YAASL. The easy stuff!

Breaking the laws of user interface design is a major talent of mine.  It's always the last thing on a developer's mind, and one always longs for the days where the primary problem is how something looks.

With that said, here's the start of the interface with a few extra bits:

So - we now have a scrollable, zoomable lettered/numbered hexgrid, some functional dice buttons and the beginnings of a log window and information bar.

Next up is to to define a basic scenario (and I do mean basic!) - and have the interface accept moves, through to completion of the game.

So - by next time we'll see a couple of squads, a way of moving through the turn sequence and a resolution window.

The rate of return at this stage of a project is always high.  It's the fun stage.  Big looking things ("a map" - "a dice roller") are trivial in comparison to figuring out the mechanics of how bypass movement or the interface for defensive fire will be implemented.  Keeping up that kind of energy required is near impossible when you don't see the instant gratification of a major functions spring to life so it's important to take small steps and to set realistic goals.

Don't throw away your stuff just yet!

YAASL

(Yet Another) ASL implementation?

For those on the linux scene (I barely scratch the surface of that wonderful world) there's a common theme - the "Yet Another..." [insert favourite application/utility/idea]  The internet is full of well meaning people who start another unoriginal project, destined never to fully complete it and this little project is going to be another one of those!

There are other implementations out there.  JASL, up until 2004, got mighty far and is certainly the leader in the race for a computer emulation of ASL.  There are without a doubt others out there, I saw a flash based one somewhere, and there are others to be sure. It's a tricky beast, full of rules but the real issue is the exceptions that almost every scenario has via the Special Rules.  It's one thing knowing you have a great specification of the system in the rulebook but effectively breaking those sub-components in every scenario makes creating a workable system immensely hard.

That's a long introduction to set expectations low.  However, it's something I've kicked around for years.  I've always stopped because, quite frankly it's an impossible task.  Trying to squeeze in the SSRs for secret movement DRs, subterranean movement, unique HOB results and the like that two players can (usually) instantly understand and comprehend is just too daunting.

But, like the old saying about eating elephants one bite at a time, I intend to approach the project bit by bit. First, set up an empty board, have a couple of squads on each side, and play a scenario that says last remaining squad wins.  Right there is the essence of the game.  Move, shoot, resolve the scenario.  The rest is "simply" chrome!

So, seeing as we start from the beginning, and this blog is now going to take on a journey of the development pitfalls, here we go.  The first screenshot!

Not much, eh.. But - like a how an artist sees a blank canvas, I see opportunities leaping out at me!

Of course - astute players will already spot the problem of the half hex (even they're a pain in computer ASL, - is it a hex, a half hex, how do we count off-board hexes!?  Urg - all these things that as players, we take for granted.

As you can see, rather than a blank canvas I also see a whole host of UI, programmatic and copyright challenges, but we'll tackle them one bite at a time.

Next up will be the first stab at the basic UI.  We need to show turn number, phasing player and the phase of the turn.  Oh - and maybe a nice zoom function.  Ok - back to work!