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

No comments:

Post a Comment