Initial Game Design (Week 2)

JUNE 22 – JUNE 29

Game Jam

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.

ortographic camera
Pokemon Ruby left and Link to the Past on the Right. This is the kind of camera angle we’re going for.
Art Style

For the artstyle we will go with a Vaporwave/Cyberpunk kind of look.

vaporwave_moodboard1
Vaporwave Moodboard

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.

Game Mechanics

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.

Production

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.

Art Assets Conventions
Art Assets Conventions 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.

Bug Tracker
Bug Tracker with color coding and explanations (click to enlarge)

I also made a TODO list for everyone to use, and compare progress, and Rick made a document for needed art assets.

Programming

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.

Animation

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.

statemachine
Statemachine for player character

And this is what it looks like with the temporary art assets: (the video is quite choppy, not the game though)

Pathfinding

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.

prefabfolder
Prefab folder, blank images for most prefabs.

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.

Code

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.

MeleeAttack()
MeleeAttack Method

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.

PlayerMelee
Part of the OnCollide Method of the EnemyHealth Script.

 

Leave a Reply

Your email address will not be published.