JUNE 22 – JUNE 29
We wanted to make a Game Jam early on in order to set a few things in place like the main gameplay mechanics, and the feel we wanted to achieve as well as the art style. We set the date for it to the 22nd and 23rd of June, we planned to meet at 10am and finish around 6pm each day.
Because of several complications delaying some of us, the last person arrived at around 4pm, and we couldn’t really start without them, so we ended up discussing for three hours instead of eight, which meant our results were much fewer than I hoped. At we decided not to meet on the second day, because our Game Designer had to work, and I wanted the artists to get their style down.
Switch from 3D to 2D
We realised that making a full 3D game wasn’t really feasible, since our artists were both 2D focussed, with no or barely any 3D experience. So we switched, which sadly meant that I had to scrap my earlier prototype.
After some discussion we decided on an orthographic style, similar to Pokemon or the old Zelda games.
For the artstyle we will go with a Vaporwave/Cyberpunk kind of look.
I’m still not convinced whether this look will work for our game, but our artist are excited to do it, so that’s what we’re going with.
For our core gameplay we decided on a sort of Beat ’em up / SHMUP sort of design. The player will be presented with an objective for each level, most of them will involving destroying buildings and killing enemies. Other objectives may be freeing or protecting little chicks.
Like last semester, I want to be somewhat organised this semester, so I have started a few production documents on our Google Drive. One important document is the Asset Conventions doc. Since we weren’t clear on the specifics of our art style I wanted to help avoid confusion with this document.
Another Document is the Bugtracker. Since my intention is to prototype early, I need a document to keep track of all bugs. I used the same system as last semester. I quickly explained the system to my team members, and they were already using it for the two builds I had sent them.
I also made a TODO list for everyone to use, and compare progress, and Rick made a document for needed art assets.
As we switched from 3D to 2D, I had to rebuild the prototype from scratch. I got some Pokemon backgrounds and buildings and a large Link sprite sheet and started putting them together.
I built a simple state machine for the animation, which I had to redo, when I realized that connecting all states from the “Any” state, would mean you cannot really have a proper “attack” state. Since we have a top-down 2D game, the characters need animations for all four directions, so I needed to put that into the state machine. The way I finally implemented is that each substate (idle, walk, attack) begins with a “start” state, and then the direction is taken into account from there.
And this is what it looks like with the temporary art assets: (the video is quite choppy, not the game though)
Unfortunately Unity’s built-in Pathfinding system, the NavMesh, is not compatible with Unity’s built-in 2D physics and graphics system. The 2D physics system works on the XY-Plane, while unity’s NavMesh only works on the XZ-Plane. Unity doesn’t seem to b able to fix this issue.
I decided that pathfinding is quite important, so I flipped the project on its side to the XZ-Plane, and it is now using Unity’s 3D physics system. This brings some issues with it, I have to rotate all sprite renderers, which means I cannot see them in the prefab folder.
I can now use the NavMesh though, which means I don’t have to write my own pathfinding code, or buy some from the asset store.
Most code I wrote so far is pretty standard. I have an InputManager, a GameController, Health Scripts for enemies and the player, EnemySpawner and Mover, the Scripts doing the explosions and some helper scripts like Lifetime (destroy after time) and Deactivator (disable after time). I don’t really have any interesting code but I quite like the design for the melee attack came up with.
All it does is check the direction the player is facing and activate the collider for that direction. The collider deactivates itself after about half a second, and the damage is handled by the EnemyHealth Script.