Devlog: Sean Park - radiatoryang/fall2018_gamedev1_morning GitHub Wiki

Week 1:

READING RESPONSE: Due to the fact that video-games are an amalgamation of audio, visual, and interactive elements, I feel that the role of a project manager for a big AAA game would be an extremely stress inducing job. From a skill based stand point I'm sure the position doesn't require intense programming or production skills, but a firm understanding of how each team/person who focuses on those facets work. Not only that, you would also need to be socially adept at telling the team about set backs, defusing tension, and organizing the game's development work flow. The very specialized positions, like the lighter, seems like a pretty fun job as they need to pour all their focus on a small details/flourishes. While designing the game play and AI are super cool, I think it would be pretty awesome to become THE expert in a certain field.

Week 2:

READING RESPONSE: Triangles are used for 3D graphics because three points in a space is the bare minimum you need to have to define a plane, or a flat surface. In terms of occlusion, the painter's algorithms renders objects from furthest to closest to the player/camera while Z-Buffering finds out the distance of polygons that are closest to the camera (distance) in the game space and scan-lines the shapes according to this buffer. For the vector 3 of a wall to the right of me would be (-1,0,0) as the face of the wall is facing outwards towards the left. I've always found how strangely effective anti-aliasing is for how simple of a technical trick it is to create the illusion of smoother lines on a screen of pixels. It's mind boggling how slight changes in light/color create such a difference in visual fidelity.

Week 3:

READING RESPONSE: Watching the slow nature of 3D Studio 4 was quite frustrating compared Maya's much quicker workflow. This is probably why the person in the video had to render twice before finishing his wireframe, as they needed to check if their mesh had any errors/the model didn't look like what they imagined it to be. Maya does this in real-time so there's no need to wait. In terms of similar tools between the two programs, buttons to manipulate the vertex, scaling, and even mirrored creation are present. Since 3D studio 4 was released in 94, I can see how assets in games like Daytona USA or Myst were created in such 3d modeling software. I sort of wish I started to learn how to 3D model from this era, as I feel it would have given me both an insane foundation of understanding 3d space/math and a great deal of patience. While I agree Maya 2018 is way better than 3D studio, I'm curious how it would have felt working in 3D graphics when it was still in its infancy.

Week 4:

READING RESPONSE: Reading through the blog post I find step three the most important. Most of the time games usually make players do repetitive tasks. Whether this be platforming, puzzle solving, clicking, etc this core loop is the first thing that should be prototyped to see if it's fun/interesting at all! In terms of my biographical game, I've been biking for a few years in the city and would like to recreate a short part of my daily commute. There's a section during my commute in between 33rd and 31st st where the traffic and bike lanes get really messy. This section i think would be a great setting for a bike riding game where you have to weave through traffic carefully. Some of the challenges would be spawning a bunch of car prefabs and racing them across the screen at different speeds, and simplifying the physics of how it feels to ride a bike. I feel like I can definitely use simple geometry for the buildings, street signs, and even the cars, so I think most of the challenge will come in programming the traffic environment.

week 6:

READING RESPONSE: https://polycount.com/discussion/203655/little-bastard In this post the artist is trying to create a little goblin creature for what seems to be a third person action game. Their approach to modeling/sculpting seemed to be quite planned out as each part of the model: the goblin, its sash, and its sword were all modeled separately. On top of that, the 3D artist was using another artists concept art as a reference point for his creation. While not very exactly symmetrical, I can see how he could have used something like the symmetry tool in maya to start creating the general body shape of the goblin. The biggest critique that the artist got was that the tail of the model seemed too squiggly and bent in an unnatural shape. While the artist claimed that the tail's weird curves would look better once it got animated, he still took the feedback seriously and made changes to his model to see how both versions would look once in a game engine.

week 7:

READING RESPONSE: Critical code studies is a lens in which scholars try to look at code as more than just words that manipulate a computer to do certain tasks. CCS looks at how that code was written, who wrote it, why they wrote it, the cultural implications of the code, the legacy of the code for future programs, and etc; to ultimately see how both the world around the code and the code itself affect each other in various ways. Platform studies on the other hand focuses in on the hardware in which such software and programs reside in. How the physical machine and its form either liberate or restrict the limits that people have for the creation of digital content. RND is a function that can takes in a numeric argument, like a simple addition problem, and returns a number. Specifically the RND in 10 print picks a random number between 0 and 1. So in the case of 205.5 + RND(1), it adds a value between 0 and 1 to 205.5 which leads to the CHR$ function to round down the resulting number (205 or 206) and print the corresponding character attached to those numbers (\ or / respectively). The result of 10 Print is that of a endless maze that comes out the same every time you run the program. The creation of such a pattern through code, while not completely random, calls out things such as procedurally generated maps found in modern video games. The endless aspect of the program I feel also can be used as a means to create a game like temple-run, where there is no game over until the player fails or quits.

Week 8:

Reading Response: Out of all the ports I would say I enjoyed the translation of 10PRINT to Unicode Perl the most. I thought it was pretty cool that the Unicode port forced itself to ignore the more efficient while loop method of running 10PRINT and used its arbitrary 9585/9586 characters to visually become closer to the Commodore 64. It just shows that the most efficient way to port a program may not always be the way the best way to get the most accurate port, at least visually in this case. The maze itself also just looks much cleaner, even with its completely closed off sections.

Esolangs are programming languages that don't prioritize efficiency or readability of code. Instead, they focus on the problems and functions its developer/creator wants that language to resolve. Whether this be restricting themselves to program using only RGB values or code that when read sounds like a fictional language, esolangs seem go out of their way to break usual programming conventions. My favorite out of the list on wikipedia has to be Pikachu. It's so strange to think that someone put in the time and resources to create a language that is meant to be understood by a fictional video game character. A fictional character who canonically doesn't even have the ability to speak nor communicate outside of just spouting their name.

Week 10:

DEVLOG: Having successfully implemented the picking up script, I thought that I was 50% done with my task of programming item pick up in our clone. Instead, this week I found myself in a situation where I had to undo/edit some of my original pick up code because I didn't initially design it with the throwing action in mind. The biggest change I had to make was to restructure my code to take into consideration that pick up items now had rigid bodies on them. My initial idea was that once the item transformed its position towards the player (colliding with it eventually), it would lock itself onto the camera to look like the item was in the player's "hands". However, all of the code I wrote to re-position the object into the camera didn't work. Instead, the item would bash itself against the player capsule until the player moved forward. After a certain amount was moved forward, the item then would launch itself outwards. Seeing these complications, I think the solution to this problem would be to delete the item once it hits the player, and then initializing Ryan's model into the camera's view.

Week 11:

DEVLOG: Even though the itemPickUp script was functioning correctly there were small edits I needed to make that required me to restructure my code completely. The first task to tackle was to actually pick up the gun model instead of a generic unity cube, and sure enough some problem arose. Being an maya model, I had to place and resize a box collider on the gun. Next, whenever I pressed E on the gun model, both the gun and the unity cube both came to towards the player capsule. To prevent this, I had to un-tag the cube as a gun. This also brought about a new problem about how if there are multiple weapons in a scene my script is not written in a way to handle that right now. But, since there is only one gun in my groups WIP scene I decided to focus on making the sure the gun model was orientationing itself correctly on the mainCamera. When the gun re-positioned itself on the mainCamera it was tilted to the side, so I had to increase the transform z rotation value of GunPos to 90. This made sure the gun looked as if it was being held by the player's hand. Looking forward, I need to fix up the itemPickUp script to use rigidbodies to move and re-structure the code so that only the item being aimed at and picked up will move towards the player.

week 13:

DEVLOG: While the project is far from being fully polished, I feel that our group is pulling enough weight to have the corridor level ready to show by next week. Not only did I make pretty good progress this week in terms of giving the player the ability to throw their weapon, it was great to see my code get combined with other member's work. For example Charlie's bullet code was finally merged with the item pick up code to create a smooth transition for players to take the gun, fire it, and throw it. In terms of a problem we had to solve, the cross-heir was a small detail our group first struggled with as in SuperHot it is an animated asset. We first tried to use code/math to rotate a static image, but we kept running into problems implementing it in our existing code. Ren, then realized that we could just create an animation that gets triggered whenever the player left clicks. Moving forward I have to finish my hand model, and lerp it into view when the gun collides with the player when picking it up.

Week 14:

DEVLOG: Modeling a hand was much harder than I thought. I first tried starting with a cylinder, but found it hard to create the palm/top of the hand areas as the cylinder was too round. I had to restart completely with a cube, but I found success much quicker with it thankfully. However, by the time I was finished extruding all the fingers I realized that I had to taken into consideration that the gun would have to create the illusion of holding a gun. While it didn't turn out perfect, I was able to finagle the vertices and edges of the thumb to create enough distance between the index finger and thumb where the gun would fit. While the index finger isn't going to perfectly align to the pistol model's trigger area that Ryan modeled, I think when playing the game it will be a minor detail that will be easy to cover up through the first person camera.