Tag: Games

    Blast From the Past: Dragon’s Claw’s Chromatic Skill System

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Back in the dim and distant past of my school days, Dreaming Awake was called “Dragon’s Claw” and was going to be a video game rather than a book. As far as I can tell from trawling the Internet Archive, not much was posted about it online, but for some reason today I remembered the design work we did on its skill system.

    To my knowledge no game since has implemented something like this — probably because it’s not a particularly great idea — but it has a certain elegance to it so I thought it worth documenting.

    I think we called the skill system “Chromatic”, or maybe “Prismatic”. Something like that. It was based on the Hue, Saturation and Luminance method of specifying colours on a video screen.


    If you’ve ever used a paint program on a computer, you’ve almost certainly encountered this style of colour picker before. There are three axes to it: Hue, which specifies the colour, Saturation, which specifies how ‘colourful’ (as opposed to grey) the colour is, and Luminance, which specifies the shade of the colour from black to white. (Some systems use Value instead of Luminance, the difference is somewhat technical.)

    In Dragon’s Claw’s system, the Hue of the colour represents the elemental association of the skill, along a continuum. So for example, Fire-based skills have a red hue (approximately 0 on the scale), Water-based skills have a blue hue (approximately 170 on a 0-255 scale). Something like the diagram below — there were more elements to fill up the remaining space, but I forget them now.

    The Saturation of the colour represents the transition between physical abilities and magical abilities, with the physical ones being less colourful and the magical ones more so. For example, the magic spell “Fireball” might be bright red, while “Flaming Sword” is still the same hue but more physical, so has a lower saturation.

    Luminance is a continuum between white and black, and represents the balance between “good” and “evil” abilities.

    If I recall correctly, while abilities were balanced fairly well across the hue and saturation spectra, the majority of abilities clustered towards the centre of the luminance spectrum as the abilities themselves could rarely be said to be good or evil.

    Each character had an innate “colour”, which represented their central position within the three-axis ability spectra. At level 1, a character would be able to use an ability only if it was within 1 integer of their colour on each spectrum. For example, if Rosa has a colour of Hue 0, Saturation 255, Luminance 128 (primary red), she can use any ability with Hue 255-1, Saturation 254-255, and Luminance 127-129. This is a pretty restricted set, although each character would have been designed such that they started with at least one ability.

    As each character increases in level, the “sphere” around their innate colour expands, and if any new abilities fall within that sphere, the character learns that ability. By level 100, each character can use a sizeable proportion of available abilities, but never the complete set.

    As the character uses abilities, their innate colour changes by a fraction towards the colour of the ability used. In this way, characters’ ability sets can be customised however the player wants, simply by practicing abilities in the right “direction”.


    I always thought this was a pretty neat way of determining which characters can use which abilities, and the fact that characters get better at certain types of ability simply by practicing them or similar ones, is definitely appealing.

    The concept of skills as a continuum also allowed for interesting benefits from the use of weapons. Swords, for example, might increase damage dealt by low-saturation (physical) skills, while staves might increase damage for high-saturation skills. A mace might benefit high-luminance (good) skills, while a dagger might benefit low-luminance (evil) skills.


    There are a couple of big disadvantages, not least that we never found a good way of representing a 3D cube of colours to the player — we were limited by the ability of 2D screens and human eyes to see all three axes at the same time.

    Certain areas of the spectrum were also rather sparse — certain hues, saturations and luminance ranges had a lot of abilities in them, while others had fewer, and characters with innate colours in those more sparse ranges would find themselves without as wide a choice of abilities as others.

    The system also scales badly with level as originally designed. Each increase in level expanded the “sphere” of a character’s potential abilities in three axes at once, so an increase of n levels results in an increase of n3 volume. The result of this is that characters’ rate of picking up abilities becomes exponential. A logarithmic increase in sphere radius would have been a better idea to control this.

    Alongside the difficulty in displaying the colour cube, it would also be difficult for players to discover the locations (i.e. colours) of new abilities that they may want. A lot of work would be needed in suggesting to the player which abilities they might want to practice, and what new things they would learn if they did.

    Adventures in Emoji

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Yesterday, a friend of mine started me on a quest that was to be filled with despair. It started innocently enough.

    I gleefully replied with my 140 character attempt at making that come to life (each Emoji counting, as I would later discover, as two normal characters).

    Well, that didn’t look like a bad start. There were some alignment issues there, probably because Twitter uses a proportional font. Nothing that a couple of <pre> tags couldn’t solve!

    Oh, how wrong I was.

    Twenty-four hours later, this is what I have to show for my efforts:

    Well, it’s a whole screen of Rogue-like, which is not bad. But despite wrapping the whole thing up in <pre> tags, there are still alignment issues.

    Lesson 1. Not all Emoji are a fixed width.

    Lesson 2. No Emoji are the same width as a half-width or full-width Unicode space.

    This will become important.

    You may also notice that the picture above isn’t a nice <pre> block full of text that you can copy and paste. That’s because, after hours of tweaking to get something looking vaguely presentable, I decided to see what it looked like in a different browser.

    And even in the same browser, with a different monospace font:

    Lesson 3. The width of an Emoji — and even one of the Unicode spaces — varies from font to font.

    Before I even got to that point, though, I was nearly thwarted by an even more frustrating issue — actually laying out the Emoji in a text editor.

    I assumed that in the world of monospace text that editors inhabit, these problems of layout would be avoidable. Any modern text editor should allow me to edit a bunch of Unicode characters in a regular grid, right?

    Of course not.

    My first attempt was using gedit, my GUI editor of choice. It happily allowed me to mix standard ASCII and Unicode characters. When I inserted a space between ASCII characters, it was about 20px wide — so far, so good. But when I inserted a space, even a Unicode full-width space, between two Emoji, the result was only 10px wide. The browser renders the spaces correctly, so to look right in the browser, all spaces had to be half as wide in gedit — useless for drawing a dungeon layout.

    I resorted to vi, my console editor of choice. My console font happily supports Unicode, so this should be no problem!

    Of course not. For a start, keypresses in vi insert one byte at a time, meaning that every other keypress misaligns every subsequent two-byte Unicode character on that line. And then there’s the quite bizarre way in which it decides to write characters on top of each other.

    My third and almost bearable choice was an odd one. I figured that if I wanted the same look in my editor as in the browser, I should use an editor that runs in the browser. I chose the Chrome extension Caret.

    At last I had something almost usable, although the misalignment of characters rears its ugly head here too. There’s the infuriating bug that this only applies to characters on the screen, not the cursor position. 70 characters into a line of Emoji, the cursor position can show up almost two characters away from the text it actually sits at.

    Lesson 4. There’s not a single program in the world that renders Emoji the same as any other.

    Last but not least, there’s the matter of Emoji fonts.

    On my Linux machine, my browser and my text editor at least use the same set of monochrome Emoji symbols. But view the same page on an iOS, Android or Windows Phone device, and you’ll discover they have their own platform-specific Emoji fonts which are specifically designed to look great while ruining your attempt at cross-platform compatability. Here’s what our Rogue-like looks like on Android, showing off the inevitable inconsistent widths:

    If you’d like to post your hard work to social media sites, you may also discover that Twitter has its own set of unpredictably-sized Emoji. Facebook will at least use your system font when you post Emoji, although trying to edit a post with Emoji quickly results in a field of “your encoding is broken” rectangles.

    Lesson 5. Despite Emoji having existed for over a decade, and having been incorporated into Unicode for half that time, Unicode fonts and particularly Emoji in them are a complete mess of incompatible typesetting and platform-specific weirdness. They are not yet suitable for use in layouts — and thus, sadly, for making Roguelike games.

    For the curious, here’s how my Emoji Rogue-like would render in your browser. If you use the Cousine font in Chrome on Linux, this might look alright! If you’re using anything else, this is probably a horrible mess.

        🔳🐍             🔳                        🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳      
        🔳      🐂       🔳                        🔳        🍖                  🔳      
        🔳               🔳                        🔳          🍖                🔳      
        🔳🔳🔳🔳🔳🔳🔳🚪🔳                        🔳                            🔳      
                     🔳  🔳                        🔳🔳🔳🔳🔳🔳🔳🔳🚪🔳🔳🔳🔳🚪🔳     
                     🔳  🔳                                       🔳  🔳    🔳  🔳      
      🔳🔳🔳🔳🔳🔳🔳🔳🚪🔳🔳🔳                                  🔳  🔳     🔳  🔳     
      🔳        🐀           🔳                                  🔳  🔳   🔳🔳🚪🔳🔳🔳  
      🔳  🔳                 🔳                   🔳🔳🔳🔳🔳🔳🔳🔳  🔳   🔳     🐉  🔳  
      🔳  🔳          🐀     🔳🔳🔳🔳🔳           🔳                 🔳  🔳  💍     🔳  
      🔳  🔳                 🚪      🔳           🔳  🔳🔳🔳🔳🔳🔳   🔳  🔳🔳🔳🔳🔳🔳    
      🔳  🔳  🎫             🔳🔳🔳  🔳           🔳  🔳         🔳  🔳                  
      🔳🔪🔳                 🔳  🔳  🔳           🔳  🔳         🔳  🔳                  
      🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳  🔳  🔳           🔳  🔳         🔳  🔳                  
              🔳         🔳      🔳  🔳       🔳🔳🔳🚪🔳🔳🔳🔳🔳🔳🚪🔳🔳🔳              
              🔳  🐍     🔳🔳🔳🔳🔳  🔳🔳🔳🔳🔳          🐍              🔳              
              🔳    🐍   🚪                   🚪      🐍  🐍🐍💥🚹        🔳              
              🔳         🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳        🐍        🍖      🔳              
              🔳🍗       🔳                   🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳🔳              
    Level:1     Hits:14(14)   Str:15(15)   Gold:34    Armor:1   Exp:20/23

    The limited set of Emoji currently available also causes a number of other issues with creating a Rogue-like using the characters. For example, the character set currently does not contain glyphs for:

    • Stairs
    • Treasure chests
    • Corridors
    • Kobolds
    • The Amulet of Yendor

    I’m sure the Unicode committee will be working on these soon.

    The Lego of Tomorrow

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    “All I’m doing is building stuff,” Joseph says.
    “That’s what Minecraft is good for, isn’t it?” I reply. “It’s like Lego with infinite pieces.”
    “Yeah,” he says, and turns back to his computer screen; back to the childhood task of creating the new.
    I turn back to the washing up that I was in the middle of, back to my adult role of cleaning and tidying and preserving that which already exists.

    It feels odd to be writing about Minecraft in 2014. Following its 2009 “alpha” release, it quickly became the darling of the indie gaming world. There’s not a lot to say about it that hasn’t been said by countless reviewers and bloggers over the intervening years. I’d played it myself a few times—I made my character wander around, mine some rocks, fight some monsters, craft a few things. But I never “caught the bug”. That’s the all-too-adult brain at work again—I looked at the landscape and appreciated it for what it was, not what it could become.

    Today though, for the first time, I saw Minecraft through the eyes of a child.

    Joseph's first steps in Minecraft

    Raised on a self-imposed diet of videogames since he was old enough to shake a Wiimote, our son has never had the enthusiasm for Lego that I did at his age. While I would disappear to my room for an afternoon to build, he always wanted to spend it with gamepad in hand. On occasion I despaired for him and his generation. I worried that their entertainment had become so pre-packaged and targeted that they wouldn’t want to create their own games. How could silent, limited, awkward Lego sets compare against a million man-hours of Nintendo’s finest creators delivering pure entertainment?

    But now I sit and watch Joseph at work, and I know how wrong I was.

    As night falls, his character flies up over the landscape and looks down to behold all that he has created. Torches spread out across the world like the fires of a nascent civilisation, casting light upon those things that human hands have built.

    Torch-lit buildings at night

    There are houses, now, where once there was only grass. Some of the roofs are made of coal and supported only by bookshelves and hay bales, but they are houses nonetheless. They are dry when the rain pours outside. There was a bed for his character to rest in, but now there are more than a dozen—for his character’s parents, siblings and cousins, Joseph explains.

    There are railways that connect them over fragile bridges far from ground. There is a torchlit tunnel beneath the surface, joining the houses of the tiny village to the woods where sheep and cows roam. There was a spider that “freaked him out”, so Joseph’s character started to carry a sword with him at all times.

    The environment, once wild and random, was being tamed.

    Then Joseph noticed that water would flow if the ground around it was removed. The great lakes of his world could be channeled. The tunnel became a great underground river, bringing water near to the houses of his people.


    He built a black-lined room carved out of a hill, and decorated each block with a torch.
    “It’s a Christian place,” he explains. “My character is a Christian.”
    I had just watched that nascent civilisation invent religion.

    Dawn breaks. Among the high forest canopies there now stands something else—a tower, built on lowlands but rising taller than the hills. It is a vast structure of stone and glass and, for some reason, pumpkins. It is not built the way an architect would build, but nor does it look like a work of nature. It is the work of an almighty creator not restricted by principles of gravity or shearing moments. It is not utilitarian; not a house or a bridge or a water channel. It is something that was built just because it could be built.

    The land was tamed, now; the world mastered. And so his one-man civilisation had reached for the stars.

    A Tower Taller than the Clouds

    I am no longer under the illusion that neat, rail-roaded videogame adventures will leave us a generation lacking the desire to create for themselves.

    He may not spend his afternoons building Lego cars, but that’s okay. Within the last four hours I’ve watched him take a world of random-seeded entropy and transform it into a place where bridges of stained glass tower over the skies.

    I think our children’s generation will be just fine.

    Stained glass bridge

    Glitch: A Beautiful Something

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    My name is Cheesefish, and against all logic it is one of the more mundane names I have come across. I am wearing a sari and I have a fox on my head. My hobby: squeezing chickens. My mission: to become the finest chef the world of Glitch has ever seen.

    Glitch is a browser-based, entirely combat-free, massively multiplayer online game. And for the last few days, it has been something of an obsession. It is Maple Story, if Maple Story cut the combat (and the Korean-ness) and focussed solely on exploration and crafting mechanics. And it’s the exploration that makes it. As a 2D scrolling flash game, there are none of World of Warcraft or Guild Wars’ sweeping vistas here, but it makes up for it in variety. One moment you may be exploring a lush and utterly normal forest, but one stop on the ever-present intercontinental subway drops you off in a land of pastel where the hills have eyes.

    Stranger places still await the intrepid explorer. Keita Takahashi, creator of Katamari Damacy, has had his hands on this game and it certainly shows. (The other more recognisable members of the team are, bizarrely, the founders of Flickr.) There have clearly been some… unique minds behind the design of this game, which become most apparent when acquiring raw materials from the environment.

    Need meat? You get it by nibbling on pigs, but only after petting them. Milk? From butterflies of course, but they must be massaged first. Grain can be obtained by squeezing chickens, but eggs? Oh, right. Egg plants.

    From the odd interactions with fauna to the bizarre contraptions you can use, the ever-humorous quest descriptions and the pet rock that does your learning for you, there’s a strange sense of humour at work here and it works very well indeed.

    Glitch is also an example of one of my most hated things – an Energy-based game that has no end. But here, it doesn’t feel malicious like the game-killing ‘games’ of Zynga and Playfish. Energy is plentiful and refills completely every few hours, and even with my character’s mediocre cooking skills, she can easily whip up enough odd food and drinks to keep her energy and mood full. Skills are learned over minutes, hours or days of real time, but again unlike FarmVille and its kin, they’re not just a mechanism to drag you back to the game. There doesn’t feel like an urgency to get them learned, and besides, you can manage them from the website or the iOS app without having to touch the game itself.

    So what the heck is Glitch? It doesn’t seem much like a game, as there’s no way to win and no reason to compete against anyone. It’s a world to explore, to create and add to, and apparently, to hold farmers’ markets in.

    It resembles nothing quite so much as a twenty-first century upgrade of the MUSH, the shared environments from the early ’90s. If it allows anything like a MUSH’s ability for players to create and expand the world, it will be a wonder. But creating with text is easy; doing so with graphics much more complex, and I can’t imagine the company behind Glitch giving up creative control so readily.

    But even without that, even without an idea of what it is and what it’s going to be, it’s certainly a beautiful something.

    Sea Battle: Of Ships and Submarines

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    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?

    Sea Battle: Here Comes the Science Bit

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    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:

    • All 10 hulls, weapons, engines and radars are now implemented

    • You can now choose between them when setting build orders, so you can build in whatever configuration you like

    • Research is now implemented – click on an unresearched component to start researching it

    • You start the game with only basic components, and must research more to survive

    • Colours: Grey – not researched yet, Green – researching now, White – available, Yellow – selected (clicking Build will build this)

    • Enemy AI now handles its own research

    • Enemy AI now builds intelligently rather than randomly

    • You can now drag a box to select multiple ships

    And bug fixes / tweaks:

    • Base health significantly increased

    • Building a second ship without moving the first no longer places them on top of one another

    • Pathfinding code tweaked to cope with much faster/slower ships now all the hulls and engines are available

    • Fixed an issue whereby the blue radar circles were drawn at half the ships’ actual radar range

    Still to come:

    • Ship / submarine hull and vs ship / submarine weapon distinction

    • Tweaks to enemy AI

    • CPU use / mouse responsiveness fixes

    • Menu system and difficulty picker

    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.

    Sea Battle: That’s what Guns are for!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    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:

    • Ships are now implemented as having separate Hulls, Weapons, Engines and Radars

    • Ships can shoot at each other (finally!)

    • Ships have health (and health bars), and can be destroyed

    • Bases have health (and health bars), and can be destroyed

    • That means there’s now a win and a lose condition

    • Enemy ship AI now considers your ships’ scariness – a factor of firepower and remaining health – to pick targets it thinks it can defeat

    • You can now build, with appropriate build delays and an 11-slot build queue

    • The enemy can now build too

    • Colours have been tweaked to make ships’ allegiances more obvious

    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.)

    Note: this blog post is old, and the game now has more functionality than is described here. The next blog post in the sequence is here.

    Sea Battle, now with more Processing

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    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.

    Note: this blog post is old, and the game 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!