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
Part Nineteen - Water and Enemies
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
Part Nineteen - Water and Enemies
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 adding water to the game, fixing the enemy movement, and starting to add coins to the game. Bit of a later post, been pretty busy looking at houses to rent and moving into some temporary accommodation. This week I'll be talking about implementing the score and displaying it. I'll also talk about a decision I made regarding the number of levels, and have another new piece of music.
Score
Implemented scoring this week, so now when the player kills an enemy, or collects a coin their score goes up. Score is saved per level, so each level has its own high score, instead of their being a total overall score that carries on from level to level. I will be adding a level selection screen to the game, similar to what is present in Super Meat Boy, so that is a big part of the basis for score being individual to each level. So players will be able to replay any level they like, in order to try and beat their highest score. While it is implemented, I still need to compare the score earned against the current high score before saving it out to file.
Rendering the score was slightly tricky, as I don't want to render just straight text, as the SDL library I'm using for text is a bit slow when compared to normal sprite rendering. So I decided to use a sprite sheet, containing the digits 0-9, and use that instead. In order to do this, I need to pull out each individual digit from the number, and then render each individual digit. Pulling each individual digit out out of the integer is the tricky part, but I remembered having covered this in a class somewhere, so a quick google to refresh my memory and it was all done pretty easily. Ended up with code that looks a bit like what is listed below. If you've got any questions about it, feel free to poke me on Twitter.
tempScore = currentScore; // save the current score into a new temporary variable as we'll be modifying it
lastDigit = tempScore % 10; // the modulus operation gives us the last digit of the score
numbersSprite->setClip(numbersArray[lastDigit]); // each number from 0-9, matches an array index of clipping areas for the number spritesheet
numbersSprite->setPosition(position); // set the position to render at
numbersSprite[lastDigit]->Render(); // render the number
tempScore /= 10; // divide by 10 to shift the score 1 decimal point to the right. Using integers to everything after the decimal is lost.
position.x -= spriteWidth; // change the position for the next digit, rendering from right to left
This is repeated until tempScore is 0, at which point we have finished rendering the current score and can stop. This kind of code is like magic and makes me feel like a wizard.
Decisions
After thinking about it for a while, I decided to cut the total number of levels from 40 to 20 this week. In one of my earlier blogs I talked about the variety of environmental hazards and enemy types I wanted to include. I've come to the realisation recently that I probably don't have time to implement more than what I already have. This is all fine and good, as I expected I might have to cut some things in order to complete the game on time, but how would I fill out 40 levels with the current mechanics?
Currently, I have one enemy type, moving platforms as a level mechanic, and water as an environmental hazard. I might have time to implement some quicksand as another environmental hazard, but what would 40 levels of this be like? I think it would be pretty boring, if nothing new is introduced occasionally from level 1 all the way to level 40. I already have 17 levels designed on paper, so cutting the total to 20 makes sense, and it's also a nice round number.
I'd also been planning on implementing a timer, with a lower time resulting in a higher score, but I'm not sure I'll have time to implement this either.
Music
New piece of music, for the zombie pirate fort area of the game.
If you're interested in more music from the artist, he has a website over at Eternal Vibration that you can check out.
What's Next?
Next week I'll be tidying up the visual side of the score a little, and start implementing sound. Would've like to have the score side completely done this week, but I've been a bit busy outside work, looking at houses and preparing to move.
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.