Saturday, March 10, 2018

Tales of an Amateur Dev

I've dabbled in coding before, but never done anything serious - the biggest project I've ever worked on was a version of Risk I coded in Turing for a highschool class back in 1999. But it's always been something that's interested me, and it's possible that my career might take me in that direction somewhere down the line, so it's a skill set I've wanted to build for a while.

A project just came across my horizon that I think I'm going to work on - basically, it's an application for a tabletop game, but one that can get very complex by the time it's done due to the number of different advanced rule sets/unit types/etc. that are available in this game. This project is really ambitious by the standards of my current skill level, and it may well be beyond what I can do well. However, even if I fall out halfway through I'll probably learn a ton, and if it succeeds there may even be a second income stream in it for me.

This blog post will be rather different than anything else I've posted here, but if you want to see my ramblings and false starts, come join me. This is intended to be something of a notebook of my experiences, as well as perhaps being a useful guide to anyone else who wants to follow in my footsteps.

Project Overview

The game I'm building for is BattleTech - it's a tabletop wargame, based around giant stompy death robots, but it's got add-ons for everything from infantrymen to two million ton space battleships. The goal for the intial version is to be able to make units of the most common types, with a convenient and modern UI. Once that's complete, more unit types will be added, as well as more utilities that players may value - the ability to turn individual units into larger forces, the ability to organize the logistics for those larger forces, the ability to build their own imaginary factions and select common designs and the like for them, and so on. Once that's done, I'd ideally like to integrate a rules database, fictional references lookup, and so on. All of this should be easy to use for an end user - just a simple download-and-install, no need to set up a Java environment or anything.

In a perfect world, this program ought to run on all major OSes(both desktop and mobile), be easy to integrate new expansions into, take input and provide output in all the most common formats used by players, and be superior in terms of both usability and breadth of options to all its competitors. Obviously, this is a hell of a request list, and I don't anticipate it'll happen right away. For one, having the same program work on desktop and mobile is a nightmare - that was what Windows 8 was built for, and Windows 8 was a failure. If Microsoft can't do it, neither can I.

So, the architecture seems like it ought to be divided into three parts.

  • The database, which contains all the various units, weapons, rule write-ups, and so on. 
  • The back end, which does the actual calculations, output to other programs, and the like. 
  • The front end, which gives the user an interface to make everything actually happen. 
As I understand it, the database and back end should be universal, as long as I pick the right tools. The front end will be extremely different on desktop and mobile, but as long as everything is properly modular, that's the only thing that should need to change. I'll be starting with desktop, as it's both more forgiving and easier to test. 


I've started this project with the intention of using C# as the primary coding language, building it within Visual Studio's free Community edition. There's a good selection of libraries and support tools, I have some experience with both language and environment, and it seems that the expansion to other OSes is fairly easy(from what I've read, Xamarin for Visual Studio will let you turn C# code into iOS/Android apps, which looks like an easier transition to mobile than any other I've come across). 

For the database, my intention is to use SQLite. I don't have much experiences with databases of any sort, but it seems to be the de facto standard for building a relational database into an application without need for any central database server. And again, it's very well supported, and free to use. This is a Visual Studio plugin that seems to implement it. (Edit: Nope, that's a bunch of tools, but not the actual implementation. I'll update this when I find what I want.)

Getting the same version to work on Windows, Mac, and Linux systems ought to be possible, and a helpful soul pointed me in the direction of wxWidgets, which seemingly has a C# version. I don't know exactly what I'll be doing here, but that seems like a promising lead. 

Any of these may turn out to be mistakes, but I'll start there and see what happens. 


Designing something that's intended to be this thoroughly expandable is a challenge I've never dealt with. Most of the time I've just done straight A to B programming, brute-forcing things freely and hard-coding all over the place. Doing long-term maintenance on a few workplace projects has started to move me away from those habits, but I'll need to jump far, far away from them for this to work right. 

The plan right now is to use plain-text definition files of some sort, one for each different type of unit. Those files will create a list of things the unit type must have and a list of what they may have, with caps on each(e.g., you can only have one engine, but you can have dozens of weapons). These will be as soft-coded as I can manage, because the number of optional rules and add-ins means that anything I hard-code will need to be torn apart and replaced down the line. 

The structure of the database will also be a big concern. A lot of things can be used on many different types of units, so making sure that the database that stores them is properly set up for flexibility down the line will be quite important. I think each "class" of weapon(infantry, mech, artillery, naval, etc.) will have its own table, and each sub-class(e.g., all AC/2-class weapons, of which there are several types with overlapping ammunition options) will be given a label within that class. Special rules that apply to some weapons, or some ammo types, will have their own table, and a many-many relationship will be set up between them to keep it all straight and prevent inconsistencies from sneaking in. Ideally, each rule should be defined exactly once, and everything that uses it will just reference the master entry. 

Getting Started

To start, I downloaded Visual Studio, installing the ".NET Desktop Development" package. It was about a 3.5 GB install. The list I originally wanted (with Xamarin etc.) was close to 40 GB, so I figured I'd hold off on those to avoid blowing up my internet's download cap. 

Once I got it downloaded, I created a project as a "Windows Forms App (.NET Framework)", as that seems to be a decent UI option from a quick Google image search. I needed to create a new folder outside the Visual Studio folder to store the actual project in, as my original attempt to make a sub-folder was blocked. I made sure to tick off the option to add it to version control, as a VCS is a must for any kind of serious coding - it seems to use Git, which I've dabbled with before, and which is as good as any. Once that was done and I was properly into Visual Studio, I installed the SQLite plugin through the extensions manager and rebooted the program. 

The crazy part is that this has been a big focus of mine for the last day and a half, but after all this work and planning, I still haven't written a single line of code yet. But I know where I'm going, and I have some reasonable-sounding ideas for how to get there. Let's see how this goes. 


  1. Fair warning that C# is very much a Windows-first sort of programming language. I think the only option is to do cross-platform development in C# is to do it via Mono (, and I don't think that has any support for the Microsofty GUI things like WinForms.

    Generally, doing proper cross-platform development is really tricky. There aren't that many great options, especially when GUI is concerned. This is why you see many apps going the Electron route these days.

    C or C++ also works pretty well across platforms but I wouldn't recommend it to an inexperienced programmer.

    That said, your intention to keep a hard separation between backend and frontend is already a good move. Best idea is to keep them as separate libraries, if you can (or rather make the backendy stuff a library (or even more than one) that you then link with the main application that contains all the GUI logic).

    1. Thanks for the info. That seems to match up fairly well with what I've heard elsewhere. And TBH, Mac and Linux are the least important OSes for this sort of purpose(and Linux, in particular, is generally used by people who can handle emulators at need), so if it's hard to make it work for them, that's less concerning for me. Xamarin seems to be designed to turn C# into iOS/Android apps, and those three are more than enough for the time being. TBH, it'll be Windows-only until it's working well in that context, I'm mostly looking to preserve upgradability, and even that's a secondary goal.

      I know I'll almost certainly make some missteps here, and I've already made the one error with SQL tools. But as long as the basic code does what I want, I should be able to copy-paste it into another project style and keep working. Probably a really ghetto approach, but I know that the best way to learn is to dive in - if I wait until I know everything I need, I'll never actually do it. So, LEEROY JENKINS!!!