Monster Mayhem

Monster Mayhem was a group project as part of my Adv Diploma Game Programming course. We worked in a team of 4 (2 programmers, artist, designer), to come up with a complete game product from concept through to completion. We used a supplied OpenGL4 framework to target Windows desktop devices with OpenGL4 graphics hardware. Below is a transcript of my development diaries for the project. I have ripped it directly from BBForum source, so some of the formatting may have been lost. The git repository with the final source can be found here. To play the final game, a pre built windows version of the game can be found here. There is alot of reading underneath so a brutally honest tl;dr peer review can be found here.

Diary Entry 1 – 13/11/2014
On Thursday our team all met for the first time. Had an informal discussion with each of the guys.

  • John Alekozoglou – Programmer – For me the scariest part of taking on a new project with a team you have never met is to make sure the programmers will be able to communicate effectively and be able to split the workload without breaking the main project build.

    John talked to me about his struggles from the previous project, such as working in an unfamiliar platform (UDK) so priority one became to pick a framework we both felt comfortable in. The AIE framework was the obvious choice as we both had experience using it from previous projects. We talked about version control solutions and both decided that using git hub for version control would be mutually beneficial. John laid out some of his concerns about not having the experience or ability to effectively contribute to the team. We have decided to meet after 3PM on Sunday to nut out some of the technical details and go over processes for committing and syncing code safely with github.

    Perforce was thrown in as an option but we decided for reasons that are too lengthy to go into on one post that Git would be a safer fit for development and Perforce could be used exclusively for project submission. John has limited weekend availability but has agreed to meet as a team at 2PM on Sundays.

    I’m excited to take on a mentoring roll, but very cautious at the same time, I know how quickly a codebase can deteriorate if design patterns and style is not followed. I have decided to work as hard as I can before Sunday (Prototype Here https://github.com/rad-corps/MonsterMayhem.git) to get a working prototype with a focus on good clean design decisions and hopefully be able to run over it with John then.

  • Reece Griffin – Designer – Reece seems like a guy I can relate to. Him and his partner are both doing AIE streams and he has a life outside of technology as a plasterer/tradesman. It may not seem relevant for this diary entry, but in my experience the hardest workers are the ones with the least amount of time to do the work. Reece pitched his idea for a free roaming top down shooter called monster mayhem. The idea was very general and he was happy to nut out the finer details with the rest of the team which I feel is an important trait. I raised a few concerns from a programming standpoint in regards to hand to hand combat and he was quite happy to bend and change the design document in an organic process. Some people in industry could learn alot from listening.
  • Javier Munoz – Artist – No one seemed to be able to pronounce Javier’s name (ha vee ay), he didn’t seem to be bothered with a series of "that’s fine" remarks after our ill attempts. Javier played an active roll in throwing out concept art ideas during the first session and setting up a pinterest account. I have since been in contact with him over skype and he has already provided me with some white box art to make a start with. I like this guy, only met on Thursday and he is already really productive. Javier expressed that he had some struggles in previous groups strictly working to their specifications (powers of 2 and resolution sizes). One of the struggles I had in the previous assignment was being able to give the artist a strict resolution to work with. I gave Javier some vague guidelines for tile and sprite sizes with the caveat that they may change, so not to spend too much time on them :) He has since posted white box art for every asset in the asset list, then posted ammendments after some programmer testing, very productive. Javier will be a pleasure to work with.

Diary Entry 2 – 14/11/2014
I had a rare free day with no distractions at home and no job to go to. This was my only opportunity to put in a solid effort before Sunday’s meeting so i spent a solid 8 hours designing and programming a working prototype. Currently have the following features implemented.

  • Game state machine – Menu, Game Loop, Game over screens all working in harmony.
  • Character movement/rotation – Character moves with WASD and rotates with the mouse. Peeled some code out of my first term Final Defense project for the rotation and mouse hacks (AIE framework mouse IS STILL INVERTED, PLEASE FIX YOUR SHIT GUYS), Also providing more than one Rotation function out of the box would be nice, most of the time we want to store our absolute rotation values and pass that, NOT PASS IN THE RELATIVE ROTATION EACH FRAME. Coupled with the fact that MoveSprite works on absolute coordinates, not relative, it is definitely not newcomer friendly. Things like this make it exponentially more difficult to work as a programming team, spending time explaining hacks… anyway, enough ranting.
  • Character Spitting – Character can spit with the mouse button – reload dictated by number of spit power ups acquired
  • Monsters – 100 Monsters are spawning when the game starts, they are dumb and just move towards the player. no waves yet.
  • Power Ups – 10 Speed up and 10 Spit up power ups are randomly dropped at the start of the game
  • Terrain – Tiled grass terrain is down
  • Camera – Pretty happy with this one, camera is moving halfway between character and mouse pointer. Took alot of dicking around and ate up more time than any other feature. But it is working!
  • Collision – Collision working between player and monster (game over), player spit and monster (monster die), and power p

OK so thats about it! big couple of days. Its amazing what can be accomplished in short time when you put your mind to it/aren’t doing 1000 subjects at a time :)

Peace out!

Diary Entry 3 16/11/2014

Safe Zone Mechanic

John, Javier and I have made the following decision based on what we think makes the most sense gameplay wise and without adding too much complexity for game programming and difficulty balancing: Reece, as the designer, please let us know if you are happy with it –

Safe zone to be a hut or some type of building (with seethrough or no roof) with a health bar that gives the player a safe area to shoot enemies from until the enemies destroy it and overrun it, there is no timer. The enemies chip away at the health bar of the safe zone until it is destroyed. Similar to how buildings are destroyed in RTS games such as Command and Conquer.

Art
We have firmed up some of the Art assets. Javier has already delivered some placeholder art which is in the current build. The current priority order for Art assets is:

  • Static images for player character and 4 enemy characters (the smallest enemy has been dropped as it was found to be unsuitable in early playtesting)
  • Safe zone tiles (concept art folder for reference)
  • Environment tiles – River (concept art folder for reference)
  • GUI Based elements
    • Wave X Complete (with each digit as a seperate asset)
    • Main menu screen (at 1680×1050)
    • Game Over Screen
  • Player animation
    • 2 or more top down sprites for walking
    • 1 or more top down spitting action
    • Player Death (Artist interpretation, same scale as player asset)
  • Enemy Animation
    • 2 or more top down sprites for walking
    • Enemy Death (explosion animation based on the largest player – programatically scaled down for smaller players)
    • 2 or more Enemy attacking safe zone animation (sorry this wasnt discussed, but will be needed to make the safe zone work)

Animation has been listed as the lowest priority for now as it is non essential for the game mechanic and a high workload for Javier (its a nice to have, but not a must have).
Javier has his work cut out for him, the above list is pretty much bare essentials, but if we can get stuck into this early on, we may be in good stead to add more later.

Programming
All of us have current build working on our machines. John and I had a conversation outside of the main meeting and he is now up and running with latest source code repo, he can build and run the game without errors.

John has expressed some concern about having the ability to contribute to the project, we have talked about it and he is happy to look over the source code base to get his head around what has been done so far. We can re-evaluate on Thursday what contribution John can make to the project.

Current programming priority order for myself is:

  • Get the wave system working
    • Different Enemy types introduced in successive waves
    • Increasing numbers of enemies in each wave
    • One thing I forgot to discuss is the spawn system logic. At the moment all enemies spawn simultaneously at the start of a wave, can we please talk about this on Thurs?
  • Environmental obstacles such as rivers etc.
    • Load and Display
    • unwalkable/or slow for player and enemy to cross (discuss)
  • Enemy pathfinding algorithm to walk around environmental obstacles

Design
One idea we tossed up was building a simple level editor so Reece could potentially be the game level designer and playtester. This would add load to the amount of Programming work, we will have to wait until Reece is available to talk about this and see if it is worthwhile.

Diary Entry 17/11/2014

Yesterday I implemented the following features –

  • Wave Generation System
  • Placeholder main menu and game over png’s (with mouse clickable buttons)
  • .ini game settings file reading
  • 3 different enemy types, with speed, scale and health attributes
  • Fence boundary
  • Spit/Stamina depletion
    • Spit frequency reduces slightly each time player spits
    • Stamina reduces slightly while player is moving

I have been in constant contact with Javier, he has delivered some more terrain art assets and thrown out some great design ideas in regards to pacing and the safe zone mechanic that we are still nutting out.

I put the following idea forward which we will discuss on Thursday:

Yet another safe zone mechanic idea
Currently we have implemented a spit and stamina reducing mechanic (spit frequency goes down each spit, stamina (speed) goes down the more you move around. The safe zone could be a way to restore both of these to full levels. The catch is while you are in there, enemies can be attacking the safe zone, once it is destroyed it is gone for the whole game.

So the good strategy would be to try and hit it up between waves, and try to stick to the power ups during waves, but if you get really stuck you may have to go there mid wave and sacrifice some safe zone damage.

Also briefly spoke to Jason King about some performance related issues I was having with AIE framework using duplicated tiles. Turns out I was doing something very braindead and should not be duplicating the texture, hoping to see some good gains once I fix this :)

Gameplay wise, I think the game is reasonably fun so far, personally I think we stand to gain the most from adding some simple pathfinding AI to the enemies.

Diary Entry 25/11/2014
Thursday’s meeting
We were greenlit by Sam and Finn on Thursday, when asked for feedback, Sam asked us to focus on enemy movement patterns.

Also, we made the following decisions in regards to the Safe Zone Mechanic

  • A new safe zone will be spawned once each time a new wave starts
  • The safe zone from the previous wave will dissappear if it hasnt already been destroyed
  • Safe zones will have a single entry point for the player
  • Safe zones will be some sort of fence so the player can shoot through but enemies can not gain access
  • Safe zones can be worn down and destroyed by enemy attacks
  • Enemies will only attack a safe zone when the player is inside it

Enemy Pathfinding
I spent the majority of yesterday implementing an A* pathfinding algorithm which turned out to be a major fail. I have since been getting some inpiration from 8 bit games from the action RPG genre (such as the original Zelda on the NES (https://www.youtube.com/watch?v=K27hfpW5onU) and Golden Axe Warrior (https://www.youtube.com/watch?v=ttD1ei0ND14),

The enemies in these games generally move with disregard to the players position (not in all cases) The difficulty balance is found through the following:

  • Number of on screen enemies
  • Enemy health
  • Environmental Obstacles
  • Enemy Strength
  • Enemy HP
  • Enemy special ability (knights cant be hit front on.. etc)

I am currently nutting out some enemy movement and attack algorithms using these games as inspiration. Taking these mechanics across to a single scrolling screen will be the challenge, environmental obstacles and opening paths may play a large roll.

I’m hoping to have at least a simple and fun random enemy movement pattern implemented by Thursday.

Diary Entry 26/11/2014
Today I worked on pathfinding based on some conversations Javier and I had. Basically gave up on the A* idea and have gone with a more traditional randomised approach.

The algorithm goes like this:

  • While Alive
    • If enemy is outside of swaming range
      • Enemy pauses for a randomly allocated time (between 0.5 secs and 1 secs)
      • Enemy picks a random direction (up, down, left, right)
      • Enemy heads in that direction for a randomly allocated time (between 0.6 and 3 secs)
    • If enemy is inside swarming range
      • Charge player at 1.5 * normal speed

Small demo of enemy movement here: http://gyazo.com/b69a8a00cdb86f1a40d0d26d6c2300f0

Some other features I have added today:

  • I have also reduced the tile sizes to 128×128 based on some playtesting
  • Simplified resizing of environmental tile sizes without rebuilding codebase (for playtesting)
  • Added enemy collision with Environment tiles (still buggy, needs work) If enemy walks into environment tile
    • Undo last enemy update
    • Recalculate enemy direction and travel time

Existing known bugs –

  • Enemies can spawn on unwalkable terrain
  • Power ups can spawn on unwalkable terrain
  • Enemies get stuck on unwalkable terrain when swarming player

Uploaded latest build which is available here: https://drive.google.com/file/d/0B3Mj-WgQhxu1aGpiMXk1MnA0d2s/view?usp=sharing

Reminder: I need to provide Javier with an interface to test different safe zone sizes and locations. I will build this into the mm.ini file so he can scale his artwork for his own testing.

diary entry 28/11/14
just quickly spitballing ideas to fix enemy movement bugs from previous diary entry.

  • create a method to compare the angle that the enemy is looking and the position of the player (is the enemy looking at the player)
  • only charge player if enemy is looking at player (enemy can be within swarm bounds but not swarming if not looking at player)
  • if enemy is swarming and collides with terrain: turn them around 180 deg (non random). this should put them back into wandering mode because they are not looking at the player.

the above should fix the swarming enemies getting stuck on terrain bug.

also need to add a method in terrain that returns a safe walkable tile to spawn enemies and power ups.

Diary Entry 02/12/2014
Small update today. I have added some functionality so Enemies can not spawn on unwalkable terrain, also enemies now have a field of view which prevents them from getting locked onto unwalkable terrain when they are in swarm mode (will only attack the player if they can see him, they turn around when hitting unwalkable terrain so they go back into wandering-around-like-a-peanut-mode after hitting unwalkable terrain in swarm mode).
Diary Entry 05/12/2014
Summary of last nights meeting:
  • We went over timesheets and budget spreadsheet in the lecture. I got our group started with modifying the AIE budget template to our needs and we have started adding hours for the previous weeks. Would have been much easier to do from day one… </small bitch>. We decided as a group that we will all be responsible for updating our own hours.
  • I presented what we currently had to James Betar and crew, and the feedback we received was to nut out all our ‘unknowns’ as soon as possible. We ran with this and started working on an ROI chart again
  • Based on some discussion in regards to the time of development VS the return on investment of all the proposed features, we refined our feature list. The safe zone, at this stage has been culled from the feature list
  • Based on the ROI chart we worked on a refined production schedule based on whole group (minus Reece’s) input.
  • We have some goal dates, but John and Javier have not been comfortable enough to give estimates based on the current workload

Pictured below are the ROI chart and refined schedule we worked on as a group.

ROI:
Image

Revised Schedule:
Image

Diary Entry 10/12/2014

Heaps has been going on but I’ve been a bit slack updating this diary so here goes:

  • 3 Enemies have been programmed with individual movement patterns personalities
    • Slug
    • Moth (disregards unwalkable terrain due to flying)
    • Fat Walker
  • Each enemy charges player in their own way when they can see it

I have also fixed a delta time bug with the player spit so it should act the same across all hardware now.

Diary Entry 13/12/2014

Over the last couple of days I have implemented the following animations:

  • All Player animation
    • Stationary (1 Frame)
    • Movement (2 Frames)
    • Attack (3 Frames)
  • Moth animation
    • Movement (3 frames over a 4 frame cycle)
    • Hit (1 Frame)
  • Enemy explosion on death
  • Hit animation on spit colliding with enemy

Very happy with results so far Javier’s Moth and explosion artworks look great-
Image

Also I have spent some time tightening up some of the enemy movement:

  • Fat walkers pause for a fraction of a second when hit
  • Moth’s dont accellerate for a whole second when hit

For future reference: When working with UV’s in AIE framework everything is a float between 0 and 1 (U is 0 at far left, V is 0 at bottom). Took quite a bit of testing to come to this conclusion after working in in Mono/XNA which uses pixel coordinates of a sprite, could be useful if this is documented in AIE.h to avoid future confusion.

I have also built a batch file for easy deployment as it was a time consuming process. This will be handy for future projects. The tasks it performs are:

  • Copy exe file to the resources directory
  • Make a copy of the resources directory and name it MonsterMayhem-&timestamp&
  • Add contents of new directory to a zip file with the same name
  • Upload the zip file to Google Drive

I have made a start on adding Javier’s trees around the border of the map. I still need to tighten up the collision somewhat, terrain collision is currently using the whole tile width/height for collision checks which isnt as suitable with trees so the will need to be some overlap. I will also need to change the circle radius to check for player/enemy collisions as they aren’t boxes any more so will also need to allow for some overlap.

There are still some issues with enemies getting stuck on the edge of unwalkable terrain and moths getting stuck on the edge of the map. They are rare cases now, but it does still happen. I’m sure it will show up when Reece does his bugtesting, but I dont know how much time I’m willing to spend on that now.

From a management point of view, I am frustrated with some aspects of team communication, Javier and I are working together as a great team, but there is definitely room to tighten up our communication with the rest of the group.

Diary Entry

In class last night our group received some great feedback last night from both James Betar and Jason King. We have organised a Saturday meeting to discuss direction based on feedback.

James’ Feedback

  • Incorporating the river system into the spit power up
  • Experiment with punishing the player more heavily when running out of spit i.e. not being able to shoot at all
  • Refine player art for movement sprites

Jasons Feedback

  • Experiment with tweening text and menus for added polish.
  • More levels? At the moment we have a single stage.

We are at a pretty late stage of development with plenty of polish still left to work on, I think the group is leaning towards more polish rather than added features but we will try and nail this down more precisely on Saturday as a group.

Diary Entry 21/12/2014

We have acquired game feedback from testers that have had no previous affiliation with Monster Mayhem and received no instruction apart from the in-game instructions.

Did you understand the effects of the power ups that you collected?

Yep – though never ran out of stamina so not sure what effect it has on the game…

When I looked at the How to Play screen, they made sense. But straight up they were a little confusing to understand what they were.

diddnt read the how-to screen to begin with but figured out the green bar was my ammo & a powerup refilled it, the other one i figured was my life or something since it went down so slow

So based on the above responses it looks like our test group did not correlate the stamina up pickup with replenishing their player speed. One of Jame’s recent comments was to punish the player further to induce a state of panic. We will have to look into this.

What are your thoughts on the difficulty level of the game?

Not very difficult, but I only got to wave 4

Not difficult enough. Could do with a normal/hard difficulty setting.

fine, AI is pretty forgiving

Recently the algorithm for wave generation has changed so the first few waves are quite easy. Based on the above, I get the feeling that the players are getting bored before it gets quite difficult (probably need to be hitting wave 8-10 for the real difficulty ramp up, 4 is still quite easy). We may have to look at managing this difficulty curve better.

How could the overall experience of Monster Mayhem be simplified for newcomers?

I found the movement a little unintuitive at first – expected to move the direction I was facing, not just the cardinal movement.
But I did get used to it after a minute or so :)

For the items and the spit/stamina bar, have text over the top to tell them what they are.

label the resource bars

Labelling the resource bars! what a no brainer, wish I had have thought of that :)

As for the movement, I brought this up in a group discussion yesterday. This is an idea I have previously played around with, and made a conscious decision against it for fear that it would not be casual gamer friendly. We have decided to implement this feature and do a separate round of player feedback to see what the consensus is on player movement design.

Did you understand the in-game user interface of Monster-Mayhem

Not until I looked at the how to play.

I’m glad the how to play screen has had some positive effect! Great work Javier!

How did you find the pacing of Monster Mayhem?

Just right

Just right

Too Slow

This was a multiple choice question with 3 responses (too fast, just right, too slow). I think this ties in with the earlier responses on difficulty. I would prefer to see people saying it is too fast than too slow. The challenge will be to get the 1st wave to challenge the player but not frustrate them then ramp up slowly from there.

Help us make Monster Mayhem better!

Different map layouts as you progress? The windowed mode didn’t fit my screen completely – the bottom (around the FPS) was off screen. Also it locked the cursor to the window, so couldn’t move it or resize it.

Prevent flying enemies from leaving the main map area. As when they drop a power up the player cannot reach it, the same with water.
Or have it that the power ups if on the water/outside the map wiggle onto the area the player can go to.

The screen resolution bug listed there has since been squashed. I spent yesterday redesigning the way the game engine works so it can work on all screen resolutions (tested from 1366×768 all the way up to 2560×1600, as well as multiple different aspect ratios), this was valuable feedback in getting the game to work across all resolutions.

Interesting point about buffs/powerups being dropped onto unwalkable terrain. I see this as a feature (forces the player to be strategic about where the shoot the flying enemies down) but is worth a discussion with group. I would lean on it being low priority.

We also received some varied informal feedback over skype:

I forgot to write this in my feedback.
But if the artist aren’t allready, I’d recommend modifying the water asset. It looks like a wierd blue wall instead xD
Oh actually another thing, When the enemies spawn before the actual wave starts, the player can’t do damage. Would be worth while to do something that makes it so that the player doesn’t use up spit during this stage

from another user spitballing ideas

maybe make it (the duration of time while begin wave shows)[sic] shorter but allow the player to hit them

Definitely some value in the exercise. We will do another round when the new control scheme is implemented (which will also have the resolution fixes applied) and compare with the initial feedback.

Ads out!

Diary Entry 24/12/2014

Over the last few days I have built a level loader that can load a CSV in specified format. The level designer can specify:

  • Level Width/Height in tiles
  • Surface tile type (currently only grass and mud)
  • Top tile type (tree, rock, river [4 rotations for corners and 2 rotations for straight], goal
  • Player starting position
  • Number of enemies (one field for each enemy type)

I have also built an engine that switches levels if one of the following conditions are met.

Javier has built a really good looking level already, I have built one and my partner has built one. So we have three in total. Looking forward to experimenting with different level dimensions.

  • All enemies are defeated
  • Player reaches goal

At the moment, the engine just looks for the next lvlx.csv file and if it finds it it loads. If it isnt there, the game falls over so will have to do something about that eventually. Possibly go back to the first level and double the enemy numbers or something.

Also interested in looking into the possibility of timing the player to get through the level and failing if the timer is reached. I think it could add a bit of drama. The timer could also be part of the level file so different levels can have different timers.

Merry XMAS all!
Peace out
Ads.

Diary Entry 09/01/2015

Too many changes and updates to list everything since last update. A brief rundown of major changes:

  • Graphical level editor for level creation and modification
  • Sound for most game actions
  • Stamina and Salivomiter regen on level switch
  • Squashed bug where player travelled faster while heading in a diagonal direction
  • Stamina max, min and usage rate rebalanced
  • Power up drop lifetime extended
  • Player death animation on game over
  • Continue button on game over screen (allows player to restart their current level without restarting the game)
  • Power up sprite changed and animated, animation speeds up as lifetime decreases
  • Player movement and attack locked while "begin wave" text displays

Still to do:

  • point system
    • points on non lethal hits
    • points on advancing a level
    • points on picking up power ups
  • Show level number at level start of level
  • Background music

Non functional to do:

  • Finalise presentation script and presentation slide show
  • Finalise budget

edit: latest build can be downloaded from: https://drive.google.com/file/d/0B3Mj-W … sp=sharing

Diary Entry 12/01/2015

The latest build is basically complete, there are still 2 known bugs in relation to enemy movement (land enemies can get trapped in corners under certain conditions and flying enemies sometimes get stuck on the border) but we can live with these if necessary. Best case scenario we might be able to sort these before submission on Thursday.

New features

  • Points do a tween like animation on screen including the following physics/logic
    • Growth accelerates proportionally to the score obtained
    • Direction and velocity is randomised
    • Velocity slows over time leading to a "tween" style effect
  • End level logic adjusted (levels can only be completed when player reaches the goal tile
  • (royalty free)Game music added to:
    • Main Menu
    • In Game
    • Game Over
    • Continue Screen

We are on track to submit and present on Thursday 15/01/2015