Devlog Ryan - radiatoryang/fall2018_gamedev1_morning GitHub Wiki

DEVLOG 1: The best roles to me are the artistic roles like Animator, Character Artist and Composer. Those roles feel more free and open to interpretation and creativity. The worst would be combat designer and most of the programming in terms of the AI mostly because getting NPCs to work right and not break everything is tricky. A lot of the jobs took me by surprise because I didn’t know how in depth they could get. I didn’t realize programming spanned across so many different fields and I forgot that companies can have concept artists that don’t end up doing the character art and vice versa. Out of them all, Customer Support would definitely be an absolute drag.

DEVLOG 2: Unity liked to split up polygons into triangles to better read what’s there. Focusing on how something would render based on triangles allows us to have a better looking product in the end. The Painter’s Algorithm is when objects are drawn from the back to the front while the Z-Buffer focuses more on how the scene is laid out and what is in view. Things that are not in view are essentially deleted in order to free up more ram with the Z-Buffer render method. If the wall had a surface normal, in Vector3 terms it would be (-1,0,0) since it’s facing towards me on the X axis. One thing that I was like “wow” at was the anti-aliasing and scanline rendering. I always wondered why graphics were, to put it lightly, ugly looking in the past and how people made them more smooth today. Originally, I assumed it was purely high pixel density but knowing that almost all things use this gradient method makes a lot more sense on why it looks so polished and nice.

DEVLOG 3: In the application the user is creating the cup in, there’s no way to really see what the finished product will look like while making it. The only way to see a fully rendered version of it is to render it and see how it looks. In Maya, changes are rendered automatically so that the user can always know what the product is going to look like while making it. Both apps have the line tool, the basic shapes tools and modify tool. From what I could find, 3DS 4 was made in 1995. Donkey Kong 2 and Mortal Kombat 3 were also made during that year. I don’t think I would be able to make anything remotely good looking using 3DS 4 honestly.

DEVLOG 4: 7 feels like the most important since it’s sort of just trying to make things that you want to work work in a different way. In a sense that could also improve your game since you are now forced to see it from a new angle which always leads to fun results. My concept is based on how when I’m walking with my boyfriend in crowded streets, he always seems to get lost. And when he gets lost, he goes into “Deer in the Headlights” mode. In the game, you are trying to get your boyfriend through a crowd while making sure he’s calm. The game isn’t going to be too big and I’m going to use very basic shapes in order to create the proper feel. The hardest thing to make will be modeling my boyfriend in Maya and trying to get a code to freeze him in place once he’s at a certain distance from you and freak out after reaching a high nervous level.

DEVLOG 5: The one that really sticks with me is the “This game is still interesting to me” mostly because I find it strange how deadset I get when making games. Out of all the art forms I’ve tried, game making is really the only one where I’m super pumped starting out and just never lose steam with and I’ve backed out of many things in the past. Last week I mostly worked on raycasting for the Boyfriend npc. I decided I didn’t like the spring joint and I wanted to make him move more independently. It took a while but I managed to make it to where if the raycast hits an object tagged “Player” it will move him towards it. I also modelled some Maya things (one of them is finished and in the game). Next week I want to make the code that spawns the people perfect because currently it’s okay but it could easily be better. So far I feel like I’m doing pretty good, I just want to spend a little more time working on it to make it more complete as a whole.

DEVLOG 6: https://polycount.com/discussion/192027/demon-creature-wip

In this thread, they were making a demon creature (sort of like a small gremlin boy) in maya and painting in in some other software that I don’t know. They used a lot of fine detail and I think they went into Zbrush for some of the harder edges and such. Most of it seems to be soft select in Maya, though. For the feedback, it’s all surprisingly positive and very helpful. Some people were saying the logo on the head should be thicker to match the reference picture, others were talking about how to improve the tiny details without making the file too big while the rest was complimenting the artist. The most important comments of feedback were the people who went out of their way to paint over the model in order to show the original artist how to improve their paintings.

DEVLOG 7:

Critical code studies focuses on the specifics and details of the code itself, such as what it says or does. Platform code focuses on what runs the code, such as the computer itself. RND is essentially a Random Range function that chooses a number between 0 and 1. When the 1 is added next to the RND, it causes the number to always be 0.185… which means that no matter what Commador64 you pick up, the code will always be the same. It allows for consistency between consoles and less bugs. 10 Print will cause whatever is on line 10 to print out some sort of text. To me this seems a lot like a Debug.Log function which determines if the game is running or not.

DEVLOG 8:

Personally I like the Uniport Perl one the best. It’s the only one that looks like an actual maze and not just a bunch of forward and backward slashes. In the book, it says that the Perl uses a while loop to cycle through and since the characters are right next to each other, they can be easily randomized unlike the Apple II. Esolangs are strange coding languages meant to make the code itself look interesting. It usually implements strange symbols to direct the flow of the code and can seem very weird to people who are used to basic coding languages. Rockstar is the most interesting by far. Most of the esoteric languages are either extremely complicated or just really dumb, but these two aren’t. Rockstar has an interesting method of using the words as variables themselves, giving it a whole new meaning. The fact that you can code in lyrics is really fun honestly.

DEVLOG 9:

Example 2 shows a prototype made to test the user interface. Creating it helped see if the interface was easily understandable and usable by the intended audience. In example 10, a pizza box was given to architects to use as a prototype laptop. It was used because the box was a comparable size and weight to the computer and the people testing wanted to see how the architect would interact with it as they went about their day. At least for my part of the project, I made a basic recreation of the room for the level we’re doing in Super Hot. I made it to see how the generic lightbox would interact and to make sure I knew where all the basic pieces go before trying to make something more detailed.

DEVLOG 10:

Well I’m dying but that’s just because I’ve been really really sick. Honestly, I wish I could do more but I feel like if I tried I would legit destroy everything. Despite all of that though, the game seems to be coming a long pretty nice. This week I made models and basic prototypes for Sean to use in his scripts. Essentially that was a gun and a hand holding a gun. I don’t know how to do a lot of things, including the things I’m supposed to be doing. But, there are tutorials online so at least I can learn.

DEVLOG 11:

I guess I realized I couldn’t just do the art for something in a project like this. I was surprised at how well my code worked and how it didn’t have any errors really. I raycasted the NPCs to shoot at the player and when it blended with the other codes seamlessly I was weirdly proud of myself. I’m not a very good coder and I’m usually scared to code in group projects because I always assume it’s going to mess up the game but this time it worked. I need to make the models better. Most of it looks nice, but the hands are hard to put together and coding animation for them will be hard to say the least, but I can probably do it.

DEVLOG 13:

To be honest, I feel really good about our project. Since we have a relatively large group who are all good at programming, we’ve been able to lock down the SuperHot mechanics pretty well. Of course, the modelling has been pretty tough honestly but I’m just happy that we’re at an ok place. One problem that happened was a merge from one of our group members completely destroyed the entire scene for the game. It wasn’t really anyone’s fault, but we figured out that having Unity open while merging, especially if you have a bad computer, can mess up the pull request without Github noticing. Fixing it was just a matter of reversing the pull request and merging onto the last working version.

DEVLOG 14:

I created the skybox for the SuperHot game. I didn’t really know how to make a six sided skybox but making it was easier than I thought. It was much easier actually. And once I put it in, it looked really good! One mistake I made was scaling the scene way to big in the beginning. It made developing the game a bit harder and many of my teammates really got on my back for doing it. Rescaling wasn’t too hard but I had to change the camera because the way they wanted me to resize it was impossible. I still got it finished and even added the materials.