Jam Prep – City Fox (part 2)

We progressed with our individual game projects in class today, with a few goals for this week. Some of the more important ones were:

  1. Discuss the use of arrays in code
  2. Experiment with arrays of vertices
  3. Add win/loss conditions to our games
  4. Add enemy movement to our games
  5. Develop a blog post reflecting on all of this

We looked at a particular example of code that used arrays to generate shapes – this is something I’ll discuss in a separate blog, so this one remains focused on the jam prep. However, it was nice to see how arrays could be used in other ways outside of how I’ve used them so far: starting with the walking simulator where we used lists for our inventory, then moving on to the game jam and randomising obstacles through an array, up to now using them for storing waypoints in our 2D games.

After that, I returned to the post-it plan for this week and made sure I had at least 3 things I wanted to cover. These were based around suggestions from Ant, although one of those (add enemy movement) I had already done last week.

postit2

I wanted to make an end goal, but incorporate something from another lesson as practice: I was going to use a particle system to create a visible sign on the ground where the player would go to finish the level. I also wanted to include pick-ups for the the fox to walk over (in this case, apples) before the player could win the level. Of course, I also needed to put in a lose condition, where if the fox was hit by a car or caught by a person, then the game was over.

To start, I brought in a sprite sheet I found off of Google to make up the “portal” or finish. I set this up in a few minutes after re-familiarising myself with the steps and I think it serves its purpose. When I have a little more time, I’ll investigate how to make up my own sprite sheet so I can replace this – I tried for about an hour and unfortunately the sheet I made appeared a bit wonky. I’m wondering if, despite thinking I centred everything, there may be easier/better ways of doing this.

heal_001

After that, I began focusing solely on my code; everything I needed for a basic first level was in place once I added in the pick-ups. While I’d not posted about it in my last blog entry, I had added code onto my fox to get him moving around the scene last class. I wasn’t too happy with the idea he wasn’t rotating, though, so I hit the internet for an easy if statement to add into my Movement function.

playermovement

The first bit of code (lines 47 to 50 inclusive) were from our previous lessons, something Any provided for us. However, lines 51 onwards were what I found to make sure the fox could nicely rotate in the right direction. I’m getting better at thinking in mathematical terms on how to find the direction an object is moving in and then having it rotate/move correctly. I would reiterate this same maths later on when trying to make the “enemies” (cars and people) face the direction their moving, too. Practice makes perfect!

gameplay2

The above screenshot shows what the game is now like, where the player can pick up the apples and then make a beeline for the swirly exit point. Doing the code for the pick-ups was pretty straight-forward, since I’ve done it a number of times now. I decided to add in the collision detection for the two “enemies” – this was easily done by applying tags to the objects and then referring to them in-game. Quite frankly, this makes even more sense to me if I have multiple cars and/or people moving around later levels that have to be avoided.

trigger_collision

After that, I needed to fix the problem of the waypoint followers – the elements would move along the waypoints, but they weren’t turning to face the right way as they moved. This makes sense, as Unity won’t rotate the sprite for you, but I wanted something more realistic. I think I mentioned this observation in the last blog I made, and I’d done the same sort of thing for the fox, so I cannibalised that code to inject into the waypoint script we’d been given a while ago.

waypoint_movetowards

 

waypointrotation

I needed to make a new Vector3 variable (called “direction”), that was the next waypoint minus the position the sprite was already in. After that, I could find the angle of direction using Mathf.Atan2 multiplied by Mathf.Rad2Deg – this would mean I could then figure out the transform.rotation with a Quaternion.Euler formula. I think it worked out quite well! The screen clip above shows a little bit of the re-directions, which will happen off screen to what the player can view.

So far, I think the game is coming together nicely. I think it’ll be good to add a scoring system, maybe a timer that will also be a game over condition, some menus, and so on.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s