Devlog: Cindy - radiatoryang/fall2018_gamedev1_morning GitHub Wiki

Week 14

  • Talk about one task you completed, and how long it took -- it probably took longer than you predicted... Why? Was anything surprisingly difficult or tricky? I made my own version of the Super Monkey Ball logo to use on the main menu screen, and found a nice realistic cloud background - it took a few hours, mostly because of the difficulty in matching fonts and finding a non-watermarked image that was decently high quality. A lot of fonts are very similar, but little things are off, such as how they design the leg of an R, or how curved an S is. That, combined with figuring out how to fish eye the letters individually, took up a lot of time. Finding a cloud background was slightly easier, although I still had to go back into Photoshop and edit it to my needs.
  • Talk about a mistake you made or a misunderstanding you had about the project... When did you realize it, and how did you resolve it? I think I screwed up the one time I was deleting unnecessary files in SourceTree - I think I deleted some file linked to JetBrains Rider in some way, and now Unity refuses to run the game. I'm not sure when and in which version this file disappeared, or if someone else had deleted it, but I plan on going through everyone else's version to find and copy that file.

Week 13

  • Emotionally, how do you feel about the project right now? Are you depressed? Worried? Optimistic? Excited? And why do you feel that way? I am very tired, but fairly optimistic about the project, as long as our main 3D modeler pulls through with nice models. We have most of the necessary systems in place, the bulk of the work right now is fine tuning and juice. I am mildly worried about how the movement will feel - we have yet to implement movement that feels satisfying, which is the very core part of the game, and we don't have a lot of time left to continue fiddling with it.
  • Talk about one specific problem that happened with the project, and how the group fixed it. One issue was having work deleted via merging - the UI systems are implemented across multiple scripts that belong to different people, so when we did a mass merge, almost all of the code for the UI was gone. We ended up just taking a break while one of us worked on hooking everything back up, then had everyone pull.

Week 11

  • How did code review go? Did you learn/realize anything about any part of your project, or workflow? I realized that while my group has a very strong start, we really need to start merging together our scenes - there are a lot of major changes that need to be updated across everyone's versions.
  • Talk about one thing you are doing well. Other than some really stupid mistakes, I'm surprised how easy it was to emulate and hook up all the necessary UI and game manager elements. Part of it may come from having to do that over and over again in different classes, but either way the menus and text are all working as intended.
  • Talk about one thing you need to improve; how are you going to improve at it? I still need to improve the UI graphics - while everything works the way I want it to, all the text is placeholder and need to be replaced with images or fonts much closer to the actual Monkey Ball font. I also need to improve the life and score system so that they reset if you leave the game.

Week 10

  • Other than the giant Git mess this week, how else are you feeling? I'm feeling sort of tired, and sort of confused on how to merge all the different version of the project together into one/multiple scenes. I'm also feeling a little bit overwhelmed with how much work is ahead, and how quickly the month is passing by.
  • What are you working on this week? Is there anything you don't know how to do? I would like to start working on UI and 3D modeling assets and animation. I don't know how to import 3D animations into Unity, or how to hook it up to specific game objects and if statements. I also don't know how to animated custom UI images, although I do know how to make them.

Week 9

  • What type of prototype is example 2, and why? Example 2 is a look and feel type prototype, because it primarily explores how it feels to utilize and look at the bounding box tools - whether it's too clunky or too complicated - via the senses, rather than how the prototype fits within the overall project.

  • What type of prototype is example 10, and why? Example 10 is also primarily a look and feel type prototype, because the usage of a weighted pizza box reflects the usability of an object in the hands of the user rather than how they would actually implement certain programs. It's also a little bit of a role type prototype, because it helped designers see how it fits within the context of that specific environment.

  • What kind of prototype are you making for the final project, and why? Since I'm building the game manager, my prototype is mainly implementation, with some role-based elements. The game manager keeps track of scenes, scores, menus, all while displaying relevant information on the UI. It's the "nuts and bolts" within the project, and also helps with usability due to the text elements.

Week 8

  • Which of the ports do you like most? What does the book say about it? I like the Unicode Perl port of 10 Print most, mostly because it's the most aesthetically pleasing. The program runs slightly slower due to outputting in Unicode, but the usage of diagonal lines rather than forward and back slashes enhances the look into a very nice looking maze.

  • What is an "esolang"? What's the point of an esolang? An esolang, or an esoteric programming language, is a programming language that favors something other than efficiency and clarity. Esolangs explore the boundaries of programming language design, sometimes poking fun at traditional convention.

  • In this list of esolangs, which is your favorite / which is most interesting to you? Why? FiM++ is really interesting to me, mostly because it's hilarious that someone created as esolang that reads like the script of My Little Pony, but also because while it uses lines from the show, it reads like regular English, and the function of each segment is more or less written out - the sign off of "Your faithful student" ends both the "report" and the code, etc. This would be a good esolang to teach to very young or very beginner programmers, as long as they don't mind MLP.

Week 7

  • What is the difference between platform studies and critical code studies? Platform studies is the study of various platforms that code runs on, such as the hardware itself or virtual machines, rather than the code itself. Critical code studies is the study of code without neglecting the cultural and historical contexts that surround it.

  • In the “RND(1)” in 10PRINT, What does the “1” do? The 1 is used to generate the same number, no matter what, using the current seed.

  • What does the 10PRINT result resemble? How would you use it for a game? It resembles a maze. You could use it to make randomly generated mazes for roguelikes, or have randomly generated mazes for puzzle solving, etc., without ever having to manually build out levels.

Week 6

https://polycount.com/discussion/187654/finished-leona-overwatch-style

  • What kind of 3D asset did they make? What techniques did they use to make it? The modeler recreated and remodeled Leona, a character from League of Legends, in the style of Overwatch, adjusting and remodeling her outfit and weapons accordingly. For their high-res model, they used Z-Brush to sculpt the model, and for the "in-game" model, they utilized a lot of beveling and bump maps(?) to preserve all the small details while remaining within the Overwatch game model standards. They also used a mixture of quads and triangles to get a smoother curve for the modeled cloth and armor. The smooth, curving shield was definitely made using either soft selection or deformers, with the edge on it and the sword being made with a tiny bevel.

  • What kind of feedback are they getting? What was the most important feedback? A lot of the feedback had to do with the proportions of Leona, mostly to do with her head and eye size in order to match the Overwatch style better, as well as making sure her collar wasn't clipping directly into her chest. A good amount also related to textures and materials - specifically to change the color values and variation in order to make Leona look less monochromatic, due to the modeler originally going for an all gold, red, and warm silver look. In the end, the push for a closer look to her original colors really cemented the final look; the modeler redid her textures so that it was much more cool toned, which highlighted a lot of the sculpting and accents they had put in.

Week 5

  • Which of those 10 things resonates with you? Why? The uncertainty of the type and quality of the content one puts out is something that resonates deeply with me, and I suspect with many other creators. The anxiety of trying to measure up to the standards set by someone else, with no way to tell how you're doing currently besides your own internal, skewed metric, is terrifying. In addition, the mention of throwing away feedback is hilariously, painfully true - you want to stay as close as possible to your original design, but in order to improve it you need to change it based on the opinions of others, but change is scary and so much work and it's so much easier to just fiddle with your original nonsense until it works, but if you don't use your feedback then it's garbage, etc., etc.

  • Devlog: I set up the winning and restart conditions, as well as included instructions. I added more flotsam within the river, and added more rocks in odd places to force the player to platform across the debris. I started modeling out some of the debris in Maya. I plan to continue modeling in Maya, and design out the player character and the rocks, making sure that the rock models will balance properly when put into the game. I still need to code one interaction that's not basic movement, I'm not entirely sure what that will be yet, maybe a key that the player can hit before they hit the water that resets their position to a safe spot. I don't have many concerns - just a little worried about how different models will affect the balance of the stacked rocks and the platforming. I plan to include some very strangely shaped models, hopefully the mesh colliders won't freak out too much. I am mostly satisfied with my progress.

Week 4

  • Which of Michael Brough's steps seem most important to you? Why? Step 7 seems to be the most important - in the end you'll never have enough time, so tying up loose ends by merging things in order to have a game that works instead of the game you wanted is something that always happens, and is integral to having a game to submit at all.

  • So... What is your midterm game concept? (2-3 sentences maximum) A blobby human has to cross the wreckage of a bridge, collecting rocks along the way, in order to build a tiny rock tower in the middle of a big river.

  • What will happen in it? How big will your game world be? Can you build all that? There's a big river, with wreckage floating in it. The game world is just the two shores and the river, with random rocks and planks of wood. There's one really big rock in the middle. Some rocks can be picked up, and be placed on the big middle rock to make a tower.

  • What will be hard to make? Foresee any difficulties? What do you need to learn to do? The water will be annoying to texture, and deciding where to place the flotsam and rocks to create the optimal platforming will be hard. I will have to learn how to make believable water in Unity.

Week 3

  • Why do you think the user make renders at 2:22 and 3:18? Why do you think we don’t regularly make renders when working in Maya today? The user likely made those renders in order to make sure the model they revolved out looks how they want it to, because 3DS 4 cannot render out actual faces, only the wireframe. Maya now can display faces and present the result of revolves or bevels, etc., immediately, and in the model's final form. It's now possible to work from start to finish in the viewport that 3DS 4 presents only after rendering, with wireframe now being relegated to an optional view instead of a mandatory view. Because of this, there's no point in regularly making renders in Maya - the render of 3DS 4 is the default workspace in Maya.

  • Which functions / buttons from 3DS 4 are in Maya too? Name at least 3 similarities. The smoothing and the mirror functions exist in both 3DS 4 and Maya. Both programs also have a list of materials that can be used without needing to search outside the program.

  • What year is 3DS 4 from? Google / name two 3D games from that year. 3DS 4 is from 1994. Tekken 1994 and Nitemare 3D both came out in 1994.

  • Do you wish you were alive making 3D back then, or are you thankful you are learning 3D in 2018? 3DS 4 looks like the most incomprehensible, clunky piece of 3D modeling possible, I'm indescribably glad to not have to learn all that.

Week 2

  • Why do we rely on triangles instead of quads (squares) in 3D graphics? Triangles are the smallest, most minimal shape possible using points - 2 points just make a line. Triangles are also unambiguously a flat plane without dimension, whereas other shapes with more points may not be completely flat.

  • What’s the difference between Painter’s Algorithm vs Z-Buffer? Painter's Algorithm does polygon rendering via sorting the polygons based on their distance from the camera, and renders from the background to the foreground, similar to how painters work. Z-Buffer instead checks the polygon values against a list of values in its matrix, and renders polygons based on which values are lowest.

  • Look at a physical surface near you. What is it? If it were in a video game, what is its surface normal in Vector3? Why? It's a table. If it were in a video game, its surface normal would be (0f, 1f, 0f), because the light is shining down directly onto it from the overhead lights.

  • Pick a part of the video where you thought either "wow that makes so much sense" or "wtf is that, why would you do that?" Z-Buffer is sort of unintuitive, but it does seem like a much faster way to render stuff. The side effect of Z-Fighting is unfortunate though.

Week 1

  • Which industry role(s) sound the best and/or worst to you? After reading through "The Door Problem," the roles of concept artist, animator, and character artist sound the most appealing to me. The creation of assets to dictate the visual design of a game always seemed like the most fun part of game design to me - the roles of concept artist and character artist afford me that opportunity. It's amazing to be able to go from sketches to a polished, finished product that's satisfying to look at, and good animation is a keystone of modern games. The roles of core engine programmer, tools programmer, and release engineer all seem kind of terrible. While they're all incredibly important in the making of a game - the tools programmer and core engine programmer especially for large, triple A games - I wouldn't know where to start with the process.

  • Which role(s) was surprising, boring, easy, hard, cheap, expensive, or ____? The role of audio engineer can be especially difficult, trying to balance all the audio that comes with a big environment in order to make something that still sounds good without excluding any other audio. Trying to achieve that delicate balance sounds like a nightmare. The role of producer feels a little cheap, in that they're holding back content for sales purposes, but it's necessary sometimes to turn a profit and guarantee sales. I didn't even know UX/usability researcher was a role at all, although thinking about it it seems obvious - the playtesters need someone to report to. Of course, the easiest job is seemingly CEO. What a dream.