Student Game Dev Part 19 - Water and enemies

Soan

New Zealand194 Posts

April 04 2014 01:43 GMT

Part One - It begins
Part Two - Technical Foundation
Part Three - Game Design
Part Four - Input and Physics
Part Five - More Physics Things
Part Six - Even More Physics
Part Seven - User Interface
Part Eight - UI and the Editor
Part Nine - Editor Progress
Part Ten - Progress, and videos
Part Eleven - Fixing the Physics
Part Twelve - Unproductive

Part Thirteen - Context menu + enemies
Part Fourteen - Enemies and Problems
Part Fifteen - Play testing
Part Sixteen - Editor and Art
Part Seventeen - Video!
Part Eighteen - Layers and Music

This Week
Hello again TeamLiquid! Welcome back to my blog about the development of The Adventures of Sam the Pirate, the 2D platformer I'm creating as the final game project for my Bachelor of Software Engineering degree. Last week I talked about getting moving platforms to work properly, and had a new video. Last week I talked about getting some parallax scrolling working, and talking a bit about music for the game. This week I'll be talking about adding water to the game, fixing the enemy movement, and starting to add coins to the game.

Water
Added water to the editor, and got it functional in the game. Placing water areas in the editor is exactly the same as placing normal tiles, however the interaction between the player and the water tiles in the game is obviously different from the interaction with the normal tiles. Entering a water tile kills the player, as Sam is a terrible pirate who does not know how to swim. When writing this code though, rather than kill the player the instant they hit the water, I'm waiting until the player is at least partially in the water. If I didn't wait, then when the player died, it would look like they are standing on the water, like they're a Jesus pirate, which would look kind of silly.

The water doesn't look like much at the moment. It's just using a plain blue texture with a bit of transparency, without any animations. Making it animated would be pretty easy, but I'm not sure it's worth spending time on that just yet, I'll look at doing in the future. I probably will have time, with the way things have been going these last couple of weeks, but we'll see!

Enemy Movement
After I added the water, I realised that fixing the enemy movement so they didn't wander off the edges of platforms was relatively urgent. In a few places, they would wander off, then hit water and fall forever because I didn't have any checks for them hitting anything else. So now they're checking the level to see if there is a tile directly in front of them to stand on, and turning around if there isn't. This does mean that that each enemy is asking the level to check all the tiles against the position of the enemy, which is pretty inefficient, but it was the fastest way I could think of at the time to get it work.

It wasn't until a couple of days later that I realised implementing invisible trigger blocks would have made far more sense, and would allow these blocks to be used elsewhere. For instance, I could have trigger blocks to reverse an enemies direction, ones to cause an enemy to jump, or any other event that I wanted to trigger within the game. One of the tutors had even mentioned it to me some time ago as well, so I'm slightly annoyed at myself for not thinking about it before hand. If I have time, I might look at implementing invisible trigger blocks, but otherwise it's something to think about for the future, when I rebuild the entire engine to be infinitely better that it currently is.

Coins
Added pirate coins to both the editor and the game, although there is no interaction with them present in the game just yet. That is a job for next week. Didn't have any proper art for them, so I whipped up some quick programmer art, and created a sprite sheet to show the coins spinning around. It looks alright to me, at least for now.

[image loading]

I had been expecting to possibly need to put in some randomisation on which frame the animation started, but this turned out to not be necessary given the way the engine works. The animation doesn't start playing, or even processing it's frames, until the coin is visible on screen. So while every coin starts at the first frame, the time at which this starts is different for each coin, as they appear on screen at different times. So that creates a nice visual effect with all the coins on screen looking like they're rotating differently.

Screenshot
[image loading]

Current state of the game. No coins on this level yet, but you can see the water (the blue block), and the programmer art clouds in the background as a parallax effect. Still missing a few animations, but I've cleverly taken the screen shot at a point where only the existing ones are visible.

What's Next?
Next week, I'll be adding everything to do with the score. Gaining score on collecting coins/killing enemies, displaying the current score, and saving it per level as the score is done per level. Depending on how that goes, I'll also look at finally adding a sound system to the engine, so I can add some background music and sounds. If I get to that point I'll probably do another video next week as well.

Keep up to date!
Be sure to follow me on Twitter, and like the Facebook page to stay up to date on future content and blog posts when they happen. If you have any questions don't hesitate to ask, either through Twitter or Facebook! You can also check out the blog, previous posts, screenshots and videos over at my site.

EatThePath

United States3943 Posts

April 04 2014 05:52 GMT

With the enemies turning around at ledges, why not just have each enemy check its surroundings instead of every tile? Or am I misunderstanding you?

Lovely clouds.

Soan

New Zealand194 Posts

April 04 2014 20:57 GMT

I could do that, but they each enemy doesn't know what tiles are around them, and as they moved I'd have to update that information, which would still require checking the level to see what tiles were around them.

The entire thing is probably horribly inefficient, but it was the fastest way for me to get it up and running, which is the most important thing in this case.

EatThePath

United States3943 Posts

April 05 2014 00:42 GMT

On April 05 2014 05:57 Soan wrote:
I could do that, but they each enemy doesn't know what tiles are around them, and as they moved I'd have to update that information, which would still require checking the level to see what tiles were around them.

The entire thing is probably horribly inefficient, but it was the fastest way for me to get it up and running, which is the most important thing in this case.

Yeah, and it probably doesn't really matter in the end. But, if you are drawing them moving, don't you know where they are? XD I dunno how your grid / objects / level data work so maybe it's just not worth making it work with a "check nearby" scheme.

Please or register to reply.

Student Game Dev Part 19 - Water and enemies

Completed

Ongoing

Upcoming