Brainfold

Lately I’ve read a lot about game design (Danc’s blog has been especially enlightening). I’m now convinced I have to prototype a few “risky” aspects of Artillery Brawl’s gameplay to make sure what I’m doing is actually fun before wasting effort on other parts of the game.

The core gameplay of each game has to be fun for the game on the whole to be fun. Platformers are about jumping, shooters are about shooting and Go is about placing stones on a board. Players are going to spend most of their time playing doing this core activity; everything else is basically extra to hook players at first or keep them interested in the long run. In Artillery Brawl, core gameplay is of course shooting, and before I dwelve into anything else, I have to make shooting fun. In other words, it has to be rewarding.

Artillery Brawl isn’t fun yet. There are a couple of obvious problems I’m going to fix first and see what the results are, then decide what’s to follow. First, there’s absolutely no feedback or reward for shooting; there aren’t any kind of effects (visual or aural) when you shoot or hit something, and units simply disappear when they are destroyed. Not very fun at all. So I’m going to add some particle explosions and sound effects to help with that. Explosions are always fun, right?

Second, there’s the user interface. Currently shooting is controlled with the arrow keys and modifiers (alt and shift), but while I want to keep that, I also want to add mouse control that’s dead simple to use. It should be immediately obvious (at least after pressing the Shoot! button once or twice) what to do in the game without any kind of documentation or tutorials.

Last, but certainly not least, there’s the camera. Currently, other than automatically focusing on the current unit when a turn begins, the camera is completely manual. With the turn system I have in place; multiple tiny shells in the air, many things happening at once and many players in front of the same screen, each interested in different things, this simply won’t work at all. I have to improve the automatic behaviour of the camera, and luckily I have a couple of simple to implement improvements in mind. At the beginning of a turn, the camera should focus so that the current unit and the place the last shot landed should be visible. Between turns, the camera should zoom out, showing as much as possible. When a shell is about to land, the camera should zoom in on that. Later, I can improve it so that if multiple shells are about to land at the same time, I can use a picture-in-picture to show both at once. Also, I’m going to improve the visibility of both units and shells, and add a minimap.

If, after these improvements are in place, the game still isn’t beginning to approach fun, I’ll have to either change something dramatically or start a new project. Simple as that.

Tags: Artillery Brawl, game design, prototype, user interface

I’m starting to write about the game design for Artillery Brawl on this blog instead of keeping it in my head and my private wiki. As opposed to Red Nebula, whose concept is wide open, a “playground” of sorts, the vision I have for Artillery Brawl is very focused, and I have already dismissed several gameplay ideas that simply don’t fit that vision. To start with, here’s the concept for the game.

---

Artillery Brawl is a remake of my first real game, Arty, and a tribute to Artillery Duel, Scorched Earth and other games of the classic artillery genre. Two or more players, with one or more artillery units each, battle to gain victory by destroying each other or reaching some other victory condition depending on the rules.

Core features

• OpenGL-accelerated 2D graphics
• Realistic physics simulation
• Procedural levels
• Real-time gameplay paused during turns
• Damage model not based on hitpoints
• Multiple game modes with different rules
• Shopping system to buy and customize units
• Hotseat multiplayer on one computer

Everything else is extra, but the above features are central to the vision.

World

The game world is a 2D terrain always viewed from the side and bounded on each side. No unit or other entity may cross the bounds; for example, artillery shells crossing the bounds are silently eliminated. To help with this, there is a “buffer zone” on each side, where no units are placed at the beginning of the game. Scale is at the unit level, with no higher level organization or lower-level detail.

Gameplay

A game consists of a number of rounds. Before a game, the players agree on a set of rules, including ending conditions for each round and the game, and how money is gained. A round might end when only one player has units left, or after a time limit. A game might end after a set number of rounds, or when only one player has money left. Before each round, the players may buy new units and customize existing units at a shop screen with their money.

Each round has a continuous timeline. When it’s not anyone’s turn, time advances in real time. Time is paused during turns, and continues again when the turn is finished. During a turn, a player may give orders to their units, but units only act between turns. A player may start a turn any time they want by pausing the game, or automatically when a unit has finished its current orders.

Style

The style of the game is semi-realistic; not terribly serious, but not “casual” either.

• Units and other equipment will be loosely based on real equivalents
• Units and other entities are affected by physics simulation, but some gameplay elements might take liberties with this
• The world is larger than usual in the genre, though not realistic; we don’t want units to be kilometers apart
• The damage model is not based on hitpoints as usual, but will be simple

Tags: Artillery Brawl, game design

Here is a second take on the Red Nebula game concept, after lots of polishing. Please keep in mind this is the concept for the whole game, and Milestone 1 will be just a part of it. I have also made progress in the coding department, but nothing cool to show yet. The engine is slowly progressing, but I have concentrated more on game design.

---

Slow-paced strategic / tactical science fiction game of space exploration. Space is empty, cold and hostile, information and resources are always scarce. “Survival horror in space.”

Features

• Procedural game world: no predefined species (except for Earthlings), stars, planets…
• Emergent behavior: instead of predefined behavior, most interesting events should dynamically result from underlying mechanics
• Scenarios: exceptions to above, static content such as starting condition, story and scripted events
• Semi-realistic: or plausible sci-fi; no Star Trek -style humanoid aliens, slower-than-bullet lasers etc.

• Exploration: information is usually very limited (and the world is a complex place), so recon and exploration are very important

• Morale: it’s important to keep the morale of the crew high

Genre

Strategy game with role-playing elements (player avatar).

World

The world is fully 3D with no borders at the edges of the world. Scale ranges from galaxies to planets and space ship fleets, with focus on the star and fleet level.

Perspective

The game is always viewed from the 3rd person in 3D.

Gameplay

Gameplay consists of scenarios and a sandbox mode, where you can play freely in the world.

Gameplay is in real-time and can be accelerated, decelerated or paused at any time.

Style

Ambience is generally really dark, with the exception of large settlements such as Earth, which are “beacons of hope”.

Graphical style is clean, dark and minimalistic.

---

In other news, I kinda got hooked on Eve Online. Actually I just tried the free 14-day trial because I wanted to see how the game had changed during the years. I used to be in the beta and liked it very much, but when the game was released I just lost interest for some reason. Still, it’s the only MMO game I have ever liked. I have tried Horizons, World of Warcraft, Neocron and probably some others I don’t even remember, but I never liked them. The style of Eve is something very unique, and I have always absolutely loved the visuals and music (though I have no doubt I will get sick of them if I play for a couple of months). Anyway, I’m now thinking of buying an account and playing for at least the month that comes with it…

Tags: game design, Red Nebula

Christmas was nice. I finally got a new monitor (Samsung 2232BW) to replace my old CRT with a horrible picture, so that was good. Actually I didn’t get it yet because I’m still at my parents’, so I’ll have to wait until next week when I get back to my place. This is relevant for game development because until then, I’m stuck with writing code on my laptop, which tends to go much slower than on my desktop computer. On the other hand, I’ve been reading a lot on various subjects, so that counts as progress too even if there aren’t much concrete results.

I also bought Fundamentals of Game Design by Ernest Adams and Andrew Rollings for myself, and so far it looks good. Inspired by the book, I finally wrote a very rough concept for Red Nebula and its first milestone:

Red Nebula is a sci-fi strategy game of the 4X (eXplore, eXpand, eXploit and eXterminate) genre.

Notable features include:
- A procedurally generated, dynamic world
- Emphasis on exploration, as I feel it’s an aspect of the genre that’s been seriously neglected
- Try to avoid some ugly cliches of the genre, such as “Star Trek” aliens and implausible combat

Milestone 1 implements the procedurally generated world in some degree. Main gameplay content are various scenarios, such as “eight colonization fleets were sent from Earth to an unexplored star cluster, let each player control one fleet”. These scenarios can vary in scale, and contain static elements in addition to the procedurally generated world. The milestone concentrates on playing as humans; no sentient alien species will be included. The exact scale and scope of this milestone haven’t been decided yet, though most likely it will be on fleet level rather than individual ship level.

Now, Milestone 1 is really a full game in itself, so there will definitely be sub-milestones. After Milestone 1 is complete (or abandoned ), I will review the situation and decide if I want to continue with expanding the concept or doing something else altogether.

For now, I’m still working on getting rendering working again. I fully switched from Pygame to Pyglet as my main “platform” library, and I’m glad I did, since it’s much easier to work with. Basic resource management also works again, and now I’m working on scene management and the OpenGL rendering plugin simultaneously. As soon as I get some really basic rendering working, I’m going to start working on the game, and let that fully drive development on the engine side.

Tags: game design, Pyglet, Red Nebula