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