Devlog: Brian - radiatoryang/fall2018_gamedev1_morning GitHub Wiki

Week 14) Devlog

Player Camera is the most difficult feature I struggled with for this project. It took a lot of iterations and testing to have it in my liking. is finally working now. It took much longer than expected. It took long because I somehow wanted the camera to work like a 3D shooter game where it adjusts its angle dynamically and stuff. But it turns out Katamari doesn’t do that much, there are times where objects obscure the camera view too. So I just decided to do the “usual” way of doing Player camera. The rotating part was tricky for me as the Katamari ball uses torque and my camera was rolling with it and rotating with it. The solution code was simple enough to not rotate it but follow and rotate around the ball as expected.

Week 13) Devlog

I think our project is going somewhat well in terms of progress. But I’d have to say I’m a bit worried about our project. There are things we aren’t really sure about like animating 3D modeling. I don’t think any one of us learned how to do it. We are gonna have to do a crash course with online resources.

We had a Maya file importing problem. It’s crucial that every one of us can use our models whenever they like, but while .mb files worked for the ones who created, it wasn’t the same for those who didn’t. We solved the problem by changing every modeling files to .fbx format.

Week 12) Devlog

I don’t think we had time to have code review last week. But we talked as a group, and I think for what we’ve been doing, they have been going well. I think we are still having some problems merging each of our work to “one” as we’ve been having conflicts a lot recently.

I think my Camera code has been somewhat going well. I like doing 3D modeling. It’s challenging but enjoyable to replicate the original models.

My Camera code needs some work though. It’s not easy to get the right “feel” of it. It’s actually difficult to replicate the original without original game always in hand. I can’t always go to the game library and Sony has recently blocked all the PS emulators – not that it’s wrong - so it’s been difficult to see if I’m doing it “right.”

Week 11) Devlog

We weren’t able to do code review with you as we had some of out group members missing. But we gathered as a group and went over on our current development progress, and shared our codes somewhat so that each of us can see how one thought of a coding process.

I think my 3D modeling is going somewhat well. I think some of my collectables are quite comparable to the original models in terms of the proportions and shapes. I think my Katamari Camera is going somewhat great as well. I’ve looked at some examples online, and been translating to my code.

I actually want to do more in our group in terms of creating gameplays but all our group members are too. I’ve asked them if there’s anything I can help - share their loads of work to me - but it seems they don’t need my help at the moment. Few occasions popped up when some of the group members cannot figure out coding, so I reached out to help. As for my part, I’m just focusing on Camera work to replicate the original Katamari as much as possible. It seems that there’s a lot to code just for Camera alone.

Week 10) Devlog

I think each of the group members have good amount of work at the moment. Maddy is taking care of Katamari moment, Isiah is doing level design - placing objects on to our scene -, and Michael is working on UI. Everybody seems to be “in” to their work, so I think our project will turn out well. I’m working on Player Camera mostly, but I’m also working on 3D Modeling for some of the collectables in game. I’m also coding enemy AIs in the game.

For the difficulties, 3D modeling could be a hassle in the future as I think it is important to get the proportions and details right. Player Camera seems like it could be somewhat difficult too as I’m not sure how to create dynamic camera movement that automatically adjusts to the environment.

Week 9)

Example 2 is a “look-and-feel” prototype for 3D space planning application. It allows the user/player to manipulate the object - rotate, move, slide, and lift. It’s called “look-and-feel” because the design of the prototype is to get feedback from the users quickly as possible as to whether the look and feel of the handle box user interface was promising.

Example 10 is a pizza-box prototype of an architect’s computer. Its purpose was to test if the user feels comfortable carrying a supposed laptop with a similar weight of a pizza box. The prototype was efficient as it costed almost to nothing to test it out and got good feedbacks from the users that it is awkward to carry and hold portable computers like a pizza box.

Our prototype process would be similar to a combination of Example 2 and 3. We are gonna first create each part of the game sequentially - the rolling Katamari, physics aspects of Katamari, the main follow camera, pickup camera on bottom left of the screen and such -, then test them out individually, and place them in a single scene in the end.

Week 8)

My favorite port is Apple II port as it is one of the first ports of 10 PRINT. It’s quite interesting to see how they used codes and characters around to replicate 10 PRINT as much as possible. He says they use the same BASIC statements and keywords, but there are differences. Slash and backlash must be used as the maze walls because PETSCII characters are not available, and the codes are different so more elaborate characters must be used.

Esolang is an abbreviation for Esoteric language. It’s not really a practical language but used more like an experiment in computer science and artistic areas.

I like Arnoldc the most as I’m a fan of Terminator series. It doesn’t look that straightforward to understand and doesn’t seem to be the most “logical” language, it’s at least sounds like a “language” that we can actually read and comprehend.

Week 7)

The differences between platform studies and critical code studies are the efficiency in different conditions. Platform studies relies more on hardware and is more efficient and productive depending on hardware. Critical code, on the other hand, is more dependent on the creators and is used for analysis and therefore more flexible compared to the former. The 1 in RND is the base of RND. The RND creates random based on the value of 1. The result of 10 PRINT resembles a compactor. I think I could use it to compress the sizes of sprites to optimize the game.

Week 6)

https://polycount.com/discussion/194733/wip-oseram-malevanguard

He/she is creating a fan version of Oseram malvenguard from Horizon Zero Dawn. He/she mentions referencing from a concept art as a base then using lots of symmetry techniques, and using low poly on certain parts – tasset and arm protection– to save time. The creator also uploaded a breakdown of his process of creating a model. It goes from the outer layer and silhouettes of the model, details on the outermost layer, then builds toward the inner layer step by step.

Most of the feedbacks were compliments on his work, but some were giving useful feedbacks on the balance in proportions on like how the head seems bigger than the original concept art so it gives more cartoony look than it should. So the creator edited the head and body proportions later on, giving more realistic and majestic look to the character.

Week 5)

Among the 10 things, “I still have further aspirations” resonates with me the most. I like my core gameplay mechanic, playing with mouse and platforming, and the more I play, the more inspiration I get. I keep wanting to add more, but that’s not really possible as we have a deadline in about 2 weeks. I do want to talk about my game for feedback, but I think I already know what I’ll get – add more depth to the gameplay. I’m aware of the problems and lack of gameplay depth, but I can’t really add more as that could just be too ambitious for this particular project. I do resonate with most of the talks in “I still further aspirations” but I find myself repressing my desires.

I’ve been working on the core gameplay mechanics for the past week. I changed the main Player control from WSAD to Mouse Control, and added jumping mechanic. The jumping isn’t really working as I intended so I might be removing it soon, but the jumping itself it related my autobiographical game idea, so I want to figure it out. As soon as I think I’m done with mechanics, I think I’ll be spending most of my time with Maya. For some reason, my Unity Project folder has gotten too big to upload. I found out my Library folder is over 350 megabytes. So it keeps giving me “Too large to upload – use GitHub large file subscription whatever” so I’ve been manually just uploading Assets folder. I was going to implement many dialogue popups when Player is in close radius with another NPCs, but I realized that alone consumes a lot of time, so I’m going to just keep the way it is for now as finishing the game is main priority.

Week 4)

“Keep playing it to get the right feel of it” seemed most important to me. I think that’s the most important part of it since games are developed for players to “play. I’m also developing a game to make what’s in my head come true, so I want my players to have the most similar experience of it - at least the core of it.

Since you mentioned you want to “know” us, my game’s going to be about my experience/time while I was in a military trainee boot camp. The Player will go through a variety of levels of military basic training, experience what it’s like, and ultimately become a private in the end. My actual time there was about 4-6 weeks, but it’s going to be short 3-4 minute game, so I’m going to just focus on the “core” experiences and levels for my game.

Player will be able to walk around and interact with objects to complete tasks to advance to next level. My game world will be in rooms of levels, so they will be about 4 levels - a minute for each level. I think I can manage. I have a feeling I’m going to spend most of my time with Maya than coding.

The hardest part would be creating that “right” feeling. It’s relatively going to be a simple game, but I also want my Player to experience what it’s likely to be a trainee at a bootcamp. So I’m going to have actually play my game a lot to closely replicate my memory and experience as much as possible. I’m going to have to learn to code and model in a way that would fulfill my needs for my development.

Week 3)

I think there could be many reasons why he renders them beforehand like for the sake of saving progress occasionally due to how it seems not easy to fix/undo progress in the editor. And I think he placed some physics/light effects on the cups at 2:22 and 3:18, so maybe the computer at that time doesn’t have enough memory to calculate them correctly in real time, and it was better, at that time, it was like a command sense to render any important changes you made before editing further from there. We don’ do that in Maya the models users create have much more complex calculations, and it takes more time to render. And user can fix anything in realtime with ease compared to 3DS 4.

Create, Rotate, Shapes and Scale functions are still in today’s Maya too.

3D Studio R4 was a 1994 modeling program. The two games developed with it were Donkey Kong Country and System Shock.

I do appreciate the capability and better UI of today’s Maya, but I think the 3D Studio R4 wasn’t too bad at all - it actually seems great. I think the modeling technique and polygon count it can actually render was way less in terms of complexity back in1994. So the user’s job with modeling was more about adding much detail and important characteristics as much as possible in the given polygon count, which was also way less maximum polygon count compared to nowadays. There weren’t as much 3D modeling programs to compared to back in the day, so, as for the UI, it looks straightforward and manageable.

Week_01)

For me, I think the best roles were the level designer, UI designer, and community manager. They sounded to make the most sense to me as they were thoughtful in the aspect of players interacting with the game. They seemed to like my type of thinking and perspective when it comes to game development. As for the worst roles, the CEO and Monetization Designer were the worst. What they said were only regarding the business side of the game but didn’t really think about the “success” of the game – will people like it enough to pay for it. I think such a perspective is important, but it could also potentially ruin the game. I think the game must be “good” before thinking about making money.

PR and Customer Support sounded most stressful jobs for me. All the other roles were mostly working within the teams – even the business side. Even when communicating with players and potential players, they could listen but didn’t necessarily have to make decisions solely based on those feedbacks. The PR and Customer Support, however, have their jobs to communicate with players mostly, and that could mean they are the ones taking bullets for the developers.

Week_02)

For more complex shapes, triangles are better to minimize the polygon count for computer to render faster and more efficiently for the sake of better framerate. Better framerate means better animation frame rate - smoother framerate, smoother gameplay.This is due to algorithms for simplifying meshes in 3D space. 3D space needs 3 points, and triangles have the minimal points of 3 points for the developer to draw those 3 points on a plane.

The difference between Painter’s Algorithm and Z-Buffer is that each uses a different algorithm. Painter’s algorithm renders in the order of the depth - from the farthest to the closest. So It sorts all the polygons from farthest to nearest, then fills each polygon in that order each at a time. It’s also called that way since a real painter paints from farthest to nearest. On the other hand, Z-Buffer doesn’t sort each polygon in such order. It rather uses Z-Buffer, matrix of values sitting in the memory, to keep track of closest distance of polygon for every pixel in the scene. First, every polygon is initialized in infinity. Then starts with a polygon in its list. Instead of coloring them in, it calculates the distances. Because they aren’t sorted, there’s no guarantee that all polygons will be visible. The pro for such algorithm is that it’s much faster to render than Painter’s algorithm. However, it could cause flickering effect if the polygons have same distances as the polygons and orders of access are constantly shuffled around in the memory.

The surface normal in Vector 3 of my keyboard would be something like (0f,1f,0f). It’s perpendicular and flat on my desk.

Z-Buffer made so much sense in understanding the flickering effects in certain games. Many people called them as “bugs” or “glitches” when they encountered them. I thought there were some glitches too at first, but because I encountered them numerous times, I always thought there must be reason behind it - there must be a solid reason why developers can’t really do anything with it. Some game examples were like “Call of Duty Modern Warfare” - it has great balance between great visual fidelity and high framerate yet I often found those flicking effects. Now, I know it was because they were using Z-Buffer algorithm for graphical calculations.