Sea Battle is a casual 2D real-time strategy game with a pixellated ‘retro’ feel, based on the multi-component vehicles of RTS games such as Warzone 2100. It was written as an experiment in building games using the Processing language.
Sea Battle was prototyped and launched in 2010.
The distinction between surface ships and submarines in Sea Battle has turned out to be a more thorny issue than I originally imagined.
The original plan was to have two classes of vessel, based on their hull types – ship or submarine – and weapons that could hit ships, submarines, or both. A future update could also have included aircraft “hulls”. However, the more I think about the game balance issues, the less I’m convinced that this is a good decision with the tech tree and playing field size that Sea Battle currently has.
Sea Battle’s tech tree, as it currently exists, has four straight “trees” with 10 items in each. By and large, each component that you research is better than its predecessor. (Later hulls are heavier and take longer to build, so small hulls are still useful. However, you would rarely want to choose anything other than the best weapon, engine and radar that is available to you.) Combined with the small playing field, this makes for a fast-paced game of a few minutes, with each player researching and churning out ships constantly to gain the upper hand.
There are a number of reasons why the current tech tree is inappropriate for submarines. Firstly, the weapons that a submarine could have: there’s only two. The Sting Ray torpedo (weapon 8) and Tomahawk missile (weapon 9) are the only weapons appropriate to be fired from a submarine. This would make rushing down the hull tree to submarines pointless unless you’d already reached near the end of the weapons tree — and in most games, you don’t even get that far.
It also creates a UI complication, in that currently, any combination of hull and weapon is permissible. Submarine-appropriate weapons would break that behaviour.
There’s an issue with anti-submarine weapons too. Again, only two (Depth Charge (6) and Sting Ray (8)) are appropriate for use against submarines. But since a viable submarine build wouldn’t exist until Hull 6 + Weapon 8, they would only exist in the late game, at which point Depth Charges just can’t hold their own against other weapons — so why have them at all?
To abuse game theory, the logical choice is for players to build Depth Charge ships when they become available, then hold them in reserve as insurance against their opponent building submarines. But if you see your opponent stocking up on Depth Charge ships, you might as well not bother building subs and just go for better weapons and radar instead. Whoever commits to a strategy first ends up on the losing end.
To cure these problems, perhaps we need to take another lesson from Warzone 2100′s book and have separate tech trees for different weapon types. So rather than one tree of 10 weapons, we have two trees for anti-ship and anti-sub. (And potentially anti-air later.) If we’re going down this route we ought to have different hull trees for ships and subs too. But at this point it’s turning into a rather different game — a slower, more traditional rock-paper-scissors RTS. But these games benefit from larger playing fields, varied terrain and squad-based combat — none of which Sea Battle is particularly well suited to in its current form.
So the question stands: Do I expand Sea Battle significantly to include this extra complexity, on the understanding that I would probably need to rewrite it in something other than Processing and that may consign it to the pile of “projects I lost interest in”, or do I just ignore the issue and for the sake of simplicity not treat submarine hulls as any different from ships?
Another day down, and somehow Sea Battle is remarkably close to the finish line. (No idea what I’m talking about? See previous blog entries 1, 2 & 3.)
First things first, my failings: CPU use and mouse sensitivity are still not fixed. I’m now having to re-render more of the window on each refresh than before, so if anything they might be slightly worse.
On the Facebook thread, Scott and Mark mentioned an AI issue in that a suitably scary player ship, when parked close to but slightly off to one side of the enemy base, will be ignored by enemy ships in favour of attacking the player base instead — even when they have no hope of destroying the player’s base before their own is destroyed. As far as I know that issue is still there, though improved enemy research and build AI should mean the enemy is pumping out ships just as scary as yours.
On to the new features:
And bug fixes / tweaks:
Still to come:
If you’d like a good strategy for beating the game at this point, I recommend you begin by keeping your build queue about 3-4 ships full, building the best thing you can at any point. Research-wise, rush down the weapons tree as far as Harpoon missiles, throwing in a couple of hulls and radars. Avoid engines for now. As soon as you have Frigates with Harpoons and Radar Mk 4, keep building them until you’ve fended off all the enemies near your base and you have a fleet of 15-20 of them, then move them all right up to the enemy base. With that fleet you should be able to destroy the base before the ships they build wear yours down too much.
You can play the current version of Sea Battle as a Java applet by clicking here.
Another day — or three, in this case — brings another ton of functionality for Sea Battle. (Previous posts: 1, 2)
Today’s release reduces the target frame rate from 60 to 30 frames per second, in an attempt to alleviate the CPU hogging reported by aefaradien in the previous post’s comments section. As I said in the comments, it’s not an issue I see on every machine, so I’d be grateful if any testers could tell me what PC setup they have, and how much CPU power the game takes up.
Today’s version also fixes the spinning ships bug that just about everyone reported. What it doesn’t do is make mouse clicks any more responsive, which is annoying me too. Please bear with it for today, I’ll see if I can work out how to deal with that soon.
Mostly this release is about new features. Sea Battle now has:
The only real bit of functionality that’s still missing is the research / build options. Currently, clicking the Build button produces a ship of a predefined configuration — you can’t change that config or research better ones. The AI builds random ships up to and including as powerful as your default one, and has a reasonable amount of ‘thought delay’ to its actions, meaning that you can achieve victory fairly easily. (Just fill up the build queue and send every ship North as soon as it’s built — you’ll lose a few, but enough should survive to destroy the enemy base.)
You can play the current version of Sea Battle as a Java applet by clicking here.
Note: this blog post is old, and the applet now has more functionality than is described here. The next blog post in the sequence is here.
Nearly a month ago now, I blogged some sketches and ideas for a game I felt like writing. masterofwalri made a passing reference to Processing in his comment, and having heard people mention it in the past, I figured I should check it out.
I’m very, very glad I did.
It neatly deals with the issue of what I should develop for. The comments were leading me down the Java path anyway, but Processing’s two-click export to Applet and bundles for Windows, Linux and Mac OS sealed the deal. And it’s easy to program in too — it’s clear that it’s beginner-oriented, but it’s also ideal for simple games like this as it simply removes all the starting faff, like sorting out JPanels and TimerTasks and all the rest. Time will tell if Processing over-simplifies things and stops me doing something I want to do, but for now it is excelling at the main task of high-level programming languages — reducing the amount of brain overhead I need to allocate in order to talk to the computer.
One lunchtime has produced 270 lines of code — which already includes the game area of the GUI, controllable player ships, and the beginnings of AI for the enemy ships.
You can play around with it as an Applet here.
Note: this blog post is old, and the applet now has more functionality than is described here. The next blog post in the sequence is here.
Currently there’s no real gameplay — you can’t build, and ships can’t shoot or be damaged. You can move your ships (starting at the bottom of the screen) around, and the AI ship will hunt yours. Click on a ship to select it (blue circle), then click elsewhere to set its destination. Red lines, when they appear, show when ships would be shooting.
The next block of code will give the ships customised gear, health points, and the ability to attack and sink others. With that will probably come attack animations, which with my lack of skill in that department, will take a while. After that, damageable bases and win/lose conditions, then the build/research system. Finally, graphics tweaks, AI improvements and game balancing will finish it off.
More bloggery will appear once more coding occurs!