Building a Demo for a Portfolio

A crucial part of a game designer's portfolio is a functional game, a tangible piece of evidence that you can do the things your resume and cover letter say you can do. But you worry that your demo won't stand out from all the other independent games out there, so you fear that your demo will be dismissed as a 'clone' and you will not be hired.

So how could you fix that? How could you develop something unique without joining mod teams that may fail from team drama that happens way too often? In this article, I propose one solution.

Start small.

That's right. Start small. Develop that clone, and get it working with as few bugs as possible. Don't bite into the entire watermelon. Just bite off a small piece and work on that. Keep it simple and functional and *fun*. For a designer, a fun game is more important than a pretty game.

Build on that game, one feature at a time.

Doing this will help you learn many aspects of full time game development. You'll learn to branch off experimental code from working, compiled code, so you don't break the entire build after adding another hundred or two lines.

You'll learn to schedule tasks and how important iteration is. Try something that doesn't work? Delete the branch and start again from the core game.

Play test each new feature before adding the next.

This one is extremely important. You need to discover if that added feature adds to your game, or takes away from it. Does it fit into the flow of gameplay well? Is it interesting? Do you encounter the feature enough while playing? Too often? Not often enough? Such questions can only be answered through constant play testing.

Save separate builds of your game to not lose your work.

This is also crucial from a data standpoint. Full time studios do this so they don't lose weeks, months or years of work. You'll be creating backups of not only your work, but previous builds that may lack a bug you're encountering in your current build. When you are in the debug stage of development this will save you many moments of pulling your hair out.

Starting small and adding features gradually will help you break down a larger project into more manageable chunks. It will let you have a working, compiled build for your portfolio instead of having excuses for 'It's not ready to play yet but it will be.'

Studios do not have time for excuses. They want tangible results. Deliver them.

Unreal Development Kit

Epic Games recently released the Unreal Development Kit, a closed source recent build of Unreal Engine 3, completely free.

What a great, great idea. I've used Unreal Editor 2.0 and 3.0, and there's *thousands* of tutorials, video demos, articles, samples, etc. for Unreal Engine, so it will make an excellent prototyping kit.

Using Unreal Kismet, UDK's visual scripting system, I can quickly prototype quick concepts for play testing, and timing of systems.

If I need to get right into the script code, UnrealScript looks very much like Lua, so it is very easy to learn, plus the aforementioned samples and tutorials can quickly get one up to speed on all sorts of game mechanics.

You can get the Unreal Development Kit here.

The Sims 3 and Cognitive Models

I've been playing The Sims 3 lately and I've been quite enjoying it. The Sim games as well as Sim City are an excellent method of taking a player's cognitive model of something and challenging it or altering it.

What exactly is a cognitive model, you might ask? Well, one definition states:

"A cognitive model is an approximation to animal cognitive processes (predominantly human) for the purposes of comprehension and prediction."

In other words, a cognitive model is a model in our heads of how a system works, or at least how *we think* it works. If I were to ask you to describe how a typical human's day goes, you'd probably say something like:

"Well, he wakes up, goes to shower, eats some breakfast, goes to work, eats lunch then goes back to work, comes home, spends time with his family, does some extra work at home, eats dinner, then goes to sleep."

That is your cognitive model of how you think the human's daily activity system works. How can that be translated into a game?

In The Sims, each object 'calls out' to the sim, stating their function. 'I am the refrigerator, I am the microwave, I am the bed,', etc. So the sim's Ai will navigate to each object based on their item type in order to fulfill one of the sim's Needs.

In real life, we do the opposite. Our eyes scan the area for all the objects, and our memory sees the fridge and goes 'Okay, that's a fridge, I know that if I want to not be hungry I should eat, and I can find food in the fridge because I remember storing food in there.'

Such a memory-recall system is quite complex as you would have to code a memory for every single object and character (known as a Sim in the sims), in order to have a system that mimics real life. As you can probably assume, that would be an enormous undertaking technically, not to mention for CPU cycles.

What can we take from this?

When designing a system that will emulate a cognitive model that your players have, Don't limit yourself to literally mimicking how the system works in real life. If you can emulate it with better optimization and a smaller, more manageable development time, then all the better, so long as it still fits the player's cognitive model of how that simulated system works.

The Game Development Process

2d Platformer part 4

Quick update on the platformer game. The following features have been implemented and work:

• Interactive Main Menu, complete with mouse rollover highliting and clicking
• Pausing and unPausing
• Pushable crates that fall with gravity
• Toggling switches that open doors for the player to get past
• Transitions to later levels
  

I am next going to work on falling platforms as an obstacle for the player, along with more enemy types. I will keep you posted.

2d Platformer Part 3

Tada! The first public screen shot of the platformer in action, though I am using placeholder artwork for now.

A lot of work has been put into the game lately, and I finally fixed the monsters not stopping on edges of platforms. Currently I am working on:

- Animation for the enemy sprites

- Gravity for enemies

- Ability for enemies to go up and down slopes on platforms.

I will keep you posted.

In other news, I recently joined the Game Designer's Special Interest Group in the IGDA, and there's a lot of people in the list who have worked on some of my favorite games, so that's been an exciting opportunity. 

I am part of the Wiki development team for the SIG, and I also head the Portfolio Help initiative, so good opportunities to network with and discuss portfolios with other game designers.

More to come!

2d Platformer Game Part 2

A quick update on the progress of the 2d Platformer game:

- Playing around with the size of each level, testing both horizontal and vertical layouts

- Play Testing various enemy types and taking notes on the game's complexity curve

I'm having trouble with getting certain enemies to stop when they reach the edge of a platform. For some reason they are not responding to the obj_reverser object that reverses their direction when they pixel collide. I'll keep looking into it, though.

Once that's done I'll be scripting the shooting code for enemies that shoot projectiles in the direction of the player. Luckily the projectiles are limited to a horizontal path so the code shouldn't be too complex.

I'll keep you posted!