Where I’m at now

Oi, it’s been a while. I should definitely get into the habit of posting more regularly.

I officially “finished” my capstone project last semester, which I will post in a more “official” blog post in a bit.

A few weeks off of the capstone and general development has given me some time to think back on the capstone itself and what I did right and wrong. I’ll write another blog post analyzing all of that, because boy do I love analyzing what I did right and wrong.

The future looks interesting, to say the least.

Sincerely,

~Tomer Braff

Capstone Report Card Week 11

11.06.2016 - 11.013.2016

What I was supposed to work on

This week I was tasked to work on as much as I could on the small, sub-task list that I made for myself to work on. The main thing I needed to work on was to fix up the level loading system to properly start and end levels and load the next one. I also needed to create an obstacle that allows for climbing a ledge and dashing through an obstacle. I also needed to adjust the control method to automatically move the characters left and right.

What I worked on

Luckily, I was able to get bits and pieces of all of those done. The level loading system currently works, though it is a bit jankey. It loads the next level, but the start menu pops up for each of them, and the intro image does not play while the outro image does. The characters also immediately start moving even though they should be frozen until the player presses start.

I was able to finagle an animation of the current character “climbing” a ledge obstacle working, so I finally got that done and out of the way. I also got a dash obstacle working.

The characters now move left/right automatically and change directions if the player hits left/right when they are going right/left. Right now there is a weird glitch where crouching (hitting the down button) causes the player to speed up, and I need to figure out why the hell that does that. Dashing works when the player hits left/right when the character is already going left/right.

What went wrong and what I’m doing about it

I didn’t get things working quite as quickly as I would have liked, nor as stable as I would have liked. Tuesday was a hell of a day, to put it lightly. Right now my code is a bit spaghetti-like when doing things with the Level Manager and the UI manager, and there are a bunch of glitches that are making it hard to get the smaller things done.

I need to now get the bigger parts done, like getting the story sections placed in. Perhaps just putting up an image of dialogue or a quick summary of what is happening at the current moment, but this would need to used with the intro imaging system that needs to be fixed.

What’s next (11.13.2016 – 11.20.2016)

  • Rocket timer system
    • Randomly launch rockets, percentage of the rocket covering dependant on the timer left
  • Story/Narrative
    • Create an intro/outro image/storyboard to display at the beginning of each level.
  • Levels
    • 00
      • Tutorial, characters as children
    • 01
      • Characters as older men discussing their lives
    • 02
      • Characters talking about their families being affected by the conflict now
  • Fix character controller bugs
    • Crouching speeds character up
    • Characters start moving immediately

Capstone Report Card Week 9

10.23.2016 - 10.30.2016

What I was supposed to work on

This week I was supposed to work on a timer system as well as begin integrating a tile system to create the levels. I was also supposed to create a few more obstacle types for the player to interact with, as well as potentially start laying out a second level for further testing.

What I did work on

I’m decently happy with the amount of work I got done this week. I was able to get the Tiled tiling system working with Unity, handling all the triggers and different physics layers I need to have the characters interact with the map properly, and I finally got a decently complete level for both characters to go through. Granted, they’re symmetrical, but still.

I was also able to get a timer system working as well as a basic game loop functioning when both characters make it to the end of their respective levels. I also adjusted how the UI is displayed so that now it will display over both cameras regardless of where they are. This will mean I’ll have to use diegetic UI like highlighting objects or flashes a bit carefully so it doesn’t mess around with both character cameras, but it’s looking good.

What went wrong and what I’m doing about it

Unfortunately, I wasn’t quite able to make new obstacles. I have a script for a dash-through-able object, but I have yet to implement it. I also think it is time for me to introduce some custom animations, primarily because it’s limiting the kind of obstacles I can make without seeing how they should interact with them. For example, I’ve been wanting to make an obstacle that is too high for the player to jump ontop of, so they’d have to jump and pull themselves up to stand on it. This would require an animation, and that animation would require a system to work with the player’s root motion and other technical stuff so that it runs smoothly.

What’s next (10.30.2016 – 11.06.2016)

  • Get a few people to playtest/experiment with the game and the controls, see how they react to it.
  • Implement some test animations
  • Attempt to create obstacles more dependent on animations/directly changing the player state rather than affecting things like movement speed.
    • For example, an obstacle that completely disables the character controller so the player can’t move them for a second or two, or has to press A/D rapidly to “shake off” a stun.
  • Think up more obstacles like fires, timed obstacles that lead to different routes if overcome in time, unstable beams etc…

Capstone Report Card Week 8

10.16.2016 - 10.23.2016

What I was supposed to work on

This week my tasks included introducing the crouch mechanic into the player character controller, implement a timer system to create a fail state, playtest the game with a few people, and introduce a few new obstacles.

What I did work on

This week I incorporated crouching for the player character, an obstacle that incorporates crouching, and double-tapping left/right keys for a quick dash. I also rebuilt the level with the new obstacles in mind. I was able to incorporate animations (premade from Unity’s standard assets) into the player character for easier feedback on what’s going on.

What went wrong and what I’m doing about it

I was unable to incorporate the timer system I would have liked to use. I also didn’t have time to toy around with the tiling system to better construct the levels I want to make. Overall, I don’t feel like I worked enough on the chunks of tasks that I could have been working on. The double-tapping mechanic was annoying to figure, but I should have a solution that works.

I have been looking at different talks from game developers like Jonathan Blow, the creator of Braid, giving advice on how to approach programming and productivity in game making. I’ll have to take a look into those.

What’s next (10.16.2016 – 10.23.2016)

  • Tweak camera system to transition between each other more smoothly
  • Get a few people to playtest/experiment with the game and the controls, see how they react to it.
  • Implement a simple timer system to create a “fail state” for the game
    • Make a “point total” for things, not necessarily ending the game. Just a timer thing to put in there.
  • Looking into tilesets/tile system
    • Get some open source/free 2d sprites/tilesets for the level
  • Think up more obstacles like fires, timed obstacles that lead to different routes if overcome in time, unstable beams etc…

Capstone Report Card Week 7

10.09.2016 - 10.16.2016

What I was supposed to work on

This week I was supposed to develop a list of obstacles and mechanics that would go into the game. This would include all the smaller details of the obstacles even if they are mechanically similar, such as building debris and a junked up car acting the same way as blockade type obstacle. I was also supposed to white box the first level, placing basic obstacles to have the characters run through.

What I did work on

Luckily I was able to get a decent amount of work done on all fronts, though I do feel like I could have done more work in general.

I wrote out a whole list of various different types of obstacles that could potentially be made for the game here. The list should categorize each obstacle type, make a description of each, and how the characters interact with each obstacle.

Additionally with whiteboxing the level, I worked a little further on the camera system with trying to get the center camera to work with zooming in and out to keep the characters visible, while also interacting with the two character cameras so it brings a smooth transition.

I’ve also introduced a different obstacle, “debris”, which will simply slow down the player if they walk through it rather than jump over it. For some reason the jump and crouch buttons aren’t working (might be an issue with Unity, restarting it seems to make it work again), but overall I’m making some decent progress.

What went wrong and what I’m doing about it

I probably could have worked a bit more on the obstacle list to provide more detail on how I would implement each type of obstacle.

I also didn’t get as much done on the programing side as I would have liked. I would have liked to get the characters to be able to physically crouch and get tunnel/crouching obstacles implemented in, and I do think I probably focused too much on the camera system again when what I had worked just fine.

I need to set time aside for myself every day or so to focus on the capstone, giving myself an hour or so to just hack away at all the things I need to do, particularly with programming.

What’s next (10.09.2016 – 10.16.2016)

  • Implement crouching for the characters
    • Implement crouching/tunnel obstacles for the characters in the level
  • Tweak camera system to transition between eachother more smoothly
  • Get a few people to playtest/experiment with the game and the controls, see how they react to it.
  • Implement a simple timer system to create a “fail state” for the game

Camera Systems are neat

Like the title says, camera systems are neat.

It took me a longer than I would have liked to make the current camera system I have, but after some finagling and diagramming things out, I figured out a system that should be able to be modified for future needs.

We’ll need the Camera that is being moved, the Target the camera is following, the xSpeed and ySpeed we want the camera to move with towards its desired location, and the minimum X/Y and maximum X/Y values for the viewport boundaries in the camera the player will have to adhere by (all four values are limited to a range [0,1]).

First, we find the difference between the Target and the camera’s position.

// Target location - Camera location
Vector3 dif = target.position - cam.transform.position;

Next, we find the topRight/botLeft corners of the “buffer zone” we’ve set up in camera’s viewport with the min/max variables. We find out where those points are in world space and then add the difference we found earlier to center it around the Target

// Corners of viewport to worldspace + dif
Vector3 topRight = cam.ViewportToWorldPoint(new Vector3(maxX, maxY) + dif;
Vector3 botLeft  = cam.ViewportToWorldPoint(new Vector3(minX, minY) + dif;

Now we need to find out the offset from the Target the camera should be at. This is broken down into the X-coordinate and Y-coordinate.

X-Coordinate:
Find the proportion between character’s X speed and the max speed. This will have a [-1,1] range (going left has a negative speed), so we convert it to a [0,1] range for the following Lerp function. We Lerp between the min/max X points from the botLeft/topRight points, giving us the X-coordinate the camera should be. We finally Lerp between the camera’s current x position and the destination with xSwitchSpeed for a smooth transition.

// X-offset: How fast is the target moving left/right proportional to maxSpeed? 
// Has Range [-1,1] convert to [0,1] 
float destPointX = Mathf.Lerp(botLeft.x, topRight.y, ((character.velocity.x / Players.RunSpeed) + 1) / 2); 
float finalX = Mathf.Lerp(cam.transform.position.x, destPointX, xSwitchSpeed * Time.deltaTime);

Y-Coordinate:
Is the character grounded? If not, the camera should move downwards so the player can see what’s coming. We assign the bottom or top y point and Lerp between the current camera y position and the destination with ySwitchSpeed for a smooth transition.

// Y-offset: Is the player grounded? True: maxY, False: minY
float destPointY = c.controller.isGrounded ? topRight.y : botLeft.y;
float finalY = Mathf.Lerp(cam.transform.position.y, destPointY, ySwitchSpeed * Time.deltaTime);

Finally, we assign the final resulting Vector to the camera’s position.

c.cam.transform.position = new Vector3(finalX, finalY, -10f);

And that’s pretty much it. There’s probably a way to make it a bit more efficient, and there are some features I could probably add like having an “internal” camera speed for when the camera needs to move with the player inside the “buffer zone”, and an “external” camera speed for if/when the character goes fast enough to outrun the camera and it needs to catch up ASAP (like maybe for a huge drop).

Still, pretty neato.

Capstone Report Card Week 6

10.02.2016 - 10.09.2016

What I was supposed to work on

This week I was to whitebox the first level of the game with basic blocks, allowing for basic obstacle traversal and movement. I was also to created and adjust the mechanics of the game (player speed, responsiveness, input, etc…) to a good point to allow for further testing. I was also supposed to expand on the mechanics list with details on different obstacles and how they would be overcome.

What I did work on

I was able to create a basic whitebox of a level, though it is by no means as complete as it probably should have been.

When I started working on the level, I quickly realized that I had to fix up the camera since the current system made it really awkward to traverse the level. For example, when jumping down a ledge it would be difficult to gauge what would be at the bottom because the camera would be locked into the character’s y position.

Since then I found an incredible article on 2D camera systems and went on implementing a dual-forward facing camera system that moved downwards whenever the player was jumping to see what was coming ahead. It took a while since I wanted to make sure I could expand on the system later.

I was tempted to purchase a Unity plugin that would handle the camera system and give me much more options for the future, but I decided that for now I would code my own solutions as this is my personal Capstone that should showcase my skills in these areas.

What went wrong and what I’m doing about it

I perhaps took way too long in constructing the camera system as is. One thing I definitely should have done is draw out/diagram the system that I needed. I tend to try and work things out in my head instead of visualizing it or writing it out which can make me even more confused and work even harder for something that probably should be simpler. Drawing out the system, breaking it into chunks (one for X coordinate, one for Y) helped me figure out exactly what I needed to do to implement the camera system I needed that could also be adjusted for the future.

I also completely forgot to detail the obstacles and mechanics for the game and will be sure to rectify that this coming week.

What’s next (10.09.2016 – 10.18.2016)

  • Write out as many detail mechanics
    • Jump over obstacle
      • Premade hole
      • Mortar round comes in and makes a hole
      • Electric cable thrashing about
      • Etc…
    • Communicate needs between both sides (get food, toss it over the wall, etc…)
  • Continue to whitebox the first level
    • Attempt to introduce crouching sections

2D Camera Systems are neat

So I’m starting to work on whiteboxing the first level of the game, getting a feel for how the controls should, well, feel, and one of my suspicions was proven correct; I’m going to need to implement a fancier camera system than what I have now.

Luckily I found a great article talking about all sorts of different camera systems and tricks taht dozens of 2D games over the years have used;

https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true

Every one of those exmples is something I’ve seen but have been unable to put into words to describe what is going on, and it’s great to find a resource that I can point at and figure out how to best describe a mechanic or system to myself and others.

Definitely makes me think on how to improve myself on communicating my ideas and concepts both to myself and to others. Video game design vocabulary isn’t quite as ubiquitous as, say, film or narrative language. People generally understand what “panning” and “zooming” are, and things like “foley” can be simplified to “audio creation”. Video games, comparatively, can be difficult to describe and get across certain mechanics and systems to other people without knowing if there’s already a term for it or how knowledgable the person you’re talking with is with game design terminology.

Capstone Report Card Week 5

09.25.2016 - 10.02.2016

What I was supposed to work on

This week I had assigned myself the task of working out what potential mechanics I could implement, regardless of it’s potential complexity of placement in the game. I would then go through each of the levels I have created for the story beats and events and specify what mechanics I should expect in each of them. This lets me visualize how the story and mechanics are paced throughout the game.

What I did work on

Luckily, I did manage to get some time to work out potential mechanics and plan them out throughout the game’s levels. I was also able to replace the character controller with a more efficient one I found online.

What went wrong and what I’m doing about it

All that said, it doesn’t feel like much work is being progressed. I did work on the character controller, replacing it with a much more efficient one that I found on the internet. This should let me iterate much more easily when adding new mechanics taht the character can do.

What’s next (10.02.2016 – 10.09.2016)

  • Write out as many detail mechanics
    • Jump over obstacle
      • Premade hole
      • Mortar round comes in and makes a hole
      • Electric cable thrashing about
      • Etc…
    • Communicate needs between both sides (get food, toss it over the wall, etc…)
  • Add two of the mechanics from the list of potential mechanics.
  • Whitebox the tutorial level with basic boxes/colliders to allow for basic gameplay
  • Adjust player controller for a better feel