Devlog Kevin - radiatoryang/fall2018_gamedev1_morning GitHub Wiki

Week 1: My favorite roles that The Door Problem proposed were the design based roles. Specifically I would enjoy the following the most: Designer, Writer, Sound Designer, Level Designer, UI Designer, Combat Designer, Systems Designer, Creative Director and CEO. The jobs that I find to be the worst would be of the following: Gameplay Programmer, AI Programmer, Network Programmer, Legal, Release Programmer, Core Engine Programmer, Tools Programmer, Customer Support, and Localization. I was surprised by the amount of roles required to put a door in a game, especially the idea of monetizing a door itself. The monetization designer and producer shook me up a bit. The boring roles would be anything that requires paperwork like Legal and Localization. The hardest jobs for me would be the art teams and code teams while PR seems cheap and coding to be the most expensive.

Week 2: We use triangles for 3D modeling because they allow us to make more complex shapes even though they may end up using more processing power. The Painter's Algorithm determines the ordering of objects based off of their position during rendering in order of distance whereas Z-Buffering ignores determines order then renders by pixel which is much faster though can cause ordering issues. The table next to me could have it's surface normal represented on the different sides of the top and legs by perpendicular lines on those surfaces. The part of the video I felt made the most sense was the Painter's Algorithm vs. Z-Buffering because I was able to visualize how it works in a game. I find that I prefer the Painter's Algorithm because it prevents the overlap errors.

Week 3: We don't need to render in Maya because we can already see h to that of the tools in the curves and surfaces panel of Maya. The move vertex tool works the same as selecting the vertex via the modeling toolkit then moving it with the move tool and the auto-smoothing tool works the same as the smooth tool in Maya as well. Super Mario 64, Mario Kart 64, and everyone's favorite, Bubsy 3D all came out the same year as 3D Studio 4. I am glad I get to use Maya now instead of using this old software where I would have to read instruction manuals on how to use it.

Week 4: One of the best pieces of advice from the article stated that you should play the game a lot and pretend that the rest of it is there. I find this important because I often feel like I need everything working before I playtest the game. My game is going to be me going to different track meets and trying out different throwing forms. You have to hold down multiple buttons that are building up and falling together but you have to release them all at the same time. Building the track to walk around on and the background will probably be the most work. I have most of the code done but I still need to figure out how to translate these variables into physics. I think I can build most of it. I don't know if I'm going to be able to make a pretty background full of trees but the rest should be fine. I don't foresee any difficulties, everything can be solved in time.

Week 5: The one that I connect with is that I have further aspirations. I have put a lot of work into my game but I know it can be even better after I finish making the base game and I can add juice to it. This week I finished up fixing bugs in my ThrowScript and I added a score system and an easy way to restart the game. I also added scratches to the game so if any value equals zero, the ball will be thrown backwards. I also was able to create my track and field model as well as my shot put rings. 3 rings are provided and it is now easy to distinguish the levels from one another. Going forward I need to make the player model and fix a couple bugs. I need to make my code slightly more specific to the individual levels and I need to make different canvases for the different levels. I also would like to make my game look better through better animations and juice if I have time for that.

Week 6: https://polycount.com/discussion/200434/wip-3d-elesett The 3D assets I looked at was a set of armor with a sword and shield. He used Fibermesh and Renderman apps to add fine detailed textures. Most of the feedback is positive and people are just saying "good job" without any critical feedback. Some people did mention that some of the proportions of the character were thrown off by the belt and external gear so he slimmed it down. People also thought that more color value and contrast should be added to the design as well but that is very much a change that isn't necessarily better in any way. It's a choice. It seems the author didn't take much of the vague criticism into account when finishing up the model. The most important feedback was probably the bit about the proportions of the body due to the belt.

Week 7: The difference between platform studies and Critical Code Studies is that platform studies is the studies oh how particular code is written on them and how they relate to that code. Critical Code Studies is code in how it relates to Critical Theory and how it is analyzed.. As long as the RND variable is positive the code will run. It is the idea of a true false statement of should this run or not based on the variable. The one is the easiest way to hold the variable as positive. The 10PRint states the number of lines the code is on and it was used on the Commodore 64 and was used to make a maze. It adds randomness to regularity.

Week 8: The port I like the most is probably the Apple II because I am biased and my dad worked on it. The book stated that the Apple II shares a lot of BASIC programs as the Commodore 64. Esolangs are estoric coding languages that are meant to the the limits of code systems. It's almost an art form of sorts as people made the weirdest language structures they could. It helped with finding the limits of systems so that code could be made most efficient and effective. The esolang I found the most interesting was the one called Pikachu because it just seems the most odd and funny. Only to be able to write in Pi- Pika- and Pikachu is the weirdest language I've seen.

Week 9: Example 2 from the reading showcases itself to be a Look and Feel playtest as well as an implementation playtest. The playtest was to test the user interface and how the player reacted to it. This is why it is a Look and Feel playtest. It is also an implementation playtest because it tests the functionality of the UI itself. As for example ten with the pizza box, I would have to say it is a Look and Feel playtest as well as a role playtest. It is a Look and Feel playtest because it is testing the weight and feel of the pizza box and how the movement is affected by it. It is also a role playtest because it represents how it will affect our everyday lives. The game we are making will need a lot of Implementation and Look and Feel playtests in order for it to work as well as Look and Feel like Overcooked.

Week 10: As I am working on my project this week, I am realizing that we should have mapped out out work for the rest of the semester rather than assigning work each week. We should have budgeted our time on a master schedule because now, doing the work we are doing, I'm not sure if we will finish in time, also considering not knowing how much time we will have to work in the coming weeks. This last week I just set up the AI code and fixed the camera movement so it actually locked at certain heights as well as made a couple 3D models. I realize I should leave the modeling to others and focus on the code alone.

Week 11: Working on code with other people can be very difficult. When you don't know what the other person was striving to achieve with their code, you can find conflicts with theirs and your own. Luckily I was able to figure out how to fix these conflicts and it helped me learn more about code by how it is set up in a different manner. Now that I have all those errors smoothed out, I feel like everything will be much easier from this point on. I have an idea of how I want to go about doing the rest of the code for this project and I am feeling a lot less stressed. To improve I need to communicate more with my team when we are not present to converse with one another and also give people ideas on how to go about their code.

Week 13: I'm feeling really good about my work on this project right now but I'm worried we all haven't done enough work to be on track to make it look polished and clean. I feel like every week ends up with me working to fix other people's errors rather than just having everyone ready and moving on to the next step in the process. I think the biggest problem's we have had have been with github. When we started, all of Mina's code work got deleted but after we asked for Xin's help and started to learn how to use SourceTree and github more effectively. We still have problems with it at times with merge conflicts but we always save back-ups of our work now as well.

Week 14:This weekend it took me about 6 hours to make a system where I could find specific objects in a list delete them, shift the position of some of the items in the list and give the player a score based on how long that gameObject was alive, visualized through our UI which I also did. This took longer than expected because the solution required the use of functions I've never really used before and I'm not as experienced with lists because usually my games don't need many objects and I've never needed to use it with as many conditions as this. I made a mistake calling the child of some game objects. I forgot to nest an if statement asking if the object had a child to begin with before asking it to get the child. It never broke the game but it gave error codes in the inspector. I haven't implemented the fix in code yet but it should be very simple. I just need to find where the error is which I can do by clicking on the error message then add that if statement.