How I made BattleMapp.io and how to start your own project

One year ago I was sitting in the pub with my mate Dave chatting rubbish, when I brought up the weekly D&D game I was running in our local games cafe. 

Dave was a bored fronted engineer looking for a project and I was looking for a distraction from my 9-to-5 job. We started talking about augmented reality (AR) applications and how, because I was a terrible Dungeon Master it would be cool to be able to show my players the battle map in AR whilst drinking beers and chugging nachos at the gaming table.

Let’s make an AR app, I said.

It never happened. 

However, inspired by my monotonous 2-3 hour daily commute I downloaded Unity and began learning programming in C#. 

Fast forward though SEVERAL unfinished games, lockdown began. Friday nights were no longer spent at the pub and several friends had shown an interest in giving D&D a go, so Friday-night adventuring began. We played over Zoom, we used Roll20, Photoshop, Paint even and much blood was spilled and much fun was had. 

However, I always found these tools to be awkward to use. Why not design my own 3D battle map application?

I had already designed bits and pieces of strategy games – building tools, narrative design elements, random environment generation. I decided to pull all of those puzzle pieces together into a single application, and BattleMapp was born.

I am a terrible programmer.

Being new to the idea of writing code I wrote (and still am writing) some very bad code. But that’s OK, for now. I just needed to get it to work, and I can refine the methods later. Perhaps not the best plan – but if I was to give any advice I would use the old saying, OK today is better than perfect tomorrow.

Just get it to work.

The most useful skill I have learned is how to Google well. Yes, I just Googled everything. 

How to instantiate an object? Google.

How to iterate through an array? Google.

And I don’t just Google once. I Google the same question several times over several months. I’m not in the business of retaining information, I just want to get the next bit done.

Finally, there was the bare minimum of a functioning product I could call my own. It was scrappy, prone to errors and very basic, but it was done. 

In the second part of this blog series I will continue to talk about the things I learned when marketing the application, how Reddit is a beast, how building a website is easier than you would think, and how social media marketing is still a pain in the arse.

Things I learned when building BattleMapp:

C# is a beautiful language and the instant feedback you get when you get something to work in your game, is incredibly exciting and addicting. If you have always wanted to learn to write code but did not know where to start, just start. 

Giving up on a half-finished game is a success, not a failure. There will always be things you have learned from a project whether you finish it or not.

Take breaks. I have spent whole days on simple code errors because I was too close to the problem. A short break has then made me realise that I’ve left a semi-colon out somewhere, or that I’ve used the wrong variable name. Remember to step away from your code.

Name your variables clearly. No matter how long or stupid they look. This will help you avoid the previous issue.

Try not to get upset with the code. It’s never the code’s fault.

Do not code tired.

Do not code angry.

Stay hydrated.

Avoid monolithic classes (those classes that are 1000 lines of a million different functions with different purposes). Try to make your scripts modular, it will save SO MUCH TIME later on. 

Break down each “thing you want to create” into its most basic component parts. Write it as a list and start on point one : how do I achieve this most basic thing? Then build the tool/code from there, piece by piece. How do you eat a whale? Bit by bit.

Use premade assets at your own risk. The varying quality levels of asset store assets means that it is often easier (and better) to write your own code than to spend time deciphering someone else’s asset. Any store bought asset is never going to fix your specific feature or issue specifically, and will ALWAYS need editing/modifying, so if your are going to use store bought assets for tools (because some are amazing and will save you heaps of time) be prepared to dig into them to figure out how they work. They are very rarely a plug-in-and-play solution.

BUT STILL USE STORE BOUGHT ASSETS TO SAVE TIME. Models, animations, special effects are all useful to buy to save you production time, especially if you want to get your MVP out there. Also buy well-reviewed assets just to see how they work and to learn about best practices.

Backup your work. Some people use Github, some people zip up their project folder and upload it to their Google Drive. However you backup your work, just remember to do it on the regular. I like to do it every other day, as long as I’ve made progress on the project. This has saved my bacon more than once.

Put aside time to back over earlier scripts to refactor the code using the new things you’ve learned. Best to do this regularly than to get to the point of needing to refactor the entire project at once (because another developer has offered to help and you’re embarrassed about how awful your code is.)

That’s it. I’m tired. Time to take a break.

Written by Marc @ BattleMapp 

@BattleMapp on Twitter and Instagram