It’s been almost twelve months or more since we did anything of note with it, but we’re rather getting to like our old friend Flash again, these days.
A few years back, it looked like everyone had turned their back on the old Macromedia/Adobe offering, after Apple arrogantly refused to support the Flash player. So all the cool kids flocked to HTML5 and web-apps, and Flash was left with an uncertain future.
And because we’re planning to make our modular board game work on as many platforms as possible, what better development environment to make cool-looking software (Flash still does amazing time-line based animations) that can run on PC, Apple, iOS and Android. With the correct AIR runtime, it can even run on Linux and SmartTVs!
So we’re off and running, making a simple data-driven app to track our board game pieces as they move around the different segments of the playing area. So far we’ve managed to implement:
Snap-to-fit board sections which automatically snap to the edges of previously placed boards. As each board needs to be uniquely identified, each one will be programmed with a serial number into eeprom. This same number will be printed onto the board so after placing each board on screen, the user can tell the software the serial number used by each module.
We’ve also got a simple obstacle generator – used for wargames and the like, were buildings and other structures are placed on the playing surface. So far, we’ve got primitives like circles/ellipses and rectangles. More complex shapes can be created by overlapping two or more shapes
And we’ve managed to make the whole playing surface moveable and scrollable, using home-made pinch gestures, so the same code can be compiled down for smartphones and other, small-screen devices and still be useable (Flash’s inbuilt gesture libraries can be a bit “laggy” in detecting a two fingered gesture. Not that kind, idiot).
All communication with the board is through an extremely simple interface. The board game will simply report the changes in state of any square on the board, by reporting the serial number of the board piece, followed by the square number (and whether a piece has been lifted off, or put down onto, the board).
When a piece is put down into an empty square, a new playing piece appears on the board. In the final version of the software, we’ll probably have some kind of character selection screen, to inform the software of the type of playing piece being put down. For now, we just generate a generic character.
Pieces are placed by providing the board id and square number and clicking the appropriate button to say whether the piece is being picked up, or put down, replicating the way the hardware will work.
We’ve got basic line of sight working between two or more pieces, including the ability for one character to “sneak up” on another. Each playing piece has a “field of vision” of 180 degrees (this can be made variable for different character types). Not only does there need to be a straight line between the two pieces, but the direction that a piece is facing is also important as to whether or not it can see other pieces on the board
And all this means that we need to be able to turn playing pieces around. This can be achieved by sending a specific serial-based message (more on this later) but the software will also track from which direction a piece has come, and update the facing automatically:
And of course, no line of sight routine is complete without a few obstacles:
In the main, getting this far in just a few days has been pretty satisfying. It’s great to be coding in Flash/AS3 again, and it’s even better to see such positive results, so quickly. At some point, we’re going to have to get some help making it look impressive, but functionally, the software does everything we wanted it to.
The next step is to keep a track of which playing pieces have been “seen” at the start of each turn, and only reveal the opposing player’s pieces once they come into your line of sight. Then onto the juicy stuff that makes a tabletop war game – shooting things!