Andy J Design

Common Pitfalls in Your Game Loop

infamouse — Tue, 05 Jan 2010 19:00:10 +0000

Putting actor logic in your game loop

It’s important to remember that we put things into objects for a reason. One of the greatest reasons is to keep the logic in our code cleanly separated. If you want the enemies to act one way, you change the code in the enemy object. At a later point if you change your mind you simply pop some new logic into the object.

When you muddy the water by putting logic in the game loop it becomes harder and harder to work on your project. It also makes it difficult for other team members to logically find your code. Take a look at the example below:


update(time) {
foreach ( actor in game ) {
actor.update(time);
if(actor.type == "enemy") actor.x += 5;
if(actor.type == "player") Player(actor).score ++;
}
}

You’ll notice that for each “enemy” it will do an arbitrary movement of 5 pixels on the x axis. What if you want to move it left 5 pixels instead? Do you go to the actor object? It gets harder and harder to find this logic. The best game loops look like this:


update(time) {
foreach ( actor in game ) {
actor.update(time);
}
}

Later you’d see:


Enemy extends Actor {
update(time) {
x += 5;
}
}

Player extends Actor {
update(time) {
score ++;
}
}

Nice and tidy!

Not timing things based on elapsed time

You’ll notice something above, as well. The update function is called on the game loop each frame and it’s passed the time elapsed. When you do anything animation or time-based you have to take that timespan into account. A player who gets one point every frame wont be very happy when his friends’ computer is playing at 100 frames per second and his at only 20.

Multiplayer Game Design: Server-Side Models and Distributed Models

infamouse — Wed, 02 Sep 2009 03:00:16 +0000

I recently posted about using the MVC pattern in games and provided a very quick and dirty pseudocode model of our hero in MVC. It showed a nice separation of concerns and had the display removed from the logic of the game. Shortly after I was prompted by one of my readers about using the Model View Controller pattern distributed over a multiplayer environment. There are a lot of opinions out there and I’ll cover a few here. I’m curious if you all have feedback on these methods and their use in browser-based games specifically.The simplest arrangement is a turn-based game that takes input from one user at a time and then displays the result to both players. Thankfully if we put our pattern-based code to use we can alleviate a lot of the client-server traffic in a simple client -server setup. (For this post I’m going to gloss over the lobby and game initiation part of the process)

We’ll start with two simple clients. These clients exhibit the characteristics of a simple View and Controller pattern. They have an array of game pieces on them and some simple inputs (lets say buttons). What these are responsible for is displaying the current game state and notifying the server when input has been given.

The game state is Model and is handled on the server separately from both clients. Each time one of the players takes action it’s sent to the server and the server updates the model appropriately. Once the model is updated it posts this update to the clients and they are responsible for updating the view.

We’ll use a simple game here: player 1 selects their favorite color from a set of three and player 2 selects which one they believe the first player has selected. Our model stores two values:

Player 1’s Color Selection
Player 2’s Color Selection

Our view displays one of 2 states:

Select a color
Display result

And our controller is responsible for one action:

Handle click on displayed color

So the basic gameplay goes like this:

The game model is initialized
1. Player 1’s Color = null
2. Player 2’s Color = null
The model is sent to both clients (both colors null)
The client’s views respond by showing the color selection buttons (“red”, “green”, “blue”)
Player 1 clicks “red”
The controller sends this input directly to the server (holding the model)
The server updates the model (Player 1’s Color = “red”)
The new model is posted to the clients (Player 1’s Color = “red”, Player 2’s Color = null)
The views now reflect new information
1. Player 1 shows “You selected red, waiting for player response”
2. Player 2 continues to see color selection buttons
Player 2 selects a color and the controller sends to the server
The new model is posted to the clients
Both clients display the game result screen: “Player 2 guessed the right color!”

So now you can see how we can divide up the responsibility with the model completely on the server side and the controller and view on the client side. From here we can evolve to some more advanced models.

Gery breached the topic of having multiple models (that is concurrent models) on each of the clients. This is an important case to consider when moving to realtime gameplay. In realtime gameplay it’s critical for players to be able to act and react based on their opponents’ actions. One reason for moving the model – or part of the model – to the client is so that the model can quickly respond to input and overcome some of the shortcomings of lag and narrow bandwidth.

In this case you have to have a nicely tuned model. One thing that game developers quickly encounter is the need to move your code from say 5 pixels per ENTER_FRAME event to 5 pixels for 20 millseconds. This way your game doesn’t run faster or slower on different computers. When you’ve got your code in this kind of set up you mostly just record input for the controller and pass it on each time the input changes. A really fun example of this is the game Rabbit Wants Cake developed by one of my favorite Flash game developers jmtb02.

The game is a great example of the effects of input recorded and played back directly to the game controller. To take this to the multiplayer MVC realm we can start with a pessimistic concurrency example. Two controllers are running (each client) and two models exist. When input is received from one of the controllers it contacts the other controller and they agree on a timestamp for that input. That timestamp is then put into the input queue for both controllers. These controller act on the input at the exact same perceived time and they render the exact same output to the model. The view remains ideally completely clueless as to the complex multiplayer interaction – the controllers are talking to each other and constant filling the hopper with identical input.

Here’s how the pessimistic model works:

A jump button is pressed on client 1 at 56 millseconds game time
The controller sends the event to the other controller and they agree that they can both render it as if it happened at 65 milliseconds
This value is returned and both client models are updated at 70 milliseconds
The view reflects this by making the 1st player’s avatar jump!

Unfortunately a pessimistic example of this will lead to a fair amount of lag if the timestamp of the input can’t be negotiated in a reasonable amount of time. In this case we need an optimistic controller that’s capable to modifying the model based on historic inputs and some way to reconcile differnces. This optimistic model means that when client 1 jumps at 56 milliseconds it immediately starts the jump on client 1’s model and then sends the jump to the second client telling it that client 1 jumped at 56 milliseconds. But now you need a much more advanced controller that can figure out exactly what happened between the jump and the current game time and update the model in a fair (and perfectly predictable) way for both models.

The real goal of distributed models like there are to keep them perfectly in sync otherwise your game state differs and it’s no longer playable. With pessimistic concurrency you can see that they will always be perfect but a fair amount of lag is introduced. This may work for you game! But for the majority of real-time games you’ll need to implement optimistic concurrency and that is a very complicated beast indeed. Not only must you be able to replay historic events into your existing model flawlessly but you’ll also need to find a way to re-sync your models should they get out of whack. That’s a big challenge and we may cover it in the future.

Please don’t be shy and let me know what you think!

Free Game Hotness: Spelunky

infamouse — Sat, 22 Aug 2009 02:00:23 +0000

So I’ve been throwing away tons of time trying to get this tiny pixelated Indiana Jones character through endless random dungeons. Can I be honest and say I haven’t made it past the 4th floor? Okay.

I’m having vivid recollections of my early NetHack days. “Don’t touch the cockatrice. You’ll die.” Check. “Don’t trip on the cockatrice while blind and die.” Check. “Don’t zap a monster with an unidentified wand, polymorph it into a cockatrice, run into a dead end, and die.”

But there’s something here that sets Spelunky apart as it’s own beast entirely. It takes dexterity. I can’t tell you how many times I’ve clumsily dropped on bomb and ran from it only to fall into the clutches of some ill tempered trap. But it makes the rewards of mastering the simple controls that much better.

The graphics are great, there’s catchy music, and it’s so simple to start playing you just can’t say, “no”. Enjoy this YouTube preview and download it below!

This video was embedded using the YouTuber plugin by Roy Tanck. Adobe Flash Player is required to view the video.

Download Spelunky

Big thanks to Tiny Subversions for tipping me off to this one. How about we kick this off by sharing your favorite Spelunky deaths?

Game Programming with Patterns: Model View Controller

infamouse — Wed, 19 Aug 2009 18:45:19 +0000

For those of you new to Flash programming – or any kind of programming – you might not have thought about object oriented programming beyond just trying to get the stupid stuff to compile. When people think about OOP it drudges up ideas of classes, inheritance, methods, abstract members, and a bunch of other stuff that sounds great but how do we apply this to our great game idea? When you’re learning object oriented programming the most important thing you can take away is how to use object patterns to quickly prototype your ideas.When people do medical research they don’t start from scratch. They use libraries – buildings full – of previous research to build upon knowledge that’s been growing for generations. When you’re writing code there’s no reason to start from scratch. People have built a huge array of useful patterns that we can put to work right away in our Flash games.

If you’re interested in diving right in you’ll love this huge list of design patterns. Today we’re going to talk about using the Model-View-Controller pattern for game programming. This pattern has been popular in business software for a long time and has recently come into vogue because of the rapid rise of dynamic web apps. Check out Microsoft’s Rob Conery (he loves MVC) who has been evangelizing the ASP.NET MVC platform for a long time now.

Bo-ring. I know. But how do we make it work in our games? Well the gist of MVC is this: you make a “model” of the things in your app, then figure out how to show them in the “view”. Everything your user does is sent to a “controller”. The controller then changes things in the model. Okay: we’re still in outer space.

Imagine you have a hero. He’s in the middle of the screen, and he’s bored. Well what do we know about the hero? We know he has an x and y location on screen. What else do we know? He’s got 100 hit points.

So lets turn this into a model. We’ll mock it up in pseudocode. (This is great practice by the way.)

class Hero {
  // properties
  x:Number; // x location on screen
  y:Number; // y location on screen
  hitPoints:Number; // number of hit points left
}

So we’ve got a funny little class. Now what do we do? Now we make a view. What does our view entail? Well it’s everything we want to display. We don’t know very much yet so we don’t have a lot to display. In our game loop we usually take input, adjust variables, and then draw things. For our view we can just display the hero and a bar for his hit points.

class LonelyHeroView {
  // a view always shows data directly from a "model"
  var model;

  function LonelyHeroView(hero:Hero) {
    model = hero;
  }

  function display() {
    // draw a hero at (x,y)
    Screen.drawHero(hero.x, hero.y, hero);
    // draw a hitpoints 10 pixels above hero
    Screen.drawHitpoints(hero.x, hero.y - 10, hero.hitPoints);
  }
}

So what do we do with these two classes? Well we take our normal game loop and each time we create a “LonelyHeroView” and run display().

// set up our model before entering loop
var hero = new Hero();
hero.x = 10;
hero.y = 10;
hero.hitPoints = 100;

while(true) {
  var view = new LonelyHeroView(hero);
  view.display(); 
}

Now our hero will be displayed every frame at 10, 10 and have a full bar of 100 hit points. Well we do want input don’t we? Of course! All we have to do is take input and use the input to modify the model. We’ll start by making a really simple controller class.

class GameController {
  var model;

  function GameController(hero) {
    model = hero;
  }

  function left() {
    model.x -= 5;
  }

  function right() {
    model.x += 5;
  }
}

This is a really simple controller. We each turn in the game loop we have some new code.

// set up our model before entering loop
var hero = new Hero();
hero.x = 10;
hero.y = 10;
hero.hitPoints = 100;

while(true) {
  var controller = new GameController(hero);
  if(leftKeyPressed() == true) controller.left();
  if(rightKeyPressed() == true) controller.right();

  var view = new LonelyHeroView(hero);
  view.display(); 
}

Now we’ve got a simple model, view, and controller. One of the staples of good object oriented design is being able to separate code that’s responsible for different things. The more complex your game gets the more your code is going to be stepping on its own toes.

It’s always helpful to mock things up in your own language first, then pseudocode, then write the real stuff. There are even entire tools and languages dedicated to generating pseudocode! Imagine how easy it is to maintain your code now. What if you play the game and decide that the hero moves to slow? You go into the controller and make him move more left and right for each key press. Easy. Now what if you decide keyboard input is bad and you want to use the mouse for input instead? Just change keyPressedLeft() to leftButtonClicked() and voila your hero responds to a mouse.

I’ll dig into more concrete examples of MVC in future posts! For now I’d really appreciate everyone’s feedback on the first of my tutorials.

Tuning Facebook Apps: Apache and MySQL Performance

infamouse — Wed, 19 Aug 2009 07:00:36 +0000

Facebook apps are getting hugely popular. Once you’ve got a great idea to implement on a social network it can be tough getting it off the ground. The Facebook team says that one of the best indicators of an apps success is its speed and responsiveness. We’ve already seen the Facebook site grow a little too big for its britches – it’s performance can be downright discouraging on some older machines and browsers. But what can you do to increase app responsiveness and performance. Here are some tricks to get you app, your Apache server, and your MySQL database ready for the big time.

The first thing I’m going to mention is that if your app is designed and implemented poorly then you’ll find tuning Apache and MySQL to be highly dissatisfying. Best practices for web apps, especially hosted on other platforms, include rendering a page with minimal content and filling in resource-intensive information with AJAX, minimizing and caching SQL query results, caching REST queries where appropriate, etc.

You can’t just stick to outdated scripting pattern of “run a boatload of queries and render the page”. When you hit the 8 second mark Facebook will render an error to your user! The penatly for this is astronomical. Just look at the countless Facebook apps whose pages, walls, and discussion boards are just rant after rant about “how come this dont lode?” and “me two!!!” threads. But even well engineered apps simply buckle under the staggering demand social apps can put on servers. The spikes in popularity can kill an app almost as fast as it meteorically rose into the public spotlight. Apps like PackRat are a great example.

To do any kind of performance testing you’ll need a reliable suite of tools to test exactly how responsive your app is. I find the best kind of performance testing is compound testing of throughput for an entire page render. Usually these page renders make a handful of REST calls, a few SQL queries, and run your template engine.

A great app to do this is Apache Bench (ab). You just point ab to a URL on your server, tell it how many requests to run and how many to fire off concurrently. A simple one is to run a batch of 10,000 queries with 100 concurrent requests:

ab -n 10000 -c 100 http://localhost/facebook_app.php

The output from Apache Bench tells you a lot. Longest request, requests per second, etc. Here’s quickie from Google:

Server Hostname:        www.google.com
Server Port:            80

Document Path:          /
Document Length:        4952 bytes

Concurrency Level:      100
Time taken for tests:   4.366902 seconds
Complete requests:      1000
Failed requests:        841
 (Connect: 0, Length: 841, Exceptions: 0)
Write errors:           0
Total transferred:      5323026 bytes
HTML transferred:       5003374 bytes
Requests per second:    229.00 [#/sec] (mean)
Time per request:       436.690 [ms] (mean)
Time per request:       4.367 [ms] (mean, across all concurrent requests)
Transfer rate:          1190.32 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:       65   84  66.8     72     562
Processing:    72  310 385.6    149    3562
Waiting:       71  149 244.7     81    3504
Total:        138  394 388.6    222    3640

Percentage of the requests served within a certain time (ms)
 50%    222
 66%    492
 75%    556
 80%    578
 90%    830
 95%   1097
 98%   1661
 99%   2136
 100%   3640 (longest request)

Apache comes pre-configured with a lot of modules turned on that are frequently not used. Even if you are using them you might ask yourself, “do I really need that feature?” The Red Hat default Apache 2 package has all these modules in it that I turned off:

authn_auth_digest_module (shared)
authn_file_module (shared)
authn_alias_module (shared)
authn_anon_module (shared)
authn_dbm_module (shared)
authn_default_module (shared)
authz_host_module (shared)
authz_user_module (shared)
authz_owner_module (shared)
authz_groupfile_module (shared)
authz_dbm_module (shared)
authz_default_module (shared)
ldap_module (shared)
authnz_ldap_module (shared)
include_module (shared)
env_module (shared)
ext_filter_module (shared)
deflate_module (shared)
headers_module (shared)
setenvif_module (shared)
mime_module (shared)
dav_module (shared)
status_module (shared)
autoindex_module (shared)
info_module (shared)
dav_fs_module (shared)
vhost_alias_module (shared)
negotiation_module (shared)
dir_module (shared)
actions_module (shared)
speling_module (shared)
userdir_module (shared)
proxy_module (shared)
proxy_balancer_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_connect_module (shared)
suexec_module (shared)
cgi_module (shared)
perl_module (shared)
roxy_ajp_module (shared)
python_module (shared)
ssl_module (shared)

Next you’ll want to make sure that extra features are turned off. Lots of things like HostnameLookups have big performance hits and have been turned off since Apache 1.3. There are still more subtle things to turn off like FollowSymLinks which makes extra system calls for each request. For a full rundown see the Apache Performance Notes.

When you start to get a lot of simultaneous requests you’ll notice Apache starting to grab bigger and bigger chunks of resources. By default many distros ship with the prefork MPM as the default handler. Switch to the worker MPM will save you a lot of resources. Unfortunately PHP is not a thread-safe environment and you’ll need to switch PHP over to FastCGI. On Red Hat you can switch you Apache over to the worker MPM by changing /etc/sysconfig/httpd and adding this line:

# Set Apache to the Worker MPM on Red Hat
HTTPD=/usr/sbin/httpd.worker

Switching PHP over to the FastCGI environment isn’t hard either. You install the PHP CGI package (and probably a few dependencies, too) for your distro and change the PHP handler in Apache to:

Options ExecCGI Indexes
AddHandler fcgid-script .php
FCGIWrapper /usr/lib/cgi-bin/php5 .php

Now you’ve got a nice, snappy PHP server capable of churning out tons of concurrent requests to your Facebook app users. For most apps you’ll also be maintaining app-specific data. Maybe it’s their high score or their favorite vampire. You do not want to store private user information in your app, ever. If you want to store user information for caching reasons put it in memory – at least flat-file in a ram drive. So you’ll likely be holding tables of user ids and some simple data associated with the user.

While your SQL fundamentals class told you to make your data as atomic as possible, sometimes this just isn’t the answer. Keep your tables structures simple joins can kill performance if you don’t keep an eye on them.

First things first, you’ll need to keep an eye on MySQL and make sure that you’re not running an “slow queries”. You can set a threshold for this and log every slow query to a file. You can even log queries that are run against un-indexed columns. Add these lines (while testing only, disk access is a performance hit):

set-variable=long_query_time=1
log-slow-queries=/var/log/mysql/log-slow-queries.log
log-queries-not-using-indexes

Keep an eye on it. You’ll catch glaring queries right away. There are subtle problems I’ve run into also. If you mismatch the variable type you pass to a query it can scan the entire table skipping your index entirely! Beyond that you’ll want to make sure the heaviest queries are cached – or in the case of leaderboards, only update them when something changes! It might be as simple as storing a value for 10th place in your leaderboards. When someone cracks the leaderboard, re-write the entire thing into cache. Use this push method as often as possible. When you do the cache-miss then fill method you can run into some nasty race conditions.

Stay tuned and happy hacking!

Kick Your Game Development Up A Notch With Subversion, Trac, and Harvest

infamouse — Mon, 17 Aug 2009 17:45:46 +0000

Trac works great with Subversion and can help you finish your game project

When you’re writing a game it’s easy to lose track of your time, ideas, and the fun of it all. You’ve gotta figure out your goals, sketch out your ideas, build prototypes, iterate, and take feedback on a project. I know you’ve all got those legal pads with the next great game scribbled down on them. Time to think like a project manager and get that stuff done.

If you don’t have source control: you need it. Spend a day and figure out how to check out and check in and it’ll save you from yourself. Ever accidentally crunch an FLA and lost everything? Do you have 5 tilde’s in front of filenames? ”Final-final_final” look familiar? I’m talking about my favorite setup here – Subversion. Of course on Windows all you need is TortoiseSVN and a copy of the (free) Svn Book to get you started.

When you’ve got Subversion rolling you might be feeling saucy and want to keep track of your changes, set milestones, make to-do lists, and keep a project wiki (so you don’t lose any of those midnight bright ideas). My favorite package for this is Trac. Trac is a great package and is a little tricky to set up but thankfully there are people like Hosted Projects who can roll you out the whole setup in minutes. You could also look at some options like a VM appliance you can roll out on your machine like vmTrac.

Now you can save your code, keep track of versions, fill out your task-list (and not forget that cool feature you thought of), and set milestones for yourself. It might seem like a hassle to set up a project so rigidly but you’d be surpised what you can get done when you get out of your own way. It’s great to sit down and know exactly what needs to get done on your project. Or, in the future of your game career, when you’re working with a client you’ll have all the tools you need to estimate out projects and keep them up to date on your progress.

It takes a lot to finalize a game, just like World of Goo

Take World of Goo for instance. It wasn’t built in a day. They had to make versions of it, play with it, take feedback from their friends and testers, and act on that feedback. You think they kept it all on sticky notes?

Thanks to great new resources a lot of indie game developers are finding projects and teams to collaborate with. You want to really blow them away? Why not keep track of your hours. Not only will it help you figure out how well you perform but it will knock their socks off, too. A great place to track your hours is at Harvest. If you get in the habit of tracking your own hours you’ll have a much better idea of the time you’re actually spending and it will make you a much better team contributor.

When you’ve got all these skills in place you’ve got a real foundation to become part of the larger developer community no matter what kind of code you write. And for game programmers I’d love to see everyone step up and take their code to the next level.