Dream.Build.Play dev diary 4

Well if you couldn’t tell by now, this game wasn’t finished in time for Dream.Build.Play  submission. I actually had the game working correctly, but didn’t have anywhere near enough features that I wanted and it was about as bare bones as it possibly could be. I figured “why rush?” and began to take my time as I saw the inevitable deadline was looming closely overhead. I should change the name of this thing, but I’m too lazy, so I’m just going to keep the title of this diary.

I wasn’t aware with 100% certainty of how some elements of my game worked, power ups for example, so I wanted to take my time and really dissect it so that I could take it apart and analyze it a bit more. Besides, what’s the point of implementing something if you are never truly learning from it?

Particle Effects

I finally have some graphical improvements worth showcasing, in the form of particle effects.  I tried a few different methods and systems to get it working within my game before finally settling on RB Whitaker’s 2D particle engine. I found it to be one of the most simple particle engines available, in addition to being extremely easy to use and build on. I did get caught up briefly when initially trying to put it in though, as I first tried to draw particles to my menu screen when the game launches, but for some reason I couldn’t get them to display.

I realized that I was placing it in the MenuScreen class instead of the Background class, which is what the player sees as soon as the game launches (doh!). To compound things, once I placed the code in the correct screen, it still wouldn’t draw. I was certain that I had everything in the correct spot this time and wasn’t receiving any build errors, so I was ready to give up. Instead, I restarted my computer and it worked fine. Go figure.

Particles are now fired each time the ball and bats collide which adds a nice dynamic to the game. I also plan on including a trail for the ball as it darts back and forth across the screen, but I’ll play with that later. I know that there are a few ways to make this happen, such as drawing the previous few frames where the ball appeared and adjusting the alpha for each one so that they create a nice ghost effect, but a simple particle  effect is preferred.

Creating and Loading Various Levels

This is something that has been holding me up for quite some time now. I have one stage completed and I’ve just been using that as my default level to play on. It simply consists of two paddles, (one for the player, one for the AI), a ball, and a background. I know that I could easily create more levels by just creating a new screen, (eg. Stage1Screen.cs, Stage2Screen.cs, etc.) but that can quickly become tedious and turns into quite the project as I update my logic while building the game.

Instead I soon discovered that I would need to create a custom content pipeline for my stages (I use stages / levels interchangeably, perhaps a relic left over from my NES days). This could be done with something as simple as a text document, or XML, which I would prefer as I find it far easier to read and comprehend. I stumbled across new terms like serialization, design-time components, and understanding XNA’s content pipeline and processor, and content loader.

As I mentioned in an earlier post, I came from a background in the Unreal Development Kit, which is far different and most of this is handled for you automatically. You would simply use their content browser via an easy to use GUI, and import your assets that way. The .FBX importer pipeline made it even easier if you were using Autodesk products like Maya or 3DS MAX, as it would bring over all of your textures, animations, collision data, and models in one fell swoop, so there was really no need for me to ever learn any of these terms. Furthermore, XNA serializes your assets into a compact binary format (.XNB) which can’t be used in any other runtime library, but fortunately former XNA team member Shawn Hargreaves has an excellent blog which detailed how all of this works and it helped me considerably.

I stumbled across Nick Gravelyn’s Tile Engine Tutorial on YouTube by sheer coincidence one evening and found it to be invaluable as well. While there wasn’t a GUI where you could drag and drop tiles, at least as far as I watched, so all of the level data was loaded through an array. This seems like an arduous process to say the least, especially when coming from using a level editing tool like UDK or Unity, but it really allowed me to understand how editors worked though, so it was quite beneficial. I’d highly suggest taking a look at it.

I still haven’t found a solution that works best for me just yet, but I plan on coming back to this at some point in the near future. I’d rather move quickly through the rest of the project and come back to the things I get hung up on at a later date. RB Whitaker hosts an excellent wiki that I’m a frequent visitor of, and I came across his Realm Factory level editor which seems to do what I need in terms of level creation, but I haven’t put much effort into it just yet.

In Due Time

I commonly go back to read old books just to grab some ideas and find that I read James Silva’s book far more than most of the others. Granted, It is the only Kindle book I own, so it makes it easy to access on my iPhone, so that may have something to do with it. Despite writing it for the XNA 2.0, I still find that most of the code still works, but more importantly., there are a ton of great concepts that he quickly adds to the game he is creating within the book. One such concept is playing with the game’s timing values.

I thought it would be neat to add a slow-mo feature as part of a power up, or perhaps part of a special move, where once triggered, the screen would blur, all items on screen would move at ¼ speed, and a deep “swooooosh” sound would be set off. Is it necessary to the game? No, not at all, but it furthers my understanding of the framework and is a useful concept for me to delve into. That’s today’s project!

While there is a big debate of the use of fixed time step vs. a variable time step, XNA fortunately has ElapsedGameTime, which is a property of GameTime, a fixed-step update, which is used in my GameplayScreen. GameDev.Stackexchange.com has a brief but excellent question which outlines exactly what I was trying to do, and other developers have confirmed that it really is this easy:


void update(float elapsedTime){     elapsedTime *= timeScale;     // update code     animation2.update(elapsedTime); }

That’s all for now. I should have some more up in the next two weeks or so. I plan on making this open source for anyone to poke fun at or even grab and use for their own projects, once it’s complete. I figure it’s the least I can do for everyone in the community who has helped me along the way.

Parts 1-3 can be found below:

Part 1 
Part 2
Part 3



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.