Steel & Steam is currently on the back burner while I’m riding high on the TOCS wave. In order to accomplish our goal of getting TOCS into the hands of other playtesters this year, there is a mountain of work to accomplish. Here’s the how and why.

Rules Review

The splitting of the original MASL rules into three parts has been done and all the information is there. However, it needs quite a bit of polish and reorganization. There are concepts that are introduced in the Core Set, which is proper, but the in-depth explanations can only be found in the WWII Era Set. For an explanation of era-specific information, this is fine, but there are some core ideas buried in there as well. As we have a plan in place to expand the system into WWI grand operational and grand tactical realms, however one defines such concepts, we need to make sure that the Core Set contains everything needed on a system-wide basis, especially as we also plan to expand into earlier combat eras as well.

Better Console(s)

While the term ‘console’ means different things to different people, we define the ‘console’ as the user interface between the players and the game engine and components. For some, this will be a browser window. For others, a dedicated Java application on their computer or Android device. For our playtests, Paul and I used the VASSAL shareware tool and it falls flat in the user experience department. It is more of a hindrance than a help. It is also nowhere near “state-of-the-art”. My standards for a wargame application include such things as counting MP expenditures and detecting moves across prohibited terrain as I move units on a map.

The console that we are going to develop will have in-depth map and unit knowledge and be able to detect and display in-game state information, even going so far as redrawing unit combat values based on its combat condition instead of requiring players to “flip” their own units and/or add combat strength chits and rely on object stacking. The console will not merely be a graphics object manipulation application. It will be a full double-blind wargame application.

Providing Services

Having a better console will mean next to nothing if it does not support excellent player communications and game state management. This will require a server to handle such things as comms and game state save and restore. This part is one of the trickier parts because, as the plan is to monetize this, the server must be able to handle credentialing in order to protect the user base from outside chicanery. Not only must we protect user’s identities and financials, we must also protect users from cheaters. This will be one of our biggest challenges.

The Technical Plan

Here is the rough plan:

• Provide public, protected and credential services via a web services API at known URLs
  • Current server code architecture will be Ruby-based and rely on PhusionPassenger, Rack, Sinatra and Crucible platforms
  • Crucible is my own web application framework which is based on the concept of API specifications and a “spec compiler” which checks the specification for correctness and emits code in a variety of languages.
• Provide a JavaFX application console which will communicate with the credential and protected services for game state management
  • Communication with the credential and protected services will be via the Crucible-generated Java class
• Provide a working TOCS scenario
  • TOCS scenarios will be on the server
  • New games will be initiated and maintained by the JavaFX console
  • The server will handle all persistent, multi-session game storage needs
  • Game component information will be transmitted to the console for rendering and management.
• Provide working User Account management

Note that this plan is very rough and glosses over a myriad of details. Any one of those bullets can spawn over 100 tasks easily. That said, I’ve been mulling these sorts of architectural design ideas for at least a decade. It’ll be fun implementing them.