Monday, 7 April 2014

Day Forty: Fourth and Final Game

At last, I was able to make it in time to release the fourth game. Although here in London it's already 2 in the morning which means I was 2 hours late of my deadline. I spent a lot of time finishing up the third game and I had at most 6 days left to create the fourth game. With 8 hours a days to spend I had at most 48 hours to create the fourth game and half the time was spent on brooding over what idea and design would fit on the project timeline of at least 40 hours.

The idea I came up with was of a minimalistic simple endless runner with the use of RGB colors. The final design became that of controlling three runner characters on one view while avoiding obstacles with each color a different style of running. Red one a regular jump over obstacles, Green one flipping gravity and the Blue one is upside down.

The goal of the game is to be able to control all three characters and avoiding every obstacle that comes their way. The less hits you get the better you are at controlling them. The gameplay only lasts for 60 seconds and a percentage rate of how good the player avoided all obstacles are shown on an end screen.

Here are the release links for the game:

Game Title: Change Of Perspective
Standalone DL link:
RGB is a minimalistic short runner game that will test your hand-eye coordination skill by controlling 3 different runner characters. It will only take a maximum of 3 minutes of your time. Have a go and see how good your hand-eye coordination is.

- Keys [1][2][3] or [z][x][c] to control each character [r][g][b] respectively
- Left Mouse Button [LMB] can be used to click on each color to control the characters



Monday, 31 March 2014

Day Thirty-Three: Change Of Perspective Release

Game 3 took awhile because I was trying out a new game mechanic and I really liked it. Development time for Change Of Perspective took 13 days in total and I've learned quite a lot of things, on of those is to leave time for level design. After making sure that the gameplay works properly as intended, It took me almost 5 days to create the levels and make sure it solvable and challenging at the same time.

Here's the release links of the game.

Game Title: Change Of Perspective
Standalone DL link:

Change from first person to top down perspective in order to solve and complete the levels. Move around in first person and change the level layout in top down to suit your needs. Instructions are shown in-game but here's a list of instructions for the game:

- WASD keys to move
- LMB to shoot energy
- Space bar to change perspectives
- (while in top down) LMB to rotate and move level layout
- Press P to Pause

- Connect the tiles to reach the next level
- Be careful of sentry guards, they'll shoot you without notice
- Preserve your energy, it depletes when in top down perspective
- Your health depletes by 3 when you run out of energy



Thursday, 20 March 2014

Day Twenty-Two: Game 3 [Design]

I finished Game 2 and I'm starting on Game number 3 now. Here's the design for Game 3.

Game Title: "Change Of Perspective"
Genre: Maze game

The idea of the game is that the player will be controlled through either a first person perspective and a top down perspective. The perspective can be changed anytime with a press of a button and the main perspective of the player will be first person. Refer to the images.

The player will be able to control it both top down and first person but when in the top down perspective a timer will be displayed as to how long the player can stay on that perspective giving them a sense of having to memorize the maze before the timer runs out.

There will be a limit on how many times the player can switch to top-down perspective on each level and a timer is present on how long it took the player to finish the level. Enemies will include patrolling guards and traps which will not be shown on the top down perspective but will be seen on first person.

That's about it for the design, I better start on making a project. I have 8 days left.

Tuesday, 18 March 2014

Day Twenty-One: Game 2 Release

The release for my second game was a day late, to be exact its 3 hours late. I didn't have much time for the second game as I was preparing for a job interview this past week but I still followed my plans for the development of game 2.

Skipping over writing development blogs and here it is, I was able to complete the game and release it a day late.

Game Title: Stay Away From My Tree

Standalone DL link:

Control Kuwalio and defend your eucalyptus tree from parachuting ants that wants to have a piece of your tree, from birds that wants to nest on your tree and crabs that wants to try eating your leaves. An endless tower defense that implements a simple difficulty balancing system. If the wave proves to be difficult then the difficulty will go down as long as you don't get a game over.


Sunday, 9 March 2014

Day Eleven: Game Number 2 [Design]

It's now Day 11, and this is Day 1 for my new game. For the next game I'm upping the challenge a bit to see how far I can complete it. I'm going to try to put more content. Here's a simple design document on what the next game will be.

Title: "Stay Away From My Tree"
Genre: Endless Tower Defense

The Idea:
The game will be a simple tower defense game where the player will be stationed on the left side of the screen while the creeps will be coming from the left side. The creeps will arrive by parachutes and when they fall down the ground they will start to walk towards the tree. Refer to the image. I know I'm not a good artist but it conveys what I have in mind.

The defender will be a koala, pictured below. His name is Kuwalio given to him by the artist where I got the free art from. Credits again to Vicki Wenderlich ( I will do some editing to Kuwalio so that he will be using a rocket launcher to fire at the creeps.

Kuwalio's movement will be limited to only going up and down the tree so that he can shoot down the creeps falling from the sky before they reach the ground. The game will be and endless wave of creeps and it will only be over when the tree is destroyed. It will be an endless defense. How long can the tree be defended.

To add more content, upgrades will be available for Kuwalio and the Tree. Points from shooting down the creeps will be used for upgrades. The upgrades will not be carried out on the next play through so that means if you fail to defend the tree you lose everything. This will be the difficulty of the game. A perma-lose-everything when you fail.

That's about it for the design of the game. I will start now to develop a core mechanics prototype so that I have something to start with.

Friday, 7 March 2014

Day Nine: Web And Standalone Release

skipping through day 7 and 8 development write ups I am able to finish the game and release it to the web and a standalone. All the screens are complete with the credits screen, main menu, game over and hi score screen. I'll be porting the game to android (google play) if I get some time because I need to start on the next game.

Here are the links for the game:

DDL [Standalone]:

The one in Newgrounds is still under judgement by the players who visit the site but it can be played but they won't show it to the latest games section yet. If anyone do play the game let me know what you think and rate the game too on Newgrounds.

Thanks a lot, and onward I go to the next game.

Tuesday, 4 March 2014

Day Six: Crunch Time

Nothing much of an update for Day 6 except the algorithm for the local hi score table which works as fine as it needs to be. It shows top 5 high scores and names just like a classic arcade hi score table. It took me some time to implement it but it works now.

The difficulty levels are almost half way but I need this done quick if I need some time to polish up the game. I have days 7 and 8 left before I prepare the game for release that's why it's time to CRUNCH!... after day 7 I'll feature freeze so that I have day 8 to polish up some things.

Monday, 3 March 2014

Day Five: Game Over

Day 5 is over and I have all the needed screens for the game except the credits page. I want to wait until 7th or 8th day to do the credits page. Not much has been done today, I was busy sending out job applications online. Updating my CV and writing a cover letter was mostly what I did today. 

What I've done for day 5 are the different screens of the game. I now have a main menu screen (although it's not much of a menu) - it has press enter to play and control instructions. I also implemented a game over screen where the player can input in their name using 3 letters. I followed the classic arcade format of allowing only 3 letters to input your name.

After a player inputs a name and presses enter the hi score table will appear showing the top 5 players of the game. I'm still on the process of implement the algorithm for the hi score table and it will be done by next day. It's almost a complete game now but it's still doesn't have the much needed challenging difficulty. I only have a few more days left.

The list that really needs to be checked for the next day are:
- difficulty changing
- hi score table
- sfx and bgm (this is really important)

Here's a video of the update:

Sunday, 2 March 2014

Day Four: The Lady Frog

Not much has changed for day 4 but I made sure that I have the list checked for me to know that I'm moving on. Checklist for day 4:
- Frog home activation for difficulty setting
- Increase difficulty up to a level of 5 then repeat
- Game over screen?
- Land snake moving object.
- Extra score objects - lady frog and flies.
No game over screen yet or any other screen than the main game one. It should be by day 5 or 6. Frog  home activation is done for triggering the difficulty increase but the difficulty is yet to come. Difficultly comes with balancing the game so I need to make sure I have all the needed components of the game first so I can focus on balancing. 
I created a LevelManager script to manage the increasing of difficulty or in this case just the triggering of the next level of difficulty, making sure that the needed variables are carried over to the next one. PlayerPrefs comes in really useful but I need to be careful on its usage as if there's something wrong with my PlayerPrefs setting and getting it can get confusing to know whats wrong. for example, setting the var as an int and getting it as a float will be hard to track down.

A land snake in the middle area that activate only on certain levels of difficulty is also implemented. I reorganized my Spawner script so that I have a different spawner for the upper part and lower part of the game. Both spawners have different behaviour on how to spawn moving objects but they have a lot of similarities so I just have them inherit from a base class SpawnerBehaviour then I scripted the individual needs on each script (SpawnerUpper and SpawnerLower).


Extra bonus point have also been implemented. The lady frog that needs to be escorted and the flies that pop-up in the frog home from time to time. The flies give a score of 600 and the lady frog give a score of 1000. The lady frog scores only if you have her until you reach the frog homes, she dies when you die which is the same in the classic. The flies spawns on the open frog homes, if there is already a frog in the home then they won't be able to spawn there anymore.

That's about it for Day 4. The next thing might be the difficulty balancing which will take time or maybe I should start with the different interface screens - main menu, game over, hi-score table. I'll think about what should come first in the morning but for now here's the next checklist:

- difficulty levels and balancing
- different screens and scene transitioning
- research hi score table for arcades

I'll leave a screenshot of the current development:

Saturday, 1 March 2014

Day Three: Core Gameplay

I'm 3 days in on the challenge and it seems to be going well. I now have a working core gameplay for a frogger game. At the moment it seems to be a complete gameplay for a frogger but with no difficulty setting yet. Here's what the game has now:

- The frog can move around the level with no problems so far
- The frog dies when it hits a badger or a snake
- The frog can hop on the lilypads and dies if he falls over
- The frog can go to his home now
- The frog respawns
- The GUI elements are set with the number of lives decreasing, the score goes up and the timer goes down. I give credits to codeman38 for the nice arcade style font:

There is no game over screen yet but the hi score is working as it should be. The checklist for day 3 are:
- Frog home
- Frog lives
- Respawning
- Additional moving objects - snake, bunnies with arrows, a rock

I have added a new moving object - the snake. It spawns in the river but as it is a snake it may as well be able to spawn in land but I didn't implement that yet. for now since there's no difficult setting yet, I've set it so that every 1 in 10 a snake is spawned instead of a lilypad. I'll do another snake for land and the middle land too on the next day. Recolouring and resizing should give it a different feel.

For the respawning of the player frog, I scripted a FrogDeath script and put it as a component of the player object. Everytime there is a collision triggered when the player collides with a moving object the Die function is called, this is only for the bad guys because when a collision is triggered with the player and lilypad the moving platform behaviour is called. When the player dies there is a 1 second delay to play the death animation before respawning the player which is the same on the original frogger. I'm also resetting the camera position after the death animation. The ways that a player can die now are:
- when the player collides with any bad moving object
- when player/frog falls off to the river
- when player hits the bushes that separate the frog homes
- when the player moves away too much on the side of the screen on the upper/river section

The frog homes we're simple enough to implement, although I am not tracking the number of homes activated yet which will be a job for the next day. I placed a trigger on the position home, one for each and when the frog collides with the trigger, the frog is removed (not killed), the trigger is replaced with an image of the frog to signify that the home is activate, and after a 1 second delay I respawn the player frog at the bottom to start for another round and another home to activate. This implementation is the same as the FrogDeath script, it is called FrogWin.

After doing the frog home and respawning of the player, I went on and did the GUI elements. There are four main GUI elements in classic frogger game and these are the score, hiscore, lives and timer. The way I did the GUI is by creating another camera on the scene and named it GUI Camera and positioned it on a separeat coordinates than the main camera. I then position all the needed GUI elements on the second camera (GUI Camera) and making sure that the depth of the GUI camera is higher that the main one.

This implementation of GUI works great for the setup of this type of game since the main camera never really moves much and you can see everything with this and not on a separate GUI layer which is only seen when you hit play. To access all the needed variable in the scene for the GUI, I created a GUIParameterManager which manages all the needed variables for the GUI and of course of the scene. The Manager script handles the increasing and decreasing of lives, increasing of score and recording of hi score and also handles the timer. Basically, all of the variables that's needed for the gameplay is managed in the script.

This is so that I don't lose any of the important parameters of the game especially later for difficulty setting. If any event happens on the scene, i.e. the frog dying, this script is called and updated. Singletonizing the script might be a good idea since there's only ever gonna be one copy of the said script. I need to implement this later.

With all that done in Day 3, I have now a playable game, albeit still a boring repeated play but it's a start. I still have 5 more days or rather 5 days left before the release. I decided to have the last 2 days as the release day for PC and Android since I still need to prepare the game for me to release them on each platform. Additional features of the game will now be added from here on.

- Frog home activation for difficulty setting
- Increase difficulty up to a level of 5 then repeat
- Game over screen?
- Land snake moving object.
- Extra score objects - lady frog and flies.

Here's a link to a playable web version of the game. NOTE: it will be removed when a new version is up.



Friday, 28 February 2014

Day Two: The Moving Obstacles

Here are day 2's checklist:
- implement road obstacles
- implement life system
- implement frog home
- implement a simple GUI

It's been a long day for day two. Whenever I think I've done something, another problems pops up but that's part of the process. Unfortunately, everything on the list wasn't checked and the things I've done today are:

- Camera movement from lower half to upper half and vice versa. The camera moves up to show the upper part when the player reaches the median and moves down too.
- the moving platforms for the upper part. I used lilypads instead of logs.
- the badgers instead of moving vehicles.
- the frog dying when falling in the river or being hit by a badger.

Implementing the moving objects was easy enough with the use of a spawner system. I implement a spawner that's able to spawn any type of moving object. good or bad. all moving objects in the game have the same behaviours so it was easy enough to implement. The behaviour scripts of any moving object that I want to spawn inherits from a base class called MovingObject which has direction and speed variables with monobehaviour functions as virtual so any similar behaviour can be accessed by any class or script that inherits from MovingObject.

The movement behaviour is the same on any moving object, moving from left to right or right to left. the update is called only once in the base class virtual update and every class that inherits from it will move exactly the same way dependent on the direction variable. So in the spawner, the direction and speed variable is set before the moving object is instantiated.

I created a factory of moving objects so that the spawner can just grab an object from the factory that needs to be spawned. this will make increasing the difficulty of the game later on  by just controlling or randomizing what type of moving objects will be spawned with a speed and direction.

After finishing the spawner system for moving objects, I started to implement the moving platform behaviour for the lilypads and the frog which was not part of the checklist but I did it anyway and I'm thankful actually to have started early on the moving platform because implementing a moving platform and making sure that the player does stay on the platform took time because of me wanting to try what might work best for me.

After about to finalize the moving platform behaviour, I found out that OnTriggerEnter2D and OnTriggerExit2D does not work as intended. I read on the forum that the 2D trigger functions are still buggy. OnTriggerEnter2D works like OnTriggerStay2D - which means its always called and OnTriggerExit2D doesn't even get called. Because of this I had to redo all my collision on the game from 2D to 3D collisions.

I also have to move from X and Y coordinates to X and Z, this is so that  I don't get confused with anything from collision to position since I'm dealing with 3D and not 2D. It's just my preference mostly, if working in 3D, I use X and Z (forward, back, left and right). It makes sense for me.

I made all sprite animations a child of the game object itself, for example the player gameobject parent has the colliders and movement script and the child has the player sprite animation and animation scripts. any player behaviour is done on the parent and animation behaviour like transitions is done on the child. I did this to all game objects that I have currently. That's a lesson learned at least. For now 2D triggers are not working. I don't know if it's been fixed but I'll stick to 3D.

As of Day 2 the frog  can hop onto the lilypads and die when it falls off, the frog can die when colliding with a badger. Hopefully, no more big problems will arise later on, but I'll expect more problems to be tackled. I' moving onto Day 3.

- Frog home
- Frog lives
- Respawning
- Additional moving objects - snake, bunnies with arrows, a rock

Here's a video of the game for day 2

Thursday, 27 February 2014

Day One: Core Prototype

Taking the checklist that I made on my previous post. I have checked everything that is in the list for day one development.

- game idea
- core prototype development - Player control and movement, Grid space
- asset preparation
- create repository

taking the frogger concept over here: , reading through the gameplay section got me started on what needs to be done. I created as empty project in Unity and a repository for the game so that I don't lose any of the work no matter what happens.

After creating an empty project and a repository, I began my development by preparing the assets I needed. In this case the 2D sprites. I started with this and not placeholders because I already have an Idea in mind of what the final product will be. Thanks to Vicki Wenderlich for her free art found here on this link:

I downloaded the Frogs and Lilypads and the Bunnies vs Badgers. These are the art that I'm going to use for the game. I prepared the sprite that I needed for Day 1 which are the backgrounds and the frog so that I can have a background and movement for the frog. Stitching separate sprites takes time when you do it in photoshop so I used a free sprite sheet generator available online here:

Here's the result:

I edited the backgrounds in photoshop using also some of the tileable art from the set. I made 3 backgrounds, The main one which will serve as the road for the lower half of the screen and the 2 for the upper part of the screen. Here's what they look like combined:

Now that I have the background and the player, I started coding up the behaviour of the player. I started the grid movement control for the frog. the first problem I encountered was implementing the grid movement smoothly.

I was able to implement a non-smooth grid based movement and looked into the Unity forums of what techniques people used to implement a smooth behaviour and I found one in unify community. Credits to Eric Haines (Eric5h5). I rescripted the GridMove behaviour by Eric Haines to fit my purposes of the 4 way movement - no diagonals - and moves at a press of a button then stop, not move as long as the button is pressed.

The next thing I did was to restrict the movement of the player by creating walls. There are a lot of wall implementation techniques out there for grid based but the most basic implementation of it is:

- Check the grid position of the player
- Check the grid position of where the player will move
- If the destination grid position of the player is a wall or impassable then don't let the player move there.
One way I can handle this is to create a Grid Class that will handle the grid functions that is needed to handle world to grid coordinates - check if coordinate is a wall then return true or false. And I also need to implement how to handle the impassable coordinates in the grid. This is doable and reusable anywhere and in fact I've done it and used it for pathfinding but for this game, here's how I did it.

Unity really did make life easy because instead of doing a whole grid class, I was able to implement walls/impassable tiles in one function / method.

here's the function
I firstly created a prefab wall game object and tagged it as "Wall" and then I positioned wall objects in the grid where I don't want the player to be able to move. The function searches all the game objects in the scene tagged as wall and puts them in an array. The function returns true if the end position is the same as the wall position.

Wall objects positioning
I placed this function on the movement script of my player where I can check the destination position of the player and check if the player is able to go to that position, if not then don't do any movement and stay on that position or else feel free to move there. The z value is left out because all I need for this game is x and y.

The good thing about this implementation is that I can fully control the walls in the level although there will be a lot of wall objects in the level but for a small game, I don't have to worry about optimizing performance and all I really need is an empty game object since its the position I'm after. I can optimize this later if I have time.

The last thing I did was the sprite animations for the frog. I made animations for when the frog is idle or not moving and when the frog jumps. Only these two, I did not do any face other direction animations. What I did is rotate the frog to face the movement direction that he's facing when the player tries to move the frog. This can save memory space especially image sizes can get big if it is detailed. If you can save space early on then you can use some of that space for important things. I never optimize at the beginning or in the middle of a development but if I can do it quickly, I would.

With that, the my checklist for day one is finished and 'm ready to move on to the next checklist.

- implement road obstacles
- implement life system
- implement frog home
- implement a simple GUI

The Challenge

4 Games in 40 Days is a challenge that I set to myself as a game programmer. I Just recently finished my Games Programming degree and while I'm free this is going to be my project.

The challenge is to develop 4 games within a time frame of 40 days. It will start as 10 days for each game. Starting the development from a concept stage upto the release of the games for PC, Web and Android.

The tools that I'm using are:

Unity3D Game Engine

 Adobe Photoshop CS3


Today 27th of Februrary will be the start of the challenge. So I'll start with the concept of the first game.

The game's title will be "A Frogger Experience". Bringing the classic frogger gameplay into life is the idea of the first game. 

Credits to the developer of the original Frogger: Konami.
Credits also to the people who developed the tools I'm using.

Let me end with the a checklist for day one

- game idea
- core prototype development - Player control and movement, Grid space
- asset preparation
- create repository