Devlog: Matt - radiatoryang/fall2018_gamedev1_morning GitHub Wiki

Homework 1 - The Door Problem The most appealing roles for solving the Door Problem are probably the UI and Combat designers. In the context of a scene as simple as a door, UI and Combat seem like strong building blocks for strong gameplay. I'd expected to be more interested in the writing and narrative roles, but the framing of a player simply opening a door doesn't seem to warrant narrative or dialogue, and might actually be made worse by unnecessary writing. The one thing I know for sure is I don't want to be concepting, making, or animating art assets. UX Engineer sounds like one of the odder/harder jobs on the list. Do you really find people on Craigslist to playtest when you don't want experienced playtesters? Do you just ask friends or use non-design roles from the company? I have no idea.

Homework 2 - Fun with Triangles 1) We use triangles for 3D modelling because triangles can better recreate complex shapes, and because a line intersecting a triangle must always intersect its surface at two points. 2) Painter's Algorithm decides ordering by polygon during rendering (which is costly). Z-Buffering determines distance in a second, preliminary stage, then renders by pixel. The downside to Z-Buffering is that pixels with the same z-distance fight over render priority (which looks funky). 3) Physical Surface - Top triangle of Tim's Leg. Its vector normal is up, assuming that that section of skin is facing perfectly upward. 4) The difference between the painter's algorithm and z-buffering was really interesting, because I believe I've worked with painter's algorithm in processing, and z-buffering in Unity (I think). It's the kinda thing that I already knew, but enjoy having a reference term for now.

Homework 3 - Messing Around in 3D Studio 1) They probably are rendering every once in a while to check the render for errors while working. In Maya we don't need to do this because the program renders the workspace in realtime while editing. 2) Similarities include: Vertex selection, mirror editing, and the move/rotate/scale tools. 3) 3D Studio 4 was released in 1994. I've looked for games for a while but I can't find any directories of 3D Studio R4 Games, and Google searches aren't finding anything either. Happy days. 4) I'm glad that I'm working in 3D now. Good ideas come out of technological restraints (like early 3D), but I'd rather work with easier tools and place restraints on my work arbitrarily than be forced to adhere to more difficult work and design tools.

Homework 4 - How to GameJam (& Midterm Prep) 1) The most important step in Michael Brough's Game Jam tone piece(?) is definitely step 7: Realising you'll never finish the original idea and pulling together what you have to make something still cohesive. Everyone has good ideas and Cool Mechanics but I've never done a game jam that ended with a bang, as everyone slowly realises it's time to stop dreaming and start nailing all the junk everyone made together. Your game is never what you imagined; it's what you make out of the ideas and assets that imagination inspired. 2) My midterm game is a game where the player, in first person, must walk a dog. In steps, this will involve contacting the owner via a simple text interface, getting the dog on the leash, and walking the dog. 3) The text interface will be a phone in the bottom right corner--the player presses a button to send preset texts (no choice). They then have to get in the house by finding a key or guessing the passcode on the door. Then the player will enter and see that the dog always runs away from the player unless the player has a bone. With the bone, the dog moves towards the player and can be leashed with a simple input. A timer starts on the simple phone interface and only ticks down while you're outside (a distance tracker increments while moving). The player receives a star rating on how fast they completed the game and how far they walked the dog. 4) My main worries are getting the simple dog AI working and how complicated to make the leash. Stretch goal is making the phone play music.

Homework 5 - Keeping a DevLog 1) The thing that most resonated with me from our reading was one of the last headings, where the author talks about the dangers of losing motivation and becoming jaded with the core premise of a project. The feeling is one of the most important learning experiences I think I've had at the game center, because the reality's every game pitch is flawed, and after the first couple of weeks pass those flaws really become apparent. Writing (like Pittman says) helps recenter myself and remember: a game's quality comes from persistence and execution, not planning and excitement. 2) Last week I made the player's main interaction with the game--flipping burgers. I modeled a pan for flipping and got part of the collision system working. This week was extremely stressful, with broken colliders, initialised public variables, and Sublime Merge only half-pulling a previous version. I spent most of my time playing catch up to fix broken features, but also added a game quit and reset function, as well as an end game results screen. I made the burger cook correctly by rescripting physics for the burger and pan. For next week I need to get final art for the game, finish the setting around the burger cooking area, and finally solve the strange physics glitch where my burger's Rigidbody randomly activates and deactivates for no reason!

Homework 6 - 3D Models Online https://polycount.com/discussion/194733/wip-oseram-malevanguard The OP was trying to make a knight character, their equipment, and weapon. I'm not gonna lie I didn't know a lot of the methods referenced in the post. There's something called zBrush that was used to touch up cloth and stuff. The community's comments were pretty positive, and they mostly advised additional takes on the character's proportions, cloth drape, and use of colour. I'd be fuckin jazzed if I could make a model like this, from the detail and styling to small touches like the well-modeled face inside the helm.

 10/10 has a warhammer

Homework 7 - 10 PRINT

  1. Platform studies and critical code studies (CCS) are similar in that both disciplines study code not by the code but by the context in which the code was written. Platform studies analyses code as the productive of the hardware it was written on and for. CCS analyses code in the environment is was written in and for. Platform studies is (unsurprisingly) hardware focused; CCS is creator and socially focused, more holistic.
  2. RND produces a random float value between 0 and 1. The qualifying value of (1) is a seed for the random number generator, so every time "10 PRINT" is ran it is deterministically set to be the same.
  3. The result of 10 PRINT looks like it could be used as a sprite. Maybe if I were making a very low filesize game I could use 10 PRINT to dynamically create a sprite at game start to reduce filesize at the cost of runspeed. I'd probably only do this if I was physically restricted for space by something like a cartridge.

Homework 8 - Ports & 10 PRINT

  1. The port I like the most is probably the PATH port, because PATH seems like a rather specific language in the way it orients around "directions" and flow, yet feels nicely matched to 10 PRINT's directional, maze-like patterns.
  2. Esolang stands for Esoteric Language. Esolangs exist for a variety of reasons: as jokes, ways to reinterpret one's own understanding of computer logic, or languages that seek not to be as useful as they are boundary breaking or hyper-efficient (like the well-named Brainfuck).
  3. My favourite esolang is for sure Whitespace. Assuming Whitespace operates semi-similarly to the other 3-function language on that list--Pikachu--then using this language is probably pretty damn terrible. The idea of processing data by measuring the length of gaps just sounds super cool, and weirdly analog, too.

Homework 9 - Project Thoughts

  1. The time spent on MonkeyBall for me has been pretty fun so far, mostly because of the weird, oblique thinking by which Super Monkey Ball's player controller and camera functions operate. Actually implementing changes isn't too difficult, but arriving at the proper way to implement those changes is often puzzling. For myself and Sam (the two working on these core locomotion interactions), we've been making a surprisingly nice pace out of the work, and are now looking to improve the smoothness of movement via key acceleration and fine-tuning. This upcoming week will focus on implementing some art assets and fitting our simple test plane into a larger metawhole of points, menus, and game-over screens.

Homework 10 - Project Thoughts cont. I've mostly spent this part of the final project continuing to program the player controller and camera with Sam while the rest of the group has finished up programming UI and menuing screens. I think I've been doing well at adapting to the difficulties of programming this system, but it seems like every solution I make creates a new, more deeply-embedded problem to solve. At this point in the development process it may be time to cut off and let issues lie, but if there's one last thing I can jam in before juice it'd be to adapt the rotation of the world to current "forward" for the player and camera.

Homework 11(?) - Moar project thoughts So currently Super Monkey Ball is feeling pretty bad. As one of the programmers for the player control and camera, it's disheartening to see the remarkably unfun player locomotion in a game about player locomotion. The reason I have pushes but no pull requests this break is because I'm prototyping experimental solutions to player movement that might damage other' people's scripts in their current state, just trying to find a way to make the game playable. At this point I'm beginning to accept that maybe this game just won't come out that fun, that I need to join the rest of my team and pivot to art, polish, and creating a complete experience--beginning, middle, and end. One problem our team had in this assignment was making the player movement fast like in actual Monkey Ball, but easy to control and not over glitchy. I've tried RotateAroundPoint, Physics, Translation, a bunch of other things, but the problem still hasn't been completely solved.

Homework something, date December 11th I'm having continued trouble with the rotation illusion being executed with the world script; it's really bugging me, but I don't even know how to start. I've been tinkering with values, writing various debug lines to monitor local space rotation, and even analysed the acceleration input script frame by frame to find the problem, but no dice. I think it's gonna be known shippable because I can't dedicate more of my finals time to this, and it feels good to just tighten up player controls and make the game, you know, more fun. If I could go back to the beginning of this project, I think I said before, I'd definitely rebase player movement as physics; because of our core system, we can't have highspeed levels or any changes in inclination, which sucks. But it looks like monkeyball, and using flatter levels from the game has alleviated our problems. All in all I'm proud of the little game we've made, even if it's not actually that fun, because I'm learning a lot about quaternions, Unity's understanding of transform components, and that nifty script execution order you showed me last week, but boy I don't think there's any way to make the camera system not a pain in the ass.