Days of Yore, GDC 2011

Next week is GDC week.  That’s the Game Developer’s Conference in San Francisco.  This is a truly huge event with about 18,000 people in attendance in each of the past three years.  I went for the first time in San Jose about 20 years ago,  and 300 people attended then.

Back in those days is was Chris Crawford’s event,  having started in his living room.  It was called the CGDC  (computer game developer’s conference).  Some years later the “computer” was dropped since most video game development was happening for non-computers like Gameboys and SNESes.  The weird thing is that the proper name should probably be VGDC (video game developer’s conference)  but then again,  in a few years we might move on to holograms of direct brain manipulations,  so the GDC is ready if and/or when that happens.

The good news is that Chris Crawford will again be at GDC this year.  Here’s an excerpt from Chris’s description:

As part of the special lectures around the 25th GDC show, original CGDC founder and Balance Of Power creator Chris Crawford will present a session called ‘In Days of Yore’  explaining how “the earliest days of computer games were times of technological swashbuckling, shoestring budgets, amateur designers, amateurish products, and wild experimentation. ”

I disagree with that “amateurish” characterization of the products of that time.  We were as professional for the standards of those days. At the same time we were furiously advancing the state of the art,  hence the wild experimentation.  Fortunately the spirit of those Days of Yore is still alive and well 25 years later.

–fxl

Posted in Events | Tagged , , | Leave a comment

Tool update: Blender 2.5x

Today’s topic is Blender,  specifically moving from Blender 2.49,  which is what I have been using for about a year,  to the latest and greatest,  Blender 2.56 Beta.  All I can say is,  Wow.  Even though it’s a beta,  2.5 Blender series is a big step in the right direction,  very stable, and well worth the trouble,  at least for me.

The first hurdle was that exporting to Unity 3 doesn’t quite work right with Blender 2.56 Beta.  Unity has trouble with the automatic .blend importing,  so I have to manually export .fbx files instead.  Not a big deal,  but I hope it gets fixed with updates to either Blender or Unity.  I also needed to learn the hard way that you have to select your object before exporting it,  or it doesn’t export.  Makes sense once you know it.

I’d like to give a big shout out to Super3boy AKA Super3 and his very helpful tutorials on Youtube and his website www.nystic.com.  It’s very helpful to see his tutorials when learning Blender,  and,  in my case,  when upgrading to the 2.5 series.

Posted in Tools | Tagged | Leave a comment

Invisible progress syndrome

It’s time to take some time off and learn more about the tools that I’m using.  This can be quite time consuming,  so please bear with me as I might have several days of no visible progress.

It’s a sad reality,  but a reality nonetheless.  Sometimes progress is invisible,  so that means there’s no point in posting a new version of the game.

What kinds of invisible progress am I talking about?  Here’s a list:

  1. learning stuff
  2. rewriting code to make it better
  3. writing new code but it doesn’t work yet
  4. developing new graphics, sounds, etc. that aren’t integrated into the game yet.
  5. Doing some experimentation that fails somehow.

This isn’t a complete list,  but you get the idea.  Just because there’s no new version it doesn’t mean there’s no progress.  Still,  it goes against the spirit of this project to have very much of this.

As I look at the invisible progress list,  only items 3 and 4 stand out as just plain bad.  To avoid 3,  code should be written to do small incremental, testable steps.  To avoid 4 simply stuff the new assets into the game someplace just to look at them or hear them.

Learning, or research,  are often necessary,  but it’s preferable to not overdo it.  Finishing the project has to take higher priority.

Rewriting the code is often better than trying to fix it.  If the code has grown into a tangled mess it’s best to toss it  and start over.

Experimentation will fail sometimes.  If it doesn’t then you’re not doing it right.

 

Posted in Development Tips | Tagged , | Leave a comment

Tools

No,  I’m not talking about the screwdrivers and hammers in Gubble.  It’s the software tools that game developers use.  Even early on during development it’s important to select good off-the shelf tools and to decide on which custom tools to develop.

First,  a bit of history.  In the 80s most game developers used a compiler or assembler and the artists had a paint program.  Sound was often done using custom programming inside the game,  or maybe we had some special audio tools such as RPM (Rusty’s Pokey Music System),  internal to Atari.  In RPM you typed in the notes and their duration,  like this:  C sharp, quarternote.  I spent many hours typing in notes from my piano sheet music collection.  Level editors were in their infancy,  or they didn’t exist at all.  I invented a scripting language on top of FORTRAN to generate the ramps, elevators and other data patterns for the Crystal Castles levels.

In the 90’s we saw the advent of real-time 3D and the 3D editors such as 3D Studio.  At my old company Bitmasters we used 3D Studio to prerender rocks for the SNES version of Rampart.  The first real breakthrough in this area was Donkey Kong Country for the SNES,  with great 3D animation,  all prerendered and stored in very expensive ROM memory.

For the original Gubble in 1996 we wrote a custom level editor integrated with the 3D geometry coming out of 3D Studio. We used the editor to lay out the levels,  then fed them to 3D Studio for the real level rendering.

Now,  fifteen years later, we have a huge assortment of off-the shelf tools available for purchase,  and some very good things for free.  For FatJumper I selected Blender, Unity3D, Visual Studio C# Express and Gimp2.  They are all free,  which is truly great.  It even opens the possibility of letting customers in on the act.  We could,  for example,  allow users to write custom content using these tools and set up a way to distribute this content to the rest of the players.

Still,  there is something to be said for writing a custom level editor rather than just using Unity or Blender to lay out the levels.  This is the approach used by Halo with Forge and in Little Big Planet.

Posted in Development Tips, Tools | Tagged , , | Leave a comment

Game Development when you’re Old

Now that I’ve been over 50 for a while I might seem kind of old in comparison to those other game developers out there. Today, I thought I’d take a break from developing and give some unsolicited advice to you other old timers, you know who you are. You might even be feeling old even though you’re only 26.

I started doing commercial game development at that age. Even way back then most of the other programmers in our group were younger than me, and if you were over 30 that was definitely over the hill. Eight years later when I was in another group we called one of our coworkers “grandpa” just because he was the only one over 40.

So how come I’m still at it almost thirty years later. The answer is simple. I love it. Mainly, I love playing games, designing games and, almost as much, programming. And I can’t stress this enough, I’m not too old for this. Maybe when I’m 110, but definitely not now nor anytime soon.

By the way, it’s never too late to start. It’s much easier now to get started in game development compared to the early eighties. The sheer volume of great introductory books is amazing. And of course there’s a ton of video tutorials on youtube and many specialized sites to help anyone to do this, regardless of age.

The most important thing, other than loving it, is to have a reasonably open attitude towards change. As we get older we have a tendency to latch on to the old and familiar ways while rejecting the new ways. My old friend Rob calls this ossification. So, in a nutshell, avoid ossification. Play some new games, learn a new programming language or two, get out of your comfort zone.

And, as a final thought for today, fight agism wherever you might find it. This kind of prejudice is just as ugly as racism or sexism.

Posted in Development Tips | Tagged , , | Leave a comment

How to start Making a Game

When making a new game, how do you start?

One common way is to come up with a basic idea using words. Something like this: An FPS (that’s a first person shooter for you newbies) where you’re a robot exploring the caves of Venus. OK, that’s a pretty uninspired idea, but you didn’t think I’d reveal one of my many truly revolutionary new ideas just to illustrate this point, did you?

Another way is to interactively develop a prototype and see where it leads. In our FPS example, you could maybe just make a box and move it around some terrain and tunnels. We’re shooting other boxes and make it fun to play. Then later on you add the theme, story, etc., and maybe turn the box into a robot.

We could also start by sketching some stuff on paper to see what develops. We could draw something that looks like a robot in a cave, shooting same space bats and other strange alien creatures.

For truly new stuff I prefer the prototype method. There’s no substitute for getting a feel for the controls early on. For me the heart of most games is the feel of it. If we can get the basic movement and actions nailed down right away the rest can be added fairly easily. Changing the controls later is often difficult and has too many repercussions.

So, my first decision on this as yet unnamed project is to build a prototype first.

The next step is to select our tools. Can’t build a prototype without tools. This one’s easy. I know Blender, Unity3D and Gimp, and they’re all free and amazingly good. It’s especially amazing how good they are for the price. Did I say they’re all free? The only catch (as of early 2011) is that Unity3D is only free if your company had turnover of less than $100K last year. Yes, I qualify for the free version. Blender and Gimp are open source and completely free. I don’t know what audio tools to use yet, but I’ll use placeholder audio for the prototype, so I won’t need anything fancy just yet.

The last step for today’s blog entry is getting started with same basic decisions about the game. Let’s tackle these one at a time:

Target Game Systems:

Hmm. That’s a tough one. This blog thing is putting a bit of a wrinkle into this decision. There’s a plethora of systems to choose from. In Unity I have access to iPhone, Android, Web, PC and Mac, and the big three consoles. For the prototype using Unity Web seems the best choice because that’ll allow me to easily deploy the various versions for you blog readers. After the prototype is working and good I’ll decide on the target systems for the commercial versions. Right now I’m leaning towards iPhone and Web for starters.

Game Genre:

The first rule here is simple: write what you play. I’ve played a whole lot of video games in my life. If I had to list the major genres, it would be: Platformers, FPS, RTS, classic arcade, music games, sports, racing, Zelda. It’s kind of weird that I’m putting Zelda into it’s own genre, but hey, this is my list so I can do that. Looking at that list the Platformer genre is the obvious choice for me. I’ve never developed a platformer even though it’s my favorite genre, especially lately with the resurgence of Super Mario and Donkey Kong Country. As a side note, if you don’t own a Wii, buy one and then play Super Mario Galaxy 1 and 2, Super Mario Brothers Wii, and Donkey Kong Country Returns. These are the giants on whose shoulders I’ll be standing. (“If I have seen a little further it is by standing on the shoulders of Giants” Sir Issac Newton.)

2d or 3D?:

Goodbye 2D. It’s very strange. My first game, Crystal Castles, was an attempt to do a 3D game without 3D hardware. Now it’s almost 30 years later and I still haven’t released a real-time 3D game. The only 3D games I worked on haven’t seen light of day.

The older platformers were all 2D until Super Mario N64 showed us how to do them in 3D. Lately there’s been a trend towards doing the old 2D style platformer gameplay but using a 3D engine. This is a good way to get great looking graphics, keep the controls simple, and avoiding nasty camera issues.

So, to answer the question in more detail, real-time 3D but using a 2D side scrolling look, very similar to Donkey Kong Country Returns.

The Main Character:

I’m a programmer. My art is pretty good for a programmer, but I’m no pro artist, so I’m not going to do a cute furry animal or human. I could do a robot or maybe a square, but I’m looking for something more innovative. I’m going to have to put in a placeholder character into the prototype and decide on the real character later. Maybe I’ll let the character evolve just like the rest of the game. I’ll start with some geometric shape like a sphere, and squash it when it bounces.

The Controls:

Left, right, jump. That’s the usual platformer minimal control scheme. The problem is that on the iPhone we don’t have any buttons, and simulating three buttons is one or two too many. Having just one button is too limiting, so I’ll see if I can do the whole game with two buttons: Action and Jump. The Action button could be anything from “speed up” to “open door” to “jump left”. The meaning of the action button can change from level to level. I’m visualizing the player keeping his left hand on the left button and the right hand on the right button. This works on all of the platforms, which is a big plus.

The Camera:

It basically follows the player, and possibly zooms in and out depending on what the player needs to see to play a particular section of a level. It can also zoom at the beginning and end of a level for effect.

Player Physics:

The player moves from the start of the level towards the goal. He jumps when the jump button is pressed. He accelerates (up to a max speed) when the Action Button is down, and decelerates down to normal speed when the Action Button is up.

The Levels:

The prototype will just have some plain ledges and kill areas. If you touch a kill area you die.

Scoring, Lives, etc.

This can wait for another day.

Now What?

Time to get started and built the prototype.

(This is basically the first post from my previous blog, Franz’s Game Blog. The game that resulted from this was at first called ActionJump and then FatJumper. The game is still in early development as of March 9, 2011).

Posted in Development Tips, Game Design | Tagged , , | Leave a comment