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