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. Last week I covered the work I'd done on the UI system, and the start of the editor. This week I'll be talking about the success with the editor so far, the performance problems I've run into and mostly fixed, some concerns I have for the future, and where I'm headed next.
Editor
The editor is in a position now where I can create and save levels that are filled with fixed platforms. Pretty pleased with how it works, I can hold down the left mouse button and essentially paint out some platforms, then release the mouse button to stop, and start painting somewhere else. I also have an algorithm in place that updates the art for each tile based on the tiles around it in real time. For this to work, each tile knows about all the tiles around it. Whenever a new tile is placed, each of the grid squares around that tile are checked for existing tiles. If an existing tile is placed, it is linked to the new tile, and the new tile updates what art it should be using. The new tile is then linked to that existing one, and the existing one updates its art.
So for example, I place Tile A, by itself, so it uses a piece of art with an edge on all sides. I then place Tile B to the left of it. Tile B discovers that Tile A is to the right, and so updates its art to use a piece with an edge on the top, bottom, and the left side, leaving the right side open. Tile A is informed about Tile B, and updates its art to a piece with an edge on the top, bottom, and right side, leaving the left side open. The two pieces are now connected, and display as a single piece. A video showing this off should be coming some time in the near future, as showing is probably easier than explaining!
All of this meant I was able to lay out what I currently have planned for the first level, and successfully loaded it into the game! I felt really good once I had this, as it felt like a really big step for the game. I still feel pretty good about it, and where I am with the game overall.
Scrolling
Once I had a full level loaded into the game, I had to get the side scrolling working, as up until this point it wasn't needed, and you could simply move off the edge of the screen and disappear. It was relatively easy to do and didn't pose any problems, which was nice. There is a camera that's based on the player position, and just follows you around. When you hit the edge of a level, it stops. The player is also prevented from moving past this point. The player is also blocked from moving past the height of the level, although I did think about allowing this, to potentially allow players to just go over the top of everything and get through the level faster. I'm going to think about this some more and see how other levels play out, although I think I might end up changing my mind and allowing it.
I have noticed some vertical jittering once the camera starts to move up the screen, the player doesn't appear to move, but everything else appears to very quickly move up and down in small increments. Given that the camera is based on the players position, I'm assuming that it's the player actually doing the jittering. It also doesn't appear to happen while the player is in the air, so I'm think it's probably got to do with the collision detection and reaction to the player standing on a platform. Gravity is still being applied, so the player is probably being pushed down into the platform, and then back up in the collision reaction. I'll be investigating and confirming whether or not this is it next week, and then fixing it.
Problems, and the Future
I ran into a performance issue with rendering and processing so many tiles this week. I did kind of expect it occur though, as I was lazy and wasn't checking whether an object was actually visible on the screen before it was processed or rendered. Once I actually started doing this performance was much better. The number of physics actors I have, that are all being processed when they're visible on the screen, will also be giving me a performance hit, as each tile is its own physics actor. Ideally, rather than having every individual tile be its own rectangular physics actor, I'd be linking tiles that are next to each other to create a single polygon. Individual rectangles is certainly easier, as it allows me to take advantage of SDLs built in rectangle functions, but is giving me an obvious performance hit. Changing it would require a rewrite of the collision detection, as that is based around rectangles, but I'm not sure I'll have time.
Performance of the release build, and the debug build with no debug text is still perfectly fine, but the hit that I've taken since adding so many more tiles has me slightly concerned for the future. The release build used to run at over 4000 FPS, now it runs at around 1000 or less. In debug, without debug text it's sitting around 200-300, with debug text we're around 50. What will happen when I add enemies, coins, background art, get parallax working, etc. Will it still be fine? The machine I'm working on is fairly high end, how will it run on lesser machines? Is it going to get rather difficult to play with debug text on once everything else is added? These are the kinds of questions I'm wondering about for the future, that I won't really know the answer to until I get there.
This problem isn't entirely unexpected, as I did wonder if I would run into it down the line, given that I'm using SDLs built in 2D renderer, rather than OpenGL or DirectX. The code is set up in such a way that I should be able to swap out the rendering code for something using OpenGL and have everything still work as expected. I'm going to continue with what I have at the moment, and see how things go once the game is closer to being finished.
Because of this, I don't think it'll be ready for a commercial release when I finish. Depending on where it's at, I think I will need to change the rendering in order to accomplish a product that can smoothly run on as many machines as possible. This isn't really that disappointing, as I know that having a commercially ready product is a pretty ambitious goal for one programmer. Maybe I'll look at doing a small Kickstarter campaign, or be lucky enough to find a publisher willing to fund me for the rest. Who knows!? I'll see where things stand in a few months.
Regardless of these problems, I still feel like I’ve made pretty good progress this week.
What's next?
The last alpha milestone is due in a couple of weeks, so in that time I'll be working on perfecting/fixing the physics and movement, trying to remove things like the aforementioned jittering and making sure the player character moves around appropriately. I still need to add more debug console commands and document them as well, I've been a bit slack on that and still haven't done it. Having those extra debug commands will be useful, and it will give the tutors something extra to play around with I hand in the milestone.
I also want to look at doing a couple videos showing off what I have so far, both in the editor and the game. I have Fraps, but I don't know what good and free video editing software exists, so if you know what's good and free to use, let me know if any of you guys know one please.
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!
