Pretty Bad Ass Games Blog

Today we met and pieced together a fresh deliverable schedule for the remainder of the semester:
13th

Music:
Basic trigger sound effects (dying, jumping, attacking), track one polished

Programming:
Vertical and horizontal scrolling
Player death and spawning
Enemy behavior
Sound trigger

Art:
Instrument attacks
Death animations
Wombot attack

Prototyping levels - everyone build one with game editor

20th

Music:
Title screen music
More sound effects

Programming:
Animation control
More refined music control
Eliminate “flying”

Art:
Title screen
Instrument pick-up items
Begin cut scene work

Finished looking level

Completely playable

(Beta this week)

27th

Music:
Menu screen music

Programming:
Interface functional

Art:
Interface graphics
Finish cut scene pencils
Color sprites

4th
Game complete
Color cut scene

6th
Game Due

Also, have some animations:

Capek’s jump.

B4’s attack.

Totally didn’t occur to me to post it here.

http://acm.jhu.edu/~promit/PBAG/Alpha.zip
http://www.sendspace.com/file/npqkwy
http://rapidshare.com/files/212732028/Alpha.zip.html

One of those links has got to be alive (please try to avoid the rapidshare one). It includes a readme with explanation. Controls are arrow keys and spacebar if you’re working with a keyboard, but it will work with a Xbox 360 controller as well. — Promit

I’ve been alluding to this for a couple entries now, and now that we’re done our alpha presentations, I figure it’s about time to actually talk about it just a bit. The best discussion of the topic is Scott Bilas’ GDC presentation, titled A Data Driven Game Object System. At least the first twenty slides or so…it goes on to cover a rather sophisticated version of the approach that isn’t really necessary for everybody.

Let’s recap a bit. There’s a lot of different approaches to building games. One fairly straightforward one is to let inheritance define the basic object structure. (See Bilas’ slide 7.) I’m reluctant to describe this solution as “naive”, but it is a relatively simple one that appeals to people with a working knowledge of basic object oriented programming. It’s a totally workable solution, too — I know the original Half Life is written this way, and I imagine there are more than enough big name titles that share the basic structure. It’s a solid structure that is easy to understand and modify.

In fact, it’s unfortunately a little too solid, and a little too structured. Bilas explains that in Dungeon Siege, they have over 7300 discrete object classes. Having that many classes in your code would be nothing short of hellish to maintain. And the compile times for seven thousand C++ files would be extraordinarily painful. The resulting executable code would also be huge. And every time a designer needs a new spin on a feature, they have to come to engineering to ask for the tweak, and then wait for a build to finish, and so on. It’s not necessarily a crippling problem, but it’s certainly a pain and it can become much worse.

In Dungeon Siege, they use a component based approach. Day 1, my former employer, did the same thing, and it’s an approach I’ve always been fond of in principle. This game is the first time I’m applying it in practice. It’s important to keep in mind that component systems are not new, not even close. Applying them to games is (or was) fairly unusual, though. Maybe because most game developers are permanently ten plus years behind the rest of the world when it comes to this sort of thing. But as I was saying, this is the first time I’ve experimented with it and the results and been quite interesting.

In our game, there’s no explicit object types. Everything is GameObject, and how they behave depends on the components they contain. The main trick appears to be in setting up an effective communication model. I’m not really sure how to write this yet, so I’m still trying things. For example, suppose you want a component to be triggered on a timer. Do you force the component to watch a specific timer component? Or do you have it wait for a queue to receive a message it understands? Is the queue per object or global? The component cooperation in our game so far is very simple, and I haven’t needed to answer these questions yet. I think they will need to be addressed soon, though.

There are some neat advantages, though. Since you can data drive components completely, simply providing the right mix of components allows for a very powerful system. (Can’t speak to their internal implementation, but LittleBigPlanet takes this really far, in terms of simple bits creating complex results.) The editor also uses reflection (along with C#’s custom attributes) to set up all of the editing interface, requiring very little code to customize large swaths of behavior. Adding pickup items that altered the music was extremely simple, and now practically anything can be set up the same way in the editor. Once the communication system is fully sorted out, it should be very capable indeed.

– Promit

Here are some place-able elements for level one (which still need to be shaded, I’ll do that soonish, but this is how they will exist for the alpha):

Also, here’s a painting I did of clouds which will be the back-most layer of the scrolling background:

The left and right edges of the image are painted to line up so it can repeat infinitely.

I’ve been meaning to post these for awhile and am finally getting around to it - the pencils of all the character’s walk cycles:

Once I get all the sprite animation taken care of then I’ll go back and add in all of the character details (gears, screws, etc.), ink and color them. Next up is jumping, picking up items and attacks. But first I’m going to focus on getting some level components out of the way…

I realized it’s been a while since we actually posted anything, so here’s a shot of the WIP level editor:

Unfortunately it’s still missing a ton of functionality, but that’s okay, it’ll get there soon enough. This is part of our sprint to a playable demo; it’s kind of hard to prototype anything by editing XML files. That’s especially true considering that the component based objects (no, I’m not explaining them yet) take a fair bit of time to set up. This tool will make it a breeze. You can see the Add Component dialog in that shot, and the small handful of base components that are available right now. Here’s some physics editing action:

I just threw in some random geometry pieces to show. This stuff can be set up here, and it will all kick in just like you expect in game — or it will anyway, once I actually write save and load support. The big remaining bit of work is to add support to actually add textures, animations, and game objects, all of which tend to be important for a game to work. The existing world I’m editing has been hard coded in. Once that’s in, and save/load works, we should be able to put together an awesome game side…which I’m hoping Burnest will do a lot of

I love core technology, tools, etc. Making games…it’s alright, but it just doesn’t thrill me the same way somehow. Maybe it’s just because I’m so much better at this side of things. I’ll give my group all the toys they could ever want, and let them sort out the whole “game” thing. I wonder how all you other groups are doing building your toys…I’m looking forward to seeing em.

Oh, did I mention that those panels are all resizable?

First, here are two additional environmental concepts, a more “urban” steampunk and a whimsical steampunk:

Secondly, we devised a schedule of deliverables for every two weeks, figuring upon having an approximate ten weeks remaining to complete this project:

2 Weeks From Now

–Game prototype working and playable.

–First Level painted in its entirity and ready to insert in prototype.

–Character walk cycles completed.

4 Weeks From Now

–Track for Level One sliced up and installed.

–Player death with eliminated track.
–Ability to pick up items and add to the track.

6 Weeks From Now

–Interface complete.

–Menus complete (with music).

– All sprite animation complete.

–Level 2 painted (with corresponding track).

8 Weeks From Now

–Sound effects to accompany all animation.

–Jumping puzzles fairly developed.

–Make game FUN.

10 Weeks From Now

–Level 3 (tentative, time allowing).

–Cut scenes (also tentative).

–All sprites inked/colored/cel-shaded.

–Polish game, fix bugs.

Yeah, okay, so I stole the artwork out of the platformer sample that Microsoft ships, but we’re still basically in concept art phase anyway. There’s four layers here — three background layers and then the actual level layer (rendered in the glory of dark blue bars). The various layers support parallax scrolling, so the sky is shifting at a different rate than the trees for example. The source artwork actually splits that temple thing in half through the middle. Here, look (actually click on the thumbnails):

I’ve JPEGed them, so some subtleties of the transparency in the original PNGs are gone, but you should get the idea. (They’re a third of the size in bytes this way.) The graphics underneath are still a bit hacked up, but I’ll clean it up eventually. I’ve got more important things to handle right now, like building an actual editor so that I can stop hard coding the level platforms.

By the way, collision is in, so you can run around and jump on things and such. That is not faked, and in fact works perfectly. It’s still a bit glitchy and needs tweaking, but it is basically playable! More on the details of that later, I’m holding it as an ace up my sleeve for the moment. Wouldn’t want to pack too much into one blog entry anyway.

Hey team,

So I finished up another song for the game last night.  Its got a bit more rock elements in it or…well it has an electric guitar sound but either way it turned out pretty cool.  Its up on my soundclick (www.soundclick.com/griffincohen).  From time 1:42 until the end I think is where I would imagine the boss fight of that particular level to be..the music is pretty much as maxed out as I want it to be and has a longer loop time with some more driving melodic elements…anyways, let me know what ya think.

I had some more entries in mind for tech stuff that go into more detail, but I think for the time being I’d prefer to discuss how technology and prototyping connect. One of the principles that our mentor Tim Train has been pushing very heavily is that we should get the game prototyped in a playable format as soon as possible, and start designing the details of the game from there. Rapid prototyping is not something I’m good at; I have a tendency to mull design and engineering at length for the stuff I code. It’s a bad habit, to be honest. Tim’s been very helpful in keeping me focused on the goals that need to be hit.

Here’s an example. I have a very basic rendering prototype going that I threw together in XNA between some other homework to test a couple things like the game object system (more on this in a later entry) and animation and such. The prototype made it fairly clear that I’d need to write an explicit finite state machine to control animation transitions properly, and I was planning to have this done for Monday. Tim pointed out to me — and it should’ve been obvious in retrospect — that this is a waste of time right now. Prototypes don’t need animation, they need to be playable, and animating stuff is just visual fluff. So now I’m switching gears, working on implementing collision and basic world structure so that by next week there’s actually something resembing a playable game.

There’s a couple interesting things about prototyping. First of all, it’s important to strip your technology way back, to just the bare essentials. It actually forces you to focus on the very heart of your game, instead of the rendering technology or collision trees or any of that. You also don’t really need any support at all from art or music/sound for a while, because you can just put in placeholders. It’s a very coder-oriented phase of development, and goes well with concept art, concept sound/music, etc in terms of timing. Just like those pieces don’t need code support, a prototype doesn’t need any art support and so your teams (in a production title) can work independently in their own schedules.

That’s all missing the point, though. The key to a prototype is that it strips away everything, and I do mean everything, that can distract you from the real question:

Is the game fun?

Nice graphics is great. Nice sound is great. But it doesn’t make a game. (It can break a game, but that’s a separate problem.) When you have something as barebones as a prototype, you discover if the core element is fun or not.

The Hunt Valley area, about twenty miles north of Baltimore, is a hotbed of game development. Firaxis, Day 1, Big Huge, Zenimax, Bethesda — they all have offices there. These studios are all basically spinoffs of the old Microprose company based up there, and Microprose is well known because they produced the Civilization games, designed by Sid Meier. What many people don’t realize is that Sid isn’t just a designer — he’s also a programmer. He coded the original Civilization himself.

Why am I bringing this up? Well, Sid Meier is the God of Prototyping. He prototypes basically every game that will eventually go on to be a big budget “Sid Meier’s X” game, and he does it fast. Terrifyingly fast, in fact. I’ve heard stories crediting him with building entire games, approaching ten thousand lines of code, in a single weekend. There’s no real engineering to speak of; these games are apparently usually centered around a single massive (thousands of lines) DoEverything function that drives the game. There’s no design, no architecture. He just makes things work.

I’m not good at rapid prototyping, and that’s unfortunate because I think it’s a critical skill for a developer to have. That goes double if you’re interested in doing independent/small team development (which, if you have a hit these days on the iPhone or Xbox Live, is worth a cool half million or more). Hopefully I will get some serious practice in this weekend, so that when people want to know what I’ve been up to, all I have to do is hit Run and spin my laptop around to face them.