David Kendall

April Fools Day. A day filled with press releases and videos bringing dreadful (and sometimes hopeful) anouncements in the gaming technology industry. In a day full of fake announcements and practical jokes I executed the primary purpose of my platformer game.

Around the beginning of last summer I had been with my girlfriend for just over four years. We had just moved in together after we had spent the majority of those four years apart maintaining a long distance relationship due to attending different universities. I knew what I wanted and I knew I wanted to ask her that very special question in a special unique way. I wanted it to have my stamp of "geek" on it. I had some big ideas; many of which were out of my league of ability. So I settled on building a platformer and started some work on it in the summer. At the time of starting I didn't really know what I was going to do with the game, just that it would be involved in some way. PAX then came around and another developer had a similar idea. To be honest I was miffed. I no longer had that, what I considered, unique idea.

Months passed, and I had abandoned development on my platformer and was desperately trying to think of another idea that was equally "me". But for everything I came up with, it just wasn't as good as my original idea. In the end I decided to carry on developing the platformer, but I still didn't really have an idea of what I was going to do with it. The only thing I really knew I wanted to do was have the level that she would play spell out the question that was on my mind.

However, one day I thought of the old saying "It's not the destination that matters, but the journey" (I'm probably paraphrasing). Eureka! What if the end of the level isn't the question, but the level itself is. So I started work on building the items I needed to pull it off. I wanted sign posts that could say the words that I would inevitably mess up. I wanted collectables that represented key elements of our relationship. I wanted her to be in the game and for me to be there at the end. It was all in there, and I still got those words at the end that I knew had to be present all along...


Yesterday, she played this level. It was painful to watch if I'm honest because I didn't know how she would react to the game. It was positive and the response I receieved was what I was hoping for. For once there were no fools present on this day.

As mentioned in my Dream Build Play entry update the past week I wanted to put a few more touches on my platformer before I put my focus on my entry in order to have it be something I would be proud to submit. As I've been adding new elements to my game I've been noticing more and more of a little detail that has been missing. I've put it off for as long as possible, but wanted to get the foundations added before I started anything new. I'm talking of course about the background of the levels.


This past week I have been working on two upgrades. The first is a scalable background where I can shift the background between day and night time scenes as shown in the above screenshots. Me in my little bubble thinks that this a) makes the game more polished and b) results in levels that can hopefully be even more varied in the scenery. I'm hoping to include a sun and moon that will shift approriately with the background as well.


The second thing I added is the formation of clouds. These clouds shift from one side to another and have been set up so I can vary the density and speed on a level basis. Obviously this addition is more appealing in motion.

Obviously these additions will help make the game more polished in the long run, but why was I in a hurry to get them implemented this week when other things that would be more beneficial are still outstanding (like a menu system). Well, the answer to that deserves a post of its own...

Having just finished the second part of what I changed during my big change up in January, I thought it was about time for an update of what I've been up to for the last month. If honest, I haven't done as much game development as I would have liked, mainly due to feeling quite fatigued from spending too much time in front of a computer screen. But also because I haven't been in the mood due to me having a few bugs and issues that were making me give up.

These issues being collision detection (again) and graphical glitches. The graphical glitch was inadvertently answered while watching an episode of Indie Chatter (Great video log by the way) and ended up being a simple rounding error which was caused by my 2D camera. So that was nice. But collision detection I just couldn't get right. I either had it working with perfection, but having the camera dip as my avatar ran. Or I had it not as perfect, but having the camera stable. Then it occurred to me; why should I only have one method or another. So now I determine the collision code as I see fit and have the less perfect collision detection for ground tiles (the ones that were causing all the headaches). I also had issues with collision detection against my moving platforms and transfering its velocity to the player to make sure they were pushed by the platforms. This again has now been fixed.

So once those glitches were fixed, I was then in the mood to create new things. One thing that has been added is to have the level pan out once you reach the end of the level. This is how I took the screenshot of the title picture. I've added this because I thought the player might get a level of satisfaction out of seeing what they had just completed. Althought this might come back to bite me if I decide I want collectables that are hard to find.

The second thing I have created is a lever that can be assigned to any number of other interactable tiles. Currently I've only linked it up to a movable platform which can be turned on and off, but it has been designed in such a way that it could easily be linked to other tiles. Below you can see my avatar pulling the lever (using the stock "pull" animation from the avatar animation pack).


But this has lead me down a difficult road with having the avatars as the main character. Unfortunately, the only way of creating animations is by having a nice expensive piece of software (i.e. Maya or 3D Studio Max). A free piece of software did once exist, but has since been revoked. This means that I'm currently building my assets against the animations that come in the avatar animation pack. At the moment this isn't a huge problem, but could become one for any of the future tiles I might create. This has definitely widened my eyes as to why so many avatar games have such a limited supply of animations.

In the coming weeks I hope to implement an interactable button that will act as a different kind of switch and hopefully the main menu and pause menu. This will hopefully make me more productive when testing levels and also get it out of the way before I've completed all the fun tasks.

Man am I not very good at keeping up with blog posts. Apologies. So here we go, part two of what I changed about a month ago, and case you've forgotten what this was all about here's part one to remind yourself.

What's Changed

Tiles and their interfaces

How It Was: Interfaces are great. They are C sharps answer to multiple inheritance (granted not a very good one). I used interfaces in order to define my tiles and create some commonality between them. This also means that I can deal with all tiles by just casting to their inherited interfaces and performing code based on the cast interface. An example would be an IAnimatable interface that is applied to all tiles that animate. By casting to this I could animate all animatable tiles.

The problem with this approach was that I was safe casting each tile (using the as keyword) in the level to my main interfaces and then performing interface logic to the tile if the cast was successful. However, this is a very expensive thing to do as I was casting each tile about 5 different times every frame. So what could I do to keep the greatness of interfaces but reduce the expensive calls.

How It Is Now: I have exactly the same interfaces that I had before (plus a few additional ones), but I now have some "cheat" properties on my base interface; ITile. These cheat properties tell me if the given tile implements my main interfaces (e.g. movable, interactable), which are set up during construction of each tile. This means that I no longer have to safe cast in my main game loop, but instead check the respective cheat property, which is just a boolean value and therefore much cheaper and has helped to improve frame rate.

Updating every tile every frame probably isn't the best idea

How It Was: On each update call in my tile engine, I checked collision between the player and each level tile and performed interface specific code on each level tile (using the old method). As you can probably see this can get quite costly, especially when most of the tiles aren't visible to the player because they are off the screen.

How It Is Now: Now whenever the player moves I update a global variable that stores the min and max X and Y co-ordinates. These co-ordinates specify the area of the level that needs updating and drawing. I've currently set this catchment area to two screen widths/heights surrounding the player. Ultimately, this could be further improved by reducing the catchment area for the tiles which are drawn, but as frame rates are holding up there's no need at the moment.

Reducing and refining collision detection checks

How It Was: I used to update the players location, first along the X axis and then along the Y performing AABB and PPC checks against each and every tile in the level for collisions with each change in the players location. Once I built a level of any size, I realised I needed to reduce these checks, so I reduced it down to only be done on the tiles that were visible.

How It Is Now: These checks, while not needing to be reduced due to the first AABB check, were still to much. So I have reduced the number of checks to only tiles that surround the player. However, because not all my tiles are the same size (but multiples of 64 pixels), I needed to increase these checks to surround the player of the greatest tile size on the level. For example if the maximum size of a tile was only 64 pixels, then the checks only need to be done one tile deep around the player. But if the maximum size is 128 pixels then the checks need to be two tiles deep. And this continues, but I'm not going to spell it out to you because you are all probably an intelligent bunch.

What's New!

Yes that's right, not only did I rewrite stuff, but I also produced some new stuff. Well, one new thing. Because I was getting to the point where I was adding new tiles all the time, I needed to update my level descriptions constantly. I also needed to create levels that produced different scenarios to squish a few bugs. My levels are structured as Xml documents, and while being readable were not a joy to edit. So until I've created an in game level editor, I needed an out of game editor. So I've developed a level editor using existing software (*cough* Excel *cough*) for which I then parse the document to create my needed Xml document.



As you can see the level editor is very colourful, for which there is a reason behind this madness. Each colour represents a different tile and the contents of the cell describes certain characteristics of that tile (like texture). Considering this editor took my only a few hours to create and is easily updateable for when I create new tiles, I'm pleased. And who knows, maybe I'll get the community (whoever they are) to make levels using this so I can include the levels in future updates. But then again, maybe I'm getting ahead of myself...

As mentioned in my last post over the past month I have pretty much scrapped what I had developed for my platformer and re-designed and re-developed it into a code base that I'm much happier with. Of course, it's not all perfect as there are still some bugs to work out. But I'm at a stage where I'm much happier.

This following post will hopefully give a bit more insight into what's changed on the back end, so the experienced developers can see the pitfalls that I fell in originally and hopefully the new developers can see the pitfalls to avoid. So lets get started.

What's Changed

The Removal Of Individual Textures

How It Was: When I first started developing my plaformer, I was on a coding spree. I was developing new tiles that had different purposes in the game. I had ground tiles that the player walked on, sign post tiles that the player read, collectable tiles that the player, errr, collected. You get the idea.
Each of these tiles had an associated texture (or textures for some things like ground) and each of these textures were seperate files. Now the seasoned developers can see the problem here, and for those that don't you have to understand the way that the graphics device (or possible spritebatch) works. One of these components will batch all calls made with a given texture and process the work load. The fewer batch calls that have to be made, the less work the graphics processor has to do, which results in better frame rates (to a certain extent).

How It Is Now: Following advice that I saw countless times but ignored in the AppHub forums, I decided to put all of my tile textures into a massive texture, also referred to as a sprite sheet. This resulted in less batch calls to the graphics device and helped improve my frame rate problem. In order to achieve this I had to improve my internal base Sprite class to support displaying of areas of a larger texture (now referred to as TextureBoundingArea), but this was a small change. I also had to change the way my texture manager worked, but this was getting changed anyway due to the following problem...

Updating My TextureManager To Be More...Flexable

How It Was: One of the goals of mine was to have multiple textures for given tiles like the ground, but then to also have a number of effects I could apply to that texture to make it appear different but be the same texture. This was done via the texture manager and each tile had a number of different effect collections. These effects only consisted of the in-built SpriteEffects and rotations at 90 degree intervals. The problem came to how I was defining these effect collections. Originally I was defining them in code in a static constructor. While this isn't necessarily a problem, I was finding it one as the code was getting unmanageable the more tiles I added, so I decided to change it.

How It Is Now: My TextureManager has had a rewrite and now contains effect collection information (as well as texture locations) for each tile type in an Xml file. This meant that all initialsing data was seperate to the code (as it should be) and could be easily edited with help of an XML schema. This information is then loaded when a level loads and is stored against the type of each tile. This is done by having a node in the XML that is the name of the tile, for which I use the Type.GetType method passing in the value in the XML node.

Seperating Visual Texture Information From Collision Texture Information

How It Was: The collision system I use for the game is a combination of Axis-Aligned Bounding Boxes (AABB) and Pixel-Perfect-Collision (PPC). This is where collisions between the player and the suspecting tile are checked first against each other bouding boxes. If an intersection appears between them (i.e. where the two boxes cross), PPC is then performed when the overlapping of two texture pixels are checked. The reason this is done is because PPC is an expensive process and only needs to be done when we are 90% sure a collision has occurred. The code for this method was taken from the AppHub where they provide an excellent example (one I even believe has been stolen and made into a WP7 game). This resulted in me having a texture that represented the tile visually as well as being used for collision code. This presented some limitations in my tile design and meant I couldn't do nice visual things like having grass from a ground tile cover the players feet.

How It Is Now: I now have two sprite sheets in my game. One sprite sheet represents the visual-ness of the tiles (now with grass on the ground tile) which can have the visual effects mentioned earlier applied to them. The second sprite sheet represents the collision texture which is used for collision detection and is stored, like the effect collections, against each Tile type. The TextureBoundingAreas then match across both sprtesheets so I only have to define the area once in the XML document. The result of this is two fold; a) I can add visual flair to the visual textures like my wanted grass and b) I can increase the collision area of a tile so that a collision occurs before the player collides with the visual texture (like for an interactive item).

That's it for part one. I'll try and write up part two which will include more changes, some additions and a few things yet to be implmented. Have a good weekend.

...Throw it all away and start again.

As you can see, it has been around a month since my last blog post. As mentioned in the last post I was hoping to get animations implemented in the game. I started implementing this, but I really wasn't happy with the way my code was looking.

When I started developing this platformer, I did something I hadn't done before. I planned. Yup, I bought a pad and started writting notes and "desiging" it. However, you can design until the cows come home (one of my mum's phrases there), but there are some things you can't plan for. This lead to me shoehorning things into place which resulted in badly designed code.

So when I was implementing the first set of animations, I took a step back and decided to scrap what I had done before. Now, a month later, I am at around the place that I was when the last post was written. But the code I have is better designed and I have a lot more flexability in what I can create art wise. I have also built an excel based level editor so I can create levels quickly until I've built an in game editor. If you are interested in what changes I made and what design choices I fell a victim to, I will link to the article once its gone liveThe first part is available now.

In the next month, I hope to do a few things. Firstly is to fix some bugs in the collision code that I have implemented currently and create a few more in game objects. I also hope to build up a main menu system so I can change levels on the fly. Remember to keep up to date by following my twitter account.

Hello all! Happy belated new year. Hope your holidays were good. Sorry about the lack of posts, but I've been a bit busy what with going to london to see a comedian, Christmas and a lot of new games to play. While on my christmas break, I was also hoping to make a bit more headway with development, but alas that did not occur. You see, I was at my parents house for christmas. So I decided to grab all the code I needed off my desktop and put it on a pen stick so I could work on my laptop. However, I'm a bit stupid and instead copied the data over and then left the pen stick in the computer. Whoops!

However, before the holidays I did manage to track down what was causing the low framerates (as mentioned in my previous post). After downloading a few profiling tools I determined that none of my code should be causing significant slow down. So I searched the XNA forums for low framerate which brought up a post by Shawn Hargreaves that stated that IsFixedTimeStep should be set to false on the 360. I tried this and found out my game was in fact running at about 36 FPS (using my FrameRate counter). Which is a lot nicer than the 2 I was previously getting. Lesson Learnt. As for what is causing this framerate I do believe its my design by having lots of interface casting every frame, which means at some point in the future I may want to rethink this approach.

I've also learnt that Windows Phone will be included in the next Dream.Build.Play contest; a contest I have yet to enter. This has lead me to thinking about ideas that I may submit (if time permits), which I will share if they come into fruitation.

My objective for the weekend is to get Xbox 360 avatars implemented into the game with hopefully some animation (probably using the sample on the App Hub). I will also hopefully make some more headway on the promised code sample, which is being a bit more complicated to talk about than I thought (hard to describe my method of madness).

So another week has passed and some more progress has been made on my plaformer game. Granted, not as much progress as I would like but this was due to visits from parents and inlaws along with christmas parties. Dressing in a suit makes me feel uncomfortable.

This week I decided that I had reached a good milestone with content that I should see how the game performed on my target platform, the Xbox 360. If you have been following my twitter (which you should as otherwise I don't know how you came across this blog), you would know that it didn't go quite to plan. After some re-giggling and realising some of my design decisions made no sense with what I was creating, I am at a point where collision detection works well, updating of objects works well...just not both together. So my objective this week is to rectify this, along with getting avatars implemented in the most basic way into the game. I should also be releasing a new code sample this week at some point, and it will be a two parter...

And so with my lunch break coming to an end, so does this blog post. Keep reading and following...

Thought I would post a quick seperate update to accomodate my recently published code sample. My project focus and switched from my WP7 based project to another one of my projects. The newly focused project is a platforming game that I started (for about a week or two of consentration and then re-focused) back in the summer. To avoid stagnation, I have picked up from where I left off and continuing to build up the various components. So far my game include a ground, start/finish points a basic checkpoint system (which may need improving in the future), a collapsable ground, a moveable platform and a sign post which will include information to guide the player through the levels (or perhaps used for comedic opportunities). The game is tile based and I'm aiming for the xbox avatars to star as the main character. I'm also working on a level editor for the game so that players can continue their enjoyment (hopefully) by creating new levels.

I haven't got any screenshots to post of the game yet, as it still is full of programmer art, but will hopefully have a screenshot to show by the years end. However my focus will no doubt see-saw between this project and the previous WP7 project.