Arena is a top-down shooter, using elements of a typical first-person shooter (FPS) in a 2d, sprite-based, shooting game. The game has typical FPS controls, and includes various weapons and bad guys to fight in challenging levels.

Weapons:

Sling - Hurl small stones with rapid fire rate and unlimited ammo.
Pistol - Shoot basic, single bullet.
Cannon - Launch massive ball with slow fire rate.
Shotgun - Spray bullets with moderate fire rate.
Rocket - Scream missile to target, with direct hit and explosion damage.
Machinegun - Fire basic bullets but with rapid fire rate.
Lazer - Mashes bad guys with beam that automatically recharges.

Goblin - (very small, green) Vicious, explodes when he hits you.
Kobold - (small, red) Bigger and slower, but clings to you like white on rice.
Bugbear - (small, blue) Not bigger or faster, but packs a pistol.
Imp - (small, light blue) Not fast, no pistol, but has a lazer. Watch out!
Troll - (medium, orange) Bigger, tougher and with a shotgun.
Ogre - (large, purple) Even bigger still, and has a cannon to boot.
Giant - (very large, grey) An Ogre on steroids.
Hydra- (very large, yellow) A Giant at first, but watch the heads!

Credits:

Visual Art - Mark Claypool
Programming - Mark Claypool
Sound Effects - from Flash Kit
Level Design - Mark Claypool
Play Testing - Akaash and Saahil Claypool

Comments:

Send questions or comments to:

Mark Claypool, claypool at cs.wpi.edu

Arena is free! This means free of charge for your personal use. You may copy and distribute copies of Arena, provided that you keep this copyright notice intact. You may not charge for the use of Arena to anyone else. The copyright holder (me, Mark Claypool) reserves the right to reclassify this software as a non-freeware at a later date (e.g. as shareware). Doing so will not modify the license agreement of any previously distributed executables.

Requirements:

Windows 98 or above
32MB DirectX-compatible graphics card
DirectX-compatible sound card
A computer (with keyboard, mouse and monitor) ;-)

Download (version 1.1):

Executable: arena-win7, v1.1 (Vista or Win7 executable, 8.8 Mbytes)
Executable: arena, v1.1 (Win98 or WinXP executable, 7.4 Mbytes)
Changelog: changelog.txt

Mailing list:

If you'd like to be on the mailing list to be informed of future arena updates (don't worry, there will be no other spam on this list), let me (claypool at cs.wpi.edu) know.

Below are some somewhat haphazard notes regarding the creation of Arena. Included are reflections on the "soft" plan regarding the artistic vision and game design, with some notes on the technical challenges. Post-mortem type reflections are provided at the end so that I (and maybe others) can learn from this experience for better upcoming game development.

Art, Tech and Design

Although Arena is not creative in the game genre sense (it's a shooter, after all), I did enjoy the creativity in the game design (including level design and game balance) and even the limited art (audio selection and sprite creation) that I did. And, being a computer hacker, I enjoyed the technical challenges of programming (always fun) to make it all work.

Artistic Vision

The goal was to use simple objects (that I could draw) that were clearly distinguishable from one another, primarily by color. This fit into a tenet that I've used when teaching beginning game developers ("if it is not a fun game with simple objects, it won't be a fun game with fancy graphics"), as well as appealed to my limited artistic ability (I can draw circles, after all).

The audio selected was intended to clearly represent action being taken. Thus, a gunshot sounded like a gunshot and when weapons spawned for the player to pickup, it was clearly distinguishable from other sounds (no subtlety). Clarity of the sound meaning was also made through volume, with more important events sounding louder and less important events sounding software. While theme music has it's place in games, it was decided there are too many ways to get it wrong (watered down ambient music or music that is too reactive, for example). Thus, the decision was made to forgo music.

Technical Challenges

Early development concentrated on making the control of the hero avatar fluid for the player, with responsive actions from the gun (through the mouse). Switching weapons was similarly tested to feel quick and natural. The second weapon (via the right mouse button) was added later, as were options to use the number keys to switch weapons. Both these options were put in place for more advanced players needing more options from the hero avatar. They had the advantage, too, of providing some payoffs for expert players to grow into superior combat.

The game engine itself had technical limitations when the animated sprites were too large. This was true for early incarnations of the game that had many degrees for rotation and for the movie in the start page. Similar limits were encountered when numerous particle effects were used. These limits were overcome by reducing the number of frames of animation (and reducing the sprite playback speed) and reducing the particle effects, both while still maintaining some visual quality.

Game Design

For player-to-gameplay balance, the intent was to start quite easy, assuming the player had not done many shooters. Thus, the first level is actually accomplished by running out of ammo. By the same token, some of the hooks in the gameplay, the choice of weapons and their accompanying "wow" factor (through the use of particles and sound) were illustrated early (the shotgun and the rocket launcher). However, in order not to show too much of the Arena's hand, the were a substantial number of "wow"s saved for later (lazer, cannon, machine gun and lots of baddies).

Players were primarily rewarded with new weapons, with the levels designed to show where the weapons were effective. Other rewards were unlocking of new levels (allowing new exploration) and rewards in abilities like superior fighting tactics (say, when mastering the use of the 2nd gun).

Having players proceed through trial and error was unavoidable (for example, the first time a goblin comes and blows up, that's quite likely a surprise), but in general, clues such as tougher guys being bigger and coming in with a dramatic flourish provided guidance to inform the player choices.

Most of the gameplay-to-gameplay balance (both attribute and component) was done through trial and error during play testing, with no formal mechanism setup (e.g. a payoff matrix) to compare choices. While there were no tools made to facilitate this, early balance was done in a sandbox-type room, with values (such as health, damage, etc.) set as global variables that could be adjusted fairly easily.

As the game was not multi-player, the focus was on player-to-gameplay balance and gameplay-to-gameplay balance. However, for player-to-player balance, starting conditions were made the same for each player, with most major events happening at the same time. There are a few levels that make use of random numbers for the bad guy spawn time (and also for the gun location) to add variety for when levels are re-played, most likely in the Arena level. However, the random numbers are bounded by a range that makes the timeline events dominate, so the randomness provides some variety without making the outcome of the level depend upon luck.

Post Mortem

Although this section does not have a formal post-mortem, it does contain a list of the primary things that went right and things that went wrong.

What Went Right

• Starting with fluid movement, responsive controls to the weapon. As this was a core element of the interactivity (e.g. running and gunning), the focus both technically (when keys are pressed) and artistically, served to make a satisfying look and feel for using the hero.

• Concentrating on building all the guns and all the bad guys in a "sandbox" mode, leaving level design (including game balance) for later. This allowed uninterrupted concentration on the technical aspects in the first phase, and game design (level design and game balance) in the second phase.

• Making the values for object components, such as health and damage, centrally located (actually, as global constants in one file) made tuning the game for game balance much easier. Hunting through the code for the right parameter was not needed.

• Making heavy use of particle effects. An early design decision was made to use simple graphics, but still have a compelling "feel" during battle. Liberal use of particle effects enabled more intricate visual effects without extended hours as an artist.

• Play testing with players with a variety of skills. Although my pockets (time) were not deep enough to solicit a lot of users to play test levels for balance and feedback, I did consciously seek out players that were beginners (at both computer games and shooters), intermediates, and experts (this group having played many FPS games and lots of games in general). I watched them during play, as well as solicited informal feedback after they were done. This was quite revealing both in terms of players having unexpected difficulties (say, with the left-hand controls for movement) or the use of two weapons or the ease of some supposed challenges. Such feedback tweaked early levels to help players learn to play the game without getting frustrated (for example, the Target Practice and Sling Along levels) and made challenges for later players (for example, the waves in the Arena level with high scores).

What Went Wrong

• Not enough planning went into the software design of the objects. This was true for the weapons and bad guys. There were natural hierarchies for the objects that, if used, would have made it more flexible to add additional bad guys and guns. Instead, each required considerable manual effort and fixing bugs was more of a challenge because code was repeated.

• Even though the centrally located point for component values was a good idea (as noted above), tweaking the values still required exiting the game, changing the values and restarting. A better idea would have been to invest some time in tools to help with tuning the game balance. For example, a interface could allow fire rate or health or damage to be changed "on the fly" as the game is played, greatly speeding up the play testing.

• The time to design levels was underestimated. Focusing on building the bad guys and guns was the right idea, and "generators" were even made to spawn bad guys in a tunable fashion. The expectation was that assembling interesting levels would be easy (in the early going, numbers like "100 levels" were mentioned). In practice, designing the levels took much longer than expected, both in terms of getting the right events to happen (implementing the time lines) as well as balancing the levels so they were fun.

That's it! Any comments on the game are welcome. I hope you enjoy Arena! -- Mark