Both Retro City Rampage and myself will be in Madrid at iDÉAME April 14th and 15th! You’ll get to play it on the Wii (courtesy of Nintendo!) . I’ll also be speaking about the game, its development and the industry, along side Magnus Palsson (DistractionWare, VVVVVV) and Jools Watsham (Renegade Kid, Mutant Mudds). It’s going to be fantastic, can’t wait!

More info: http://www.ideame.es/

It’s been an incredible year of non-stop development, events, speaking and learning.
Retro City Rampage has come a long way, becoming the massive game I always dreamed it could be. It’s packing over 50 story missions, over 30 arcade challenges, over 25 weapons and power-ups, over 40 vehicles, a massive interactive open-world to explore with over 70 interiors, over 100 character customizations and crazy crossovers including a ‘Splosion Man one. You’ll have hours upon hours of fun with it, guaranteed.

I can’t even begin to tell all you just how much appreciate your patience. RCR’s finally near the finish line but as it’s being developed almost entirely by one man (from programming to design, business, PR, etc.) things have taken quite a while. The game itself is nearly done but many business tasks, much testing and some platform requirements still need to be taken care of. Behind the scenes, I’ve had to battle many major bumps in the road over the past few years, including very recently. However, I pushed though them all and in the end everything’s turned out for the better. Even more great things are happening right now which I can’t yet announce, but what I will say is that when the game finally launches, nearly EVERYONE will be able to play it

I wish I could announce a release date but even when development is complete, games must go through testing and certification, then sit in a waiting list for a release week. Until this is underway, a specific release date can not be announced, but again I really appreciate everyone’s patience.

Have a great holiday,
Brian

PS. Don’t forget to download all of the free stuff from music to wallpaper and an SMS inspired game case, here.

DevHour, Mexico’s game development conference began yesterday, garnering a fantastic turnout. There’s so much passion here and potential for success for the talent in this country, everyone’s so hungry to learn which is fantastic. I’m already excited about returning next year.

I’m very happy to have been given the opportunity to speak at DevHour, both in panels and in giving a full lecture in the amazing auditorium. The two panels yesterday went very well and I’m happy to have been able to share new insight and knowledge that will enable developers here in Mexico to achieve greater success both in releasing their game and designing it. This afternoon I will be performing an hour long lecture on the development of Retro City Rampage and how small teams can automate their processes to achieve more, which will be followed by another panel.

GameCity, UK!!

Next month in Nottingham, UK between October 26th and 29th I will be at GameCity developing a game live using art that you, the attendees draw! More details to come.

Watch last year’s Make A Game In A Day, here!

Go Minecraft!!

Following that, in November I and Retro City Rampage will be at Mojang‘s MineCon in Las Vegas November 18th and 19th. I will be speaking and the game will be playable by all attendees.

Huge thanks to Mojang for the opportunity!

Lots of exciting stuff happening! Be sure to come out and say hi!

Join Destructoid and several wonderful indie game companies for a pre-PAX celebration!

The Super Indie Friends Mixer will be starring many special guests…

• us! Vblank Entertainment (Retro City Rampage)
• Twisted Pixel (Ms. Splosion Man, The Gunstringer)
• Hello Games (Joe Danger)
• Halfbrick (Fruit Ninja)
• Zen Studios (Pinball FX)
• RedLynx (Trials HD)

Meet us! Say hi! We might even have prizes that you fans would love

The mixer takes place at Gameworks from 8PM to 12AM where the various developers on all these game franchises will be hanging out along with various Destructoid personalities. Plus, Gameworks is filled with a ton of arcade machines so there’s going to be something for everyone here.

More Info Here.

Also, Friday August 26th!
Fangamer and is hosting a party!

FREE with your PAX Badge, otherwise $15 for tickets.

More details here.

Be sure to support Retro City Rampage and purchase the awesome Fangamer shirt, poster and pins to help fund the final crunch to finish and release the game.

Grab them here.

Learn how Retro City Rampage was made!

I’m also on a panel later that afternoon with other very talented indies including Jamie Cheng of Klei Entertainment (Shank, eets), Jake Birkett of Gray Alien Games, Shane Neville of Ninja Robot Dinosaur (Ray Ardent: Science Ninja) and Rick Davidson of Inspirado Games. Rick and I worked together at Backbone Vancouver years back, and he’s now on a mission creating a new segment of gaming –meaningful games. I couldn’t ask to be on a better panel. Everyone on here has made a mark in game development and have a hell of a lot knowledge to share. I hope you can make it.

See the full PAX Dev Schedule, here.

Details on the sessions below…

Grand Theft Automation:
How One Programmer Developed Retro City Rampage

Grand Ballroom A
Thursday, 10:15am – 11:15am

This talk covers the key techniques which enabled a lone programmer to build the multi-platform, multi-award winning open-world game, Retro City Rampage. The panel will cover: use of automated debugging, building more efficient tools, implementing simple features which save weeks of work later and leveraging existing functionality for multiple features.

While developing Retro City Rampage, Brian handled all of the business, marketing, design and most of the art along side the programming and tool development. It was a lot to juggle, making the process of automation critical.

Attendees are given an overview of the techniques used to build a large game more efficiently. They will get a peek under the hood and techniques they need to apply these practices to their own games.

From the Cubicle to the Basement: Corporate Devs Go Indie

Grand Ballroom A
Thursday, 4:00pm – 5:00pm

A frank and open discussion with a panel of game developers have left successful careers in the traditional studio model to go out on their own as indies. The road to independence is a rocky one and the panel will share their experiences, good and bad, while giving advice to other developers contemplating the leap.

This is a design pattern I really like because it can produce much more bulletproof code. It makes your life far easier because you don’t need to worry about one system restoring the state properly for another, or another assuming the state incorrectly. It also can make code more efficient by eliminating the need to do multiple tests (ie. IsGamePaused() { return IsThisDoingSomething() && ThatDoingSomething() && etc.; }).

The example here is for the game pause state. RCR’s pause state means that the gameplay doesn’t run but everything else does. This is set when the player brings up the pause menu, when a cutscene is active, when a UI screen/minigame pops up, etc. So, to keep things nice and clean, I set up a bit for each. The game stays paused if any of them are still active, unpauses when all of them are deactivated.

Example code:
// TIP: Use enums instead of defines when possible for better debugging/intellisense
// and instead of consts when possible to avoid a bajillion startup constructors
enum mGamePause
{
    mGamePause_PauseMenu = 0x80,
    mGamePause_Cutscene = 0x40,
    mGamePause_UI = 0x20,
    mGamePause_Freeze = 0x10,
    mGamePause_Reboot = 0x08,
};

/******************************************************************************/
// by feeding in an enum it ensures you'd get a compiler error if you tried to pass
// something invalid, although it prevents you from setting multiple bits at once
// without a cast
void Game::SetPaused(mGamePause pausebit, BOOL bWantPause)
{
    U32 newstate = (bWantPause)? (m_mIsPaused | pausebit) : (m_mIsPaused & (~pausebit));
    SetPauseState(newstate);
}
/******************************************************************************/
void Game::UnpauseAll()
{
    SetPauseState(0);
}
/******************************************************************************/
void Game::SetPauseState(U32 newstate)
{
    if(newstate != m_mIsPaused)
    {
        if(newstate && !m_mIsPaused)
        {
            // do stuff when paused for the first time
        }
        m_mIsPaused = newstate;
    }
}
/******************************************************************************/


I use this whenever I can. It ensures more robust code which is less prone to bugs, being another way a lone coder can build such a massive game. It’s what I do and you can too!

Those who have been waiting since the initial announcement in 2004 and missed the GDC talk this past February can finally see Grand Theftendo in action.

The precursor project to Retro City Rampage, Grand Theftendo was an unofficial demake of Grand Theft Auto III for the actual Nintendo NES. Although never finished, it still brought a (simplistic) open-world to the old 8-bit console.

Aaron Kaluszka at Nintendo World Report has done an amazing job summarizing the talk I gave at GDC outlining the project and how Retro City Rampage came about. There’s also lots of info in there on the tools which I built to create both projects and on game design. You’ll also find more videos, screen shots, the world map and pictures of the tools.

You can find Nintendo World Report’s great article here.

BTW, for those curious, here’s what the sprite flicker looked like on the NES. This is one of the reasons the sprites are as small as they. Sprite objects such as cars are built out of multiple smaller sprites. The more sprites on screen, the more it will flicker. The NES could only display up to 8 sprites per line, each sprite being 8 pixels wide, that’s pretty minimal. A horizontal car is 3 of those 8 sprites. More than two cars (or two cars, a pedestrian and a bullet) and you’ll start to see flicker.

Also, check out a video from 2004 of the homemade NES devkit running the game:

I’ve worked at companies where the iteration time was 1.5-6 MINUTES. Some others had experiences where the compile alone took over 20 minutes due to their poor makefile system. Now think about that. When the team is 30-120 people, that’s a lot of time wasted and a lot of money. The money a certain unnamed company wasted waiting while their horribly inefficient pipeline cooked data could’ve funded about 30 World of Goos or Braids. It blows my mind how common this is. Managers and producers are often looking everywhere BUT at the big picture to allocate time to fix these things.They definitely wasted more time waiting for things to compile and pipe than they spent doing OT. I can say that for sure.

Really, these things shouldn’t happen in the first place. It’s often the result of “temporary” code staying in which isn’t architected with the ability to scale well. When I started at that company, a friend of mine said “If I write two lines of code in a day, it’s a good day!”. I thought he was joking. He wasn’t. I then had a saying, “If it seems like people are watching youtube all day, they’re just waiting for a compile”. It was great for me though. I was able to read the entire Gamasutra site. Seriously. I ran out of stuff to read on there and was scouring the web for another equivalent site.

Anyway, ranting aside, the turnaround time on devkits is much slower than PC. So, I do anything I can do to shave off time. Turns out most of the loading time is loading then processing the audio. So, I have three #defines. “NO_AUDIO” “NO_MUSIC” and “NO_SFX”. 99% of the time, I don’t need audio to test things like say, leaderboard code. So I simply uncomment “#define NO_AUDIO” and BOOM! RCR loads almost instantly. Every second counts.

On a side note, having the ability to run the game with NO_AUDIO, which in fact doesn’t just skip loading the audio, it stubs all the functions, is very helpful when porting. Gets you to the instant gratification of seeing it on a new platform sooner because you don’t need to worry about audio initially.

Also note, I define NO_AUDIO in the cpp file, not a header. So if I want to change it, it just needs to compile and link ONE file. That’s how you do it baby! I also split up many headers with the foo_defs.h and foo.h to speed up iteration, but you get the idea.

Although my initial NES effort Grand Theftendo had its missions written directly in 6502, I designed the scripting language for RCR under the mentality that it could feasibly run on the NES if I were to port it backwards. It was lightweight and efficient! However, that being said, this also meant it was simple and somewhat primitive.

But, RCR got ambitious. More ambitious in cinematics. More ambitious in gameplay. These created a number of situations throughout development where the scripting language needed to be extended. New features needed to be added to the language but with time always being the enemy, the simplest approach always needed to be taken. Amazingly though in hindsight, these simple (and often elegant) solutions seem to have been the best anyway.

One example of where I could’ve gone and where I ended up going was for catching events. Given the time and resources, the old me would’ve designed an object oriented language, where I could set up sprite instances each with their own “onAttacked” method, etc. It would’ve been so clean and elegant! But that wasn’t going to happen. What was the core of what I needed? Events of course! So I added an event thread to each script and global event functions such as “on.attacked”. Each event then passes down params which can be used to check which object was attacked. And you know what? Most of the time I’m just checking if it’s the player object, at the most I pretty much check 3-4 different objects, so the single function doesn’t make code too messy. And if it did, I can break the code up into separate function calls (which were another quick hack).

I also made use of the event thread and added callbacks, so for example, when all of the enemies in a group are killed or the player reaches a “go” arrow, the function if passed in will be called. This type of stuff is used for all kinds of things such as waypoints for a car race.

So anyway, the win today was script-to-script messaging. At one point, one of my visions for an ideal scripting language involved implementing a linker so scripts could could share common functions and variables with each other (or at the very least, all have access global functions/variables from a global script). However, this again wasn’t going to happen. Faced with a situation where I really needed to add script-to-script communication to avoid potentially shoddy code, I did the next best thing. I made use of my script opcodes by adding a post.message one, and added an event function which is triggered in the other running scripts. Worked perfectly!

For those curious, the multiple scripts running include one for the region/building/room you’re in and one for the active mission. So if you trigger something that is set up in the room (ie. activating a secret entrance) and the mission needs to know about this, it now makes use of the messaging. Since I didn’t have access to the actual object which was being activated from the other script, I could’ve implemented some sketchy catcher events. Instead of saying “if event.obj == the_obj” I’d need to say “if is type prop and is subtypeand … and …” then stick this into any event would could cause the entrance to activate. Messy code and vulnerable to holes. The simple message is the obvious way to go. It’s all about writing safe, robust, bulletproof code. Cuts down on possible bugs down the line.

After RCR is done I’ll write a whole article on the dozen or so of these scenarios which lead to great progress and robust functionality that didn’t feel like hacks or duct tape.

…and this new functionality took less time to do than I spent writing this article. EFFICIENCY FTW!

Grand Theftendo, the precursor to Retro City Rampage which ran on actual NES hardware.

In the talk titled The Next Steps of Indie: Four Perspectives, I delve into the development of Retro City Rampage starting from the beginning. From December 2002 when I started experimenting with NES programming and sketching a top down Grand Theft Auto III city on graph paper, to building my own tools, programming language, development hardware and announcing my first open world title, “Grand Theftendo” in the fall of 2004. After a number of years of development on it part-time, I decided to do an original game on modern platforms instead, still retaining the vision of an 8-bit open world crime game. This new game eventually earned the name, “Retro City Rampage” and became the nostalgic comedy you’re all eagerly anticipating for Xbox LIVE Arcade and WiiWare later this year.

Grand Theftendo will finally be shown in motion where you’ll see GTAIII re-envisioned in 8-bit. I’ll also show off the tools and a bunch of the source code for the tech savvy! I’ll follow it up by showing off the new tools I built for developing Retro City Rampage!

Below, a picture of the development hardware. It required a few too many soldering fumes and some frozen fingers from a cold garage to build… but was so much fun none the less.

I hope to see you all there. I’m an open book and happy to answer questions/hear about your projects as well.

The Next Steps of Indie: Four Perspectives

Tuesday 1:45- 2:45 Room 135, North Hall

More details: http://schedule.gdconf.com/session/12343