David Kendall

Another 7 days have depleted from the Dream Build Play counter and I've been working on my entry over the weekend. Did I accomplish what I said I was hoping to in my last post? Not quite. But I did accompish something.


To the untrained eye, this screenshot would appear that I have done nothing. But this is not the case. I have moved the programme slots up by a bit and made the button prompts smaller :) I have also made it so the correct button prompts appear based on what programme the user has currently selected. I still need to add the additional information panel, but the menu is coming along.

But what good is a menu if you have no game to play, which brings me onto my next screenshot.


They say a picture says a thousand words, but with this picture I don't think that's the case. This is my loading screen for when loading up the main game. Following my television theme, I have gone for a loading screen that represents a network splash screen. These are the things that appear just before a programme begins. On this screen, the different coloured bars move from side to side while loading, but then slide into position once the game has loaded. I think it's nice and effective in motion, but this screenshot does not do it justice.


The last screenshot is the beginnings of my character selection screen. As you can see I've started designing my assets. This was a right pain as Blender (my modelling program of choice) as changed its interface since I last used it, so a lot of time was spent getting to grips with that. The functionality on this screen is basically in place with the signed in user being able to choice random avatars or their own (as long as they're signed in). The next step will be to produce the rest of the game assets and produce some on screen prompts so the user knows what to do on this screen. I also want to make it so that the user who initialised the game is already signed up.

The result of this weekends progress has lead to me realise that I will need to be doing more work on the game than initially wanted. This will take effect as of next week, as this week I'm hoping to do a bit more work on my platformer and I will not be present at my computer this weekend. However, I hope to have the character selection stage finished by the end of next week, with perhaps starting to code the main game. Only 78 days to go :)

Dream. Build. Play. It comes and goes every year. Since I started XNA a few years ago I've registered for every one. All of them have past, none of them have I submitted anything for. This will all hopefully change this year. This year I have made a promise to myself that I will submit something, and to make things even harder I've given myself the task to create it from the date of registration to the date of submission to complete it. This means that when the submission deadline comes around I will be submitting whatever I have done. No matter what!

Will I end up with a good project? I sure hope so. I have picked a concept that I have been spec'ing for a little while now (both in my head and on paper). The concept is simpler to my other project, which will mean I have more of a chance of finishing it. But it will be every bit as fun and interesting. I'm also making things harder by only giving myself the weekends to work on it (freeing up the weekdays for relaxing or working on my platformer still). Of course, when time inevitably starts to run out this will probably change.

So that's the plan and registration has been open for a couple of weeks. So how far am I in the project? To every bit ensure that I finish this project I have started off by making the part that usually makes me stop working on a project. The menu system.

I have an idea about what features I want to include along with a given theme. My game will have a television styled presentation, and I want this to be present from the moment the game loads


This first screenshot is my version of the traditional "press start" screen. At the moment it's not much, but my vision is to have a info-mercial styled intro, based on the channels you get on set-top boxes that explain to their users how to use a remote. I'm hoping this will be enough of a hint to my users in what is expected of them.


This is the main menu. I've based it on a set top box menu system to give the impression you are picking a show. This screenshot is a bit outdated as there really is only a planner and settings screen. But the idea is there.


This is how my planner started out. A simple screen that showed a handful of "shows". Each show would represent a different mode of play. But I felt that this didn't show enough information to the player. It also had a bit more of a metro twist feel that I felt might not go down so well with the big M.


And this is how, near enough, the main planner will look. As you can see it is more feature rich. I'm planning on adding an info screen, which will display more information about the selected show. The first four shows on the first four channels will now represent the different game modes that can be played and the rest of the shows will contain a mixture of fake mockery shows and possibly other Indie games.

So there's a glimpse into what I've developed so far, but there's still a lot more to do. It's not got quite the polish I'm wanting at the end, but the main functionality is there which is the main thing.

This weekend I hope to design my loading screen and the player select screen. So you could say the menu isn't finished. But to me it's definitely a step in the right direction.

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).