This article documents the first step in building a new strategy web game. The design phase is a critical phase which often gets overlooked by developers who want to get stuck into code. And truth be told, I’m one of those developers.
Its very easy to dive into the code before you have a solid design and whilst its probably a mistake to get too far into development without a clear idea of what it is you are developing, sometimes its fun and useful to get something working before having all the details worked out. Abstract ideas often fall apart when faced with the reality of a working model and often the finer details need to be left until after the foundation of the software has been laid. However, there’s been many a failed project that rushed to code without a clear vision of what it is to be achieved. And when working with a team of other developers or designers etc, it becomes incredibly important to have a clear understanding what it is you are trying to achieve so the importance of design, planning and documentation increases.
That said, what I’m concerned about is designing a game that I will develop by myself (at least for the foreseeable future) and what I need to start me off is a good idea of what the game is about and how it might work. So besides avoiding my usual shorthand in my outlines, I’m going to replicate that process here.
What kind of game?
The first question I’m going to answer is perhaps the most important. Whilst I’d love to one day try to develop something completely unheard of before, this project is going to be fairly well-defined by its genre: a space strategy tick-based web game.
Setting: Space
The setting is more than just colour, it is very important in the design of the game as it sets the tone, map and defines what kind of tokens the players will be dealing with.
The map will consist of galaxies, stars and planets. Galaxies contain stars. Stars contain planets (and similar entities). Planets are where players will be able to build bases and where most of the action takes place.
Galaxies will be a way to partition the play environment to allow different levels of players to co-exist. Basically, new players will be added to a galaxy until it reaches a certain population threshold after which a new galaxy will be used to house new players. Its not a fool-proof mechanism to avoid higher level players dominating lower level players (as galaxies are connected and not to be blocked off from expansion by established players) but it should help.
By tokens, I mean the pieces of the game players will have control over. This game will have effectively two types of tokens: starbases and fleets.
Starbases are your typical strategy game production / research / economic centers where the people live, things are learned and built. They are stationary being built on a planet.
Fleets will consist of units (starships) produced at starbases which can be moved from one planet to another. They may engage other fleets in combat or may try to capture starbases.
Category: Strategy
As a strategy game, players will be concerned with the macro-management of a number of resources, building bases and units, managing diplomatic relations and trade.
Every strategy game has a resource management aspect which is often the driving feedback response to motivate players. Collecting stuff, even virtual stuff, is fairly ingrained in our psyches and we seem to get quite a lot of pleasure in amassing things in games. There’s many ways to go on this from a single resource (representing say money or energy) to a multitude of items with their own attributes and uses.
We’re going to keep it simple but not too simple and have four resources: metals, carbon, minerals and crystals. The names just add colour but we’re going to also say that metals and carbon will be fairly common on all planets, minerals will be less common but still available in some quantity on all planets whilst crystals will be rare and only appear on some planets.
Metals and carbon are going to be our bread-and-butter resources and whilst there will be some diversity in their distribution, everybody should have plenty at their disposal. Therefore, almost everything that can be produced will use them in some quantity. We’re going to weigh starbase buildings to use more carbon than metal and we’re going to make units use more metals than carbon. That way depending on a player’s focus one or the other resource will probably be more important to them unless they take a balanced approach to building units and buildings.
The other two resources have specific purposes within the game ecosystem: Minerals are going to be useful in most of the expensive things players want to use and I can see it being the defacto currency (more on trade later). Crystals will be needed to unlock the advanced tech items within the game and will be a source of conflict within the game.
Resource collection will be done primarily through specialised buildings at starbases. Later on I will consider having units capable of harvesting resources outside of planets and what to do with destroyed units. Resources will be located at a particular starbase and will need to be moved before they can be used by another starbase.
Trading will be done in a fairly simple way. Each starbase will have a transport capacity based on the presence of a special type of building called a spaceport. This capacity can be used to offer resources on the galactic market for another player to buy or to transfer resources to another base.
Besides the four resources mentioned two other limited resources will come into play: colonists and energy. Colonists represent the population of starbases whilst energy is produced by power plant buildings and used by every other buildings. The purpose of these resources is simply to provide friction to growth as well as to add colour. Colonists will need housing which needs to be built and most buildings will consume energy which needs to be produced by power plants. Neither are harvested in the way the other resources are nor are they tradeable or moveable. They will be limited by the capability of the planet the starbase is located upon: a planet’s fertility rating determines the cost of building habitation for colonists whilst energy is collected via solar rays (which vary based on the closeness of the planet to the star) and gas emissions (with some planet types being better for this resource). There will be a few additional energy producing plants that don’t rely on the planet but they will be expensive.
So like a typical strategy game, players first objective is to maximise their harvesting of resources to allow them to expand their starbases. They may expand beyond their initial starbase using colony ships or trade for resources they may be short of.
But that’s all foreplay because what makes a game is conflict and for that we have fleets. They are effectively mobile tokens that are used to trigger combat which can reward resources (based on units destroyed) and experience. Experience will be used to train starbases or fleets to have enhanced abilities.
But free-for-all combat is not much fun long-term and the chaotic universe it represents gets very two-dimensional after a while so we’re going to have in place a fairly well developed diplomacy system. Players will be able to form and join alliances who may stake a claim to a particular star system, declare war on other alliances or agree non-aggression pacts and the like. Alliances will have a number of tools to help communicate between members and a command structure that should be reasonably flexible to allow different types of alliance leaderships to develop.
Process: Ticks
Turn-based web games work similarly to board games or single player computer games found on your desktop. Basically, you give orders to your tokens (in this case bases and fleets) and when its “your go” they carry out those orders as well as they can. In a board game / single player computer game, “your go” is literrally a round-robin mechanism wherein each player (including computer players) takes a turn and has a limited amount of actions they may perform with some actions taking more than one turn to complete.
This is usually accomplished in web games by giving each player a number of Action Points (or something similar) which gets replenished at a set time (usually once a day). This is actually very popular mechanism for roleplaying PBBGs.
This is in contrast to “real-time” games where actions are taken simultaneously with each order given to a player’s token being scheduled to complete at a set time.
The approach I’m going to take is tick-based: Each action takes a number of ticks to complete. The engine runs a tick at a predefined interval (probably 15 minutes in this case) and any orders (or other events) that are due are triggered during that tick. You can perhaps say this is a sort of automated turn-based system. It feels like a real-time game in that actions take time to occur but updates are done at set intervals which is very turn-like.
***
Now I’ve outlined the kind of game, here are a few “user stories” that we’re going to develop:
Joining the game
Players need to sign up to start playing, providing a minimum set of information about themselves such as a login name, email address, password etc. Once signed up to play, some initial assets are allocated to them to begin playing with. Namely, a new starbase and some resources with which to start constructing new facilities.
Manage Starbases
Players will be able to see their existing starbases, presented in a tabular format with some pertinent information such as resource gathering capacities, energy produced / used, population supported / available, construction / research / production / transport capacity and of course, location. From this screen, they will be able to go directly to the detailed starbase view and the construction, production and research screens.
Facility Construction
Players can order new facilities to be built at their starbases using a tabular form which will list existing facilities as well as unbuilt facilities they can build based on their current set of technologies. Clicking on either a “Build” or “Upgrade” link will begin the process of constructing a new facility. Constructing new facilities will consume resources (based on the facility type and level being built) and take a number of ticks (again based on the facility type and level). Both resource cost and time taken is adjusted by facilities present and technologies known. A number of construction orders may be queued for each starbase.
Scrap Facilties
Existing facility levels may be scrapped by the starbase owner, returning the majority of resources used in the construction of that level to the starbase.
Unit Production
Starbases can be ordered to build new units from the unit production screen which lists all available units for that starbase. What units can be built depends on the facilities present at the starbase and the technologies known to the player. Just like constructing a facilities, resources are used immediately in production and take an amount of ticks (time) dependent on the facilities and technologies available. A number of production orders may be queued for each starbase. Units are added to a new or an existing fleet in orbit of the planet of the starbase at which they are built.
Research Technology
Starbases can begin research projects to make new facilities, units, other technologies or gameplay elements available. Technologies may have both facility and technology prerequisites which must be met before a starbase can begin research into them. Further levels may be researched into a specific technology for enhancements to the efficiency of a variety of gameplay factors (e.g. construction speed, unit movement speed, weapon effectiveness etc) or to unlock units / facilities / etc. The time it takes to complete research depends on the technology, level being research and the research capacity of the starbase. A number of research orders may be queued for each starbase.
Transport Resources
Players may use a starbase’s transport capacity to shuttle resources from starbase to another. The amount of time this takes depends on the distance between the two starbases and may be adjusted by known technologies. Until the resources are delivered, a portion of the starbase’s transport capacity is used up.
Offer Resources for Trade
A starbase may offer an exchange of some resource for another with any starbase (of any player) willing to meet those demands (see Buy Resources). In most ways this works as a two-way transportation of resources between two starbases using transport capacity and taking time to deliver once accepted.
Buy Resources
Players can search for resources offered by other starbases and provided they have enough of the demanded resource and the transport capacity at the starbase to complete the transaction may buy the resource.
Manage Fleets
Players will be able to manage their fleets through a screen which lists all their fleets, their current location and size as well as any movement orders they are making. From this screen they will be able to go to a detailed view of the fleet where the exact composition is shown and menu options for various fleet actions are presented.
Move Fleet
Players may order a fleet to move to another planetary body using the planet’s coordinates or a bookmark saved earlier, with special bookmarks available to the player’s own starbases as well as any starbases of other players they occupy. Movement is restricted for certain units which are either incapable of moving without being carried by units capable of carrying them (ie. fighters need to be carried in hangars of carriers or other capitol ships) or may not be capable of warp movement (and thus cannot move from one galaxy to another without the use of a jumpgate facility at a friendly starbase).
Attack Fleet / Starbase
Fleets may be ordered to attack a fleet and / or starbase in their current location provided it doesn’t belong to the same alliance. This initiates the combat system which we will discuss in more detail at a later time. Successful attacks against enemy starbases results in them being occupied and pillaged (to be detailed later).
***
And that’s it for the design so far. In the next tutorial, I’ll begin putting together the Ruby on Rails project and show how you can easily setup an authentication system for your game.