The Proposal

Digital games, unlike traditional paper gaming, offer major opportunities to generate returns for investment in significant amounts. The TSWW digital games system will be marketed and developed via a new corporate entity, TKC Games Ltd.

A Growth Industry

Generally speaking, whilst board gaming as a whole has been a growth industry for the past 10 years with up to double-digit growth in overall sales globally year on year, conflict simulations are increasingly a dying breed in “old-fashioned” physical gaming, which is rapidly becoming a preserve of low complexity, short play, family friendly games.

This demise of the conflict simulation is not, however, mirrored in the computer and video gaming market, where major franchises ranging from Civilisation to Hearts of Iron go from strength to strength, whilst World of Ships, World of Tanks, Call of Duty and the like further cash in on the popularity of conflict simulation in differing ways.

More family-friendly games, ranging from World of Warcraft to MMORGs such as Eve Online, integrate conflict with fantasy and sci-fi topics. Massively successful, with millions of users globally, this market is ripe for a new concept; one which would if properly implemented be of vast interest to generations of gamers, as well as to people not normally excited by the idea of playing a “silly game”. This will be very true if it drew on the most effective elements of the most popular game types, whilst limiting (but not eliminating) the contentious “buy to win” nature of some games available.

Graph of development spend vs lower revenue projections
This is a chart estimating our start-up and ongoing costs vs the lowest potential revenue we expect to generate from a successful implementation of the digital product.

The Product Flow

TSWW is, currently, an “I go, You go” game system with each time period (half month) split into smaller player turns, each of which is carefully subdivided into elements. Each turn permits elements of resource management, movement, and then in specific turn elements, combat resolution. This is followed by further movement (if required or permitted) and finally an end-of-player and game turn phase handling a variety of book keeping elements. This methodology works well in many titles of a similar general nature, ranging from Risk to Civilisation, and is well understood by players of all ages.

Whilst it would be possible to amend this towards a real-time flow, the software flowchart, interrupts inclusive, has previously been determined, and it should be quicker to leave well enough alone during the first iteration of the product.

Over time, it would almost certainly be worthwhile moving the concept from turn-based to time-based flow, and as such the basic system mathematics would also need upgrading to provide an attrition rather than an “all or nothing” model of loss allocation. This is not a major task, and indeed significant work has previously been done to develop this concept.


It is envisaged that the e-media product should be based on local systems with a limited amount of data interchange between each phase within the game turns, via a central server array. This simplifies software design, and limits expensive bandwidth and server costs.

The downside of this (given the propensity for players to often wish to use portable systems like tablets, phones and laptops) is that storage on these computing products is often paltry in comparison with the graphical requirements and data needs of a product like TSWW. It should be noted that a typical map area at the scale is several hundreds of megabytes in heavily compressed PDF, and if ripped completely to gain access to the full quality of data (in game mapping is designed for electronic use) can be in the gigabyte range. This is not a major issue for desktop users, but is for tablet and phone users.

The benefit of the server-based concept, however, is centralisation of save files, meaning the end user can access their saved games via a product installed on any of their devices – play on PC, continue on the train on a tablet. The potentially small size of data sets within the saves (which would simply be unit status and location in basic terms) would again mitigate against excessive server equipment costs. Pushing the main data store of large, high-resolution graphics items and the primary “system” files onto the end user also limits costs within the model considered here, and again should not be discounted.

The Development Plan

This plan sketches stages for development of the TSWW digital prototype from its current form to a fully fledged online game, how that process could be managed and potential timings. At present, it is a basic high-level outline, and development costs may be offset by share allocation or profit-sharing.

Managing requirements

A simple Trello sprint management board has been set up to manage the tasks necessary to fulfil each stage of development. This allows each task to be allocated to a stage and progressed, with full visibility available to the directors and shareholders.

Staff and Organisation

A new company has been created, along with a new website dedicated to the TSWW digital presence. Through this site, initial versions of the system will be made available to existing customers and testers, and later it shall be made available through paid download or DVD purchases.


A new website,, to parallel the board game website ( has been created. At later stages of implementation and depending on take-up, this may host online user data and be upgraded to dedicated server hosting. This could be Windows or Linux based, depending on technological requirements and whether Steam integration goes ahead.

Stage 1 – Update existing code

Currently the prototype game depends on a defunct .dll file, berkelium, and was written in C# utilising Visual Studio 2008. The purpose of this stage is to migrate the existing C# prototype game code to a modern scalable platform and remove dependencies to allow the game to be compiled and run on any platform or operating system.

  • Assess existing codebase
  • Decide target migration platform ( / Rust)
  • Rationalise and migrate data schema (csv files > database tables)
  • Identify dependencies and their replacements, if necessary (Berkelium)
  • Re-code the solution, paying particular attention to the modularisation of specific regions so that in future stages players can purchase and add in further regions (North Africa, Singapore, etc)

Stage 2 – UI Enhancements

The purpose of this stage is to enhance the look and feel of the game, from the initial method of launching the game to the counter and action icons.

  • Icon set
    • Identify all existing icons and graphics
    • Design/replace action icons
    • Design and provide alternative icon set
    • Allow switching of icons from classic to modern style (and saving such preferences)
  • Redesign and implement console (game screen)
    • Design and implement hover pop-up when hovering over hex detailing units and available actions (move, restore, etc)
    • Highlight actionable unit hexes
    • Counter overlay on hex for number of units therein
    • Visual representation of stacked hexes
    • Smooth “wiggly worm” movement arrow

Stage 3 – Game Enhancements – Transitions and Automation

The purpose of this stage is to enhance game play with automation and to make actions and outcomes more obvious to a new user. This could be through means of colour-coded glowing hex outlines at a simple level and bringing in more complex movements at a later stage.

  • Design transition animations
    • Movement
    • Battle
    • Rebuild/restore
    • Destruction
  • Implement transition animations
    • Automate or semi-automate axis movements, deployment
  • Large-scale movements by AI enemy should zoom out map, returning to previous zoom after completion
  • Semi-automation should include triggered pop-up with continue button explaining the purpose of the event and to proceed

Stage 4 – Release Downloadable Game to Test Groups

This stage encompasses releasing the downloadable, installable game application through the tkc-digital website to select users or groups of users.

  • Identify test groups
  • Communicate and deploy
  • Enable means of gathering feedback (survey)
  • Concatenate feedback and report on actionable enhancements

Stage 5 – Game Enhancements – Co-op, Time-Based Play and Additional Modules

This stage encompasses implementing any enhancements identified from the previous stage and monetisation of the product. At this point, we should have a purchasable installable game application available on either hard or soft media, allowing a single campaign region to be played.

The business will now be in a position to provide and sell add-ons in the form of additional regions, selectable for play from the user’s opening splash screen. Each of these regions should be saveable separately from the other.

The mechanism for online game play (either cooperative or competitive), game saves and purchasing additional modules will be confirmed at this stage. The implementation of this may involve dedicated physical resources or integration with the Steam API and servers to allow game or module purchase and installation, online chat, co-op play, etc.

Time-based play instead of turn-based could be introduced at this point.

Stage 6 – Implement on Other Platforms

Assuming the success of the stages outlined above, we will commence the propagation of the product to platforms such as tablet or mobile devices, even if those are restricted to smaller-scale, imaginary or larger hex scale maps.

It may be unlikely that consoles would be appropriate, unless from the point of view of creating a FPS based on the larger geographical game logic.

Continue to Funding and Investment