Main image of article Web Game Development: The Venture Begins

Summary

I'm setting up a Web game. Actually I'm going to be setting up two of them, one I can talk about and discuss the design here, and one that I can't until it's ready for beta testing. In this series of articles, I'm going to be looking at all aspects of setting up and running a web game. The series will look something like this:
  1. Game Design
  2. Game Implementation
  3. Setting up a game server
  4. Implementing the Browser client
  5. Implementing the back end
  6. Admin and Security
  7. Monetizing the Game
  8. Anything I've forgotten
I've just started renting a Virtual Private Server (VPS) and in the first 24 hours discovered a few gotchas; the joys of self administering! I'll come back to those in a future article in the series. Here is the game design prior to starting development. Expect it to change but not by a lot. The game has the domain name http://webgame.im (It's not live yet— still being developed!) and is a 6-50 player strategy game of conquest. Starting on a large continent (possibly two or more smaller continents), each player begins with a variety of little empires with towns and cities. Your job is to conquer the world by capturing territory and defeating other players. It sounds a little like Risk but it's not, for instance it uses simultaneous play not sequential turns like player 1 moves, then player 2, etc. This is a semi real-time game with a turn lasting a pre-specified period of time — typically two hours. You can login anytime before the turn is processed and add new armies and give orders to move them. Then every two hours, all orders are processed, armies move, fight, and new armies become available. You can see the results of combat and the size of your empire and start giving orders for the next turn. The game is played in your browser. While it would be possible to process turns in real-time (or at least once a minute), not everybody could manage to play at that speed. However it is configurable so when the game is created, the number of players, map size and game turn time are entered and fast games are possible. The draggable scrolling map is made up of a large number of hexagons. These are sea, open land, mountain (impassable) or open land with a town or city. Possession of town and city hexes are important and provide you with extra armies each game turn.  Possession will be shown by color, shading, small digits or a border round the block. The image shows one possible layout created with the paid version of the excellent shareware tool, Hexographer. Here every occupied hex has a border and a number showing the owning player's number. The large number in some owned hexes is the army size. Making this scroll smoothly will be interesting but I believe it's possible, using the HTML5 <canvas> tag. There are a few libraries and frameworks I have to investigate. After logging in to the site and joining a new game, you'll see the game map and a mini map that lets you move quickly round the main game map. You'll see a number of armies available as reinforcements and you can add these to any hexagon you own by clicking the add button and then clicking on the location. Once the total reaches 50 in a hex you can't add any more. You can give two types of move orders.
  1. Order all or some of your armies to move to any other hex you own in the same contiguous block. Reinforce or split them.
  2. Move them to any non-mountain land hex that you don't own next to any hex that you own in that block.
Any hex that has had an order is grayed over. A unit can move to the nearest (non-mountain) land hex across the sea in one turn that isn't occupied by another player's armies. Each order is added to a list of orders on the right hand side. You can click on any order in this list to see it, and tick the check box and the cancel order button to remove it. Once you click the confirm button, all orders in the list will be saved for processing and removed from the list. Orders can be saved for processing at any time up until the turn is processed. All orders are processed at the same time and a list of battles to be resolved is built up then processed. If an army moves into an empty location then it captures it. If it's a town then one army is lost, if a city then three armies are lost. So moving in less than four armies into an enemy city or less than two into a town will not capture it. There are two ways combat can happen: If armies from one hex attack other player's armies in an adjacent hex; or, if armies from two adjacent hexes attack each other at the same time. In both cases a battle takes place. Each army has a 50% base chance of destroying another. If one side is twice as big as the other then the larger side has a 60% chance, and at three to one it becomes 70%. Both side's casualties are resolved at the same time and removed simultaneously. Combat continues until one side's armies are all destroyed. If the victor was attacking, then their surviving army captures the target hex. At the end of the turn, in each block of contiguous hexes, the number of hexes plus an extra 1 from each town and 3 from each city in the block are added up. From this is subtracted the total number of armies in existence in that block and if this is a positive difference, it becomes next turn's reinforcements that you can add to any armies or empty hexes in that block. But if the difference is negative it's a calamity and all forces in the block perish through lack of supply and there are no reinforcements to that block for one turn. I'll be publishing the other articles as the game develops, and these are initial design guidelines and not set in concrete. Touch wood I'll have it ready to play by the time the last article is published!