EPTThis 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. This week I'll be talking about some of the technical stuff behind Sam the Pirate, including what it is being written in, where I'm am at the moment, and where I'm headed over the next couple of weeks.
The Foundation
C++ and Simple DirectMedia Layer (SDL) are being used as the foundation to create The Adventures of Sam the Pirate. This does mean that there is a fair bit of initial work to be done at the start, versus using something like Unity, however I'm more comfortable doing this and using C++ than using an already existing engine. I do have previous experience with Unity, however I get more personal satisfaction and simply enjoy creating games in C++ more than using existing tools like unity. It's certainly a much bigger challenge, essentially writing it from scratch, but I'm quite excited about it.
I chose to use SDL as it works in C++, cross-platform, distributed under the zlib license so free to use for any project. The cross-platform support means that it could be released on Mac and Linux, but at the moment that's something I'll be looking at after the initial PC release. The lack of access to Mac/Linux machines, and my lack of experience with them, means I can't really do anything about it at the moment anyway, even though I'd like to at some point.
So far SDL has been very good, it's very easy to work with, and very quick to get something rendering on the screen. I followed these tutorials to get started, so if you're interested in looking at SDL they're a good place to start. As Sam the Pirate is a 2D project, I'm using SDLs built in 2D renderer, and not using OpenGL at all. As far as I can tell at the moment, it should be sufficient for what I want to do, so if I get performance issues with the rendering later down the line, I guess I'll either have to do some heavy optimization or crunch and convert the rendering to use OpenGL.
Probably the biggest challenge I'm going to face on the coding side of the project, is the physics. Originally, I had planned to use an existing 2D physics engine such as Box2D. After a comment from one of my classmates, thinking about it some more and doing a bit of research, I changed my mind and decided to write my own from scratch. There are a two reasons for this:
- May have to fight the physics engine to get the desired platforming behaviours
- Don't need everything that comes with a physics engine
See the situation in the image below, where the green box is a bounding box for the stick figure character(Forgive my awesome paint skills!):
![[image loading]](http://swashbucklinstudios.com/wp-content/uploads/2013/11/physicsengine.png)
Using a physics engine, it would be expected for the green box to fall off the platform. In a platforming game, I wouldn't necessarily expect that to happen until the character is completely off the platform. To get the expected platformer behaviour using Box2D, I'd have to hack away at the collision response and prevent the green box from tumbling down. There's a similar situation with moving platforms, as collision response would need to be hacked away at to make the character stick to the moving platform.
The second reason is probably the biggest reason for not using a physics engine, they'll simply come with way more functionality than I need. I don't plan on doing anything particularly complicated, so I don't need a full on physics engine. Combined with the previous reason, it's probably time efficient to write something relatively simple that does what I need, rather than implement a full on physics engine and fight with it to get what I want. If something doesn't work how it should, writing my own code will also be easier to debug than using a big complicated physics engine. I'll cover more about how I implement the physics in a future blog post.
Recent Progress
Over the last couple of weeks, I got rendering up and running and implemented logging to a file, to the screen, and implemented a console, similar to what you see in some games. As SDL does not have native support for rendering fonts to the screen, I'm using SDL_ttf, which seems fairly slow to render text. It does look like there is a more efficient way to do it using glyphs, rather than just rendering a line of text, but I'm not 100% sure how that would work and don't really have time to investigate it at the moment. It's not so slow that it's causing any problems, and given that all of this logging is just for debugging purposes, so will not be present in the release build it shouldn't be a concern.
One of my goals with creating a debug console, was to create it in such a way that I could add console commands without modifying the code behind the console. To accomplish this, I used Lua scripting. The exact method feels pretty roundabout to me, but it works, and that's the most important thing. The image below shows an example of a command that sets the sprite with unique ID 0, to the position (100,100):
![[image loading]](http://swashbucklinstudios.com/wp-content/uploads/2013/11/consolecommand.png)
- The first section, sprite, is the name of the .lua file to open.
- The second section, setposition, is the name of the function inside the .lua file to call.
- The last three sections are the parameters to be passed to the setposition function.
- The parameters are comma separated, and follow the format type-value. In this case three integers are being passed.
The console parses the command exactly like that. The lua function then calls a C++ function, in this case, in the sprite system, which then sets the position of the appropriate sprite. Adding new console commands is then just a matter of creating the lua file and function, creating the C++ function and telling Lua that it exists. A bit roundabout, as you can see, but it works and I'm pretty pleased with it.
What's next?
Over the next week I'll be getting animated sprites from spritesheets working, and starting work on the physics and controls. In next weeks blog I'll be covering a bit more about the game play, including mechanics, levels, enemies, and scoring.
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!
.
Just be careful of who you take advice from. Sure Box2D will have more features than you need, but it was made to be useful in any 2D game. There's a reason why it's so popular. I'm just pretty annoyed when I see poor advice given from ignorant (but good intentioned) programmers.
