Skip to content

8-bits of BA wisdom from coding my own games

Something many of you won’t know about me is that outside work I’ve started developing my own computer games. I am not naturally a technically-minded person! As well as learning to do the fun stuff – drawing aliens, composing music, or hunting open-source sound effects for explosions – I’ve had to develop skills in design, architecture, coding, testing. I’m sure my business analysis skills have helped me in this journey, but in this article, I’ll examine how learning to build software myself has helped me grow as a BA professional.

1 – Grand designs can be fragile

I’m a sucker for a comprehensive model. I love feeling confident that I can see how everything fits together. In my early forays into game design, I’d spend an inordinate amount of time designing grand systems. I’d then spend even longer trying to build everything, frequently switching between components to get it all working together. Eventually I’d hit a stumbling block beyond my technical abilities, or would discover too late that the game just wasn’t going to be fun (and then is it even really a game?). I was failing to “fail fast”, learn, and adapt.

On reflection, I’ve realised I can easily slip into this same trap with my analysis work. I want to understand and document everything about a process, or I’ll try try and identify every entity (and associated attributes) up-front. This “comprehensive” picture can actually be quite brittle; small changes can easily result in major re-work. Breaking things down into smaller chunks helps you prioritise your focus and respond quickly to new information or ideas.

2 – Don’t rely on assumptions when it comes to user experience

I’ve learned some hard lessons about how users interact with technology. In every game I’ve made so far, I’ve made assumptions about what will make sense to a user, and these assumptions have led me to make choices about how information is presented, how interfaces work, and how users receive feedback from their actions.

When I then watch someone test one of my games, I’ll be totally surprised at the ways they expect things to work. When my long-suffering husband first played my pigs-as-pirates-themed Bay of Pigs, he was totally baffled by how various characters communicated that they wanted you to bring them particular items. I’d adopted a visual language I’d seen in countless other games – but this was totally new to him!

Users come with their own prior experiences, expectations, tastes, and habits. They may not even be consciously aware of all of these. If I’ve incorrectly assumed users will share my own cultural reference points, they may struggle to solve “simple” puzzles. If they’ve not played similar games, they may never expect a button would trigger a particular action.

Nothing beats actually watching users interact with a system – and the earlier in development you can do this, the better! While it’s not always possible to give users working software to play with, I now regularly create wireframe mock-ups to better establish how users will expect things to work for them. I get feedback very quickly, and can bake this into requirements documentation to aid developers in creating technology that users will find more intuitive.

A screenshot from one of my games: Bay of Pigs.
Bay of Pigs – lessons in understanding the user experience!

3 – Seek solutions that play to your strengths

I’m still a very much a novice when it comes to building games. The thought of attempting a 3D game terrifies me. Theoretical mathematics is not my strongest suit. This means that my ambitious ideas often chafe against the limits of my own capabilities.

While I’m always learning new skills (currently A* pathfinding algorithms in hexagonal grids!) I know that I’m far more likely to make a game that’s fun and rewarding if I play to my own design and development strengths. That means relying less on complex maths and data crunching, and more on visual design, thematic flavour, and humour.

In the day job, I now spend more time up-front trying to understand the capabilities of the team and the wider organisation. This can then help shape the types of solution options considered. If there’s little budget available but some strong development skills in the team, in-house solutions may be the most sensible option. If users are pretty sophisticated, why not consider giving them more self-service options instead of directing everything to support teams? Solutions that make best use of an organisation’s strengths can maximise the value achieved from a change initiative.

4 – Applying constraints can unlock innovation and creativity

In Goblin Kingdom, I set myself a challenge: make a game using only 4 colours. In part this was to try and capture something of a retro vibe, but also to see how the constraint affected design decisions.

Some of the challenges became obvious very quickly. Where I couldn’t use colour to convey information, I would need to consider other methods. Sometimes I was able to rely on shape and form; stereotyping the shape of a mushroom or a cake meant users could still understand what the item was. With other things, I had to consider less straightforward cues. How could I convey that something was hot, was dangerous, was important? I resorted to a variety of means: patterns, similarity and consistency; placement; movement; audible warnings; visual messages; size. The game developed its own internal language that made the whole experience far richer and more coherent for users.

In my business analysis work, applying constraints to a situation can actually spur more innovative thinking. By excluding some ideas (and you can always come back to those!) you need to think laterally, consider other perspectives, and borrow approaches and solutions from elsewhere. This can really unlock a team’s creativity.

A screenshot from one of my games: Goblin Kingdom.
Goblin Kingdom – the limited colour palette unlocked more creative options.

5 – Get organised

I’m not naturally inclined to be organised. In the past, I’ve told myself that it’s because I’m an “ideas person” and my creativity would be stifled with too much standardisation and control.

In game development, things can get messy and confusing very quickly without some coherence and structure. Without an organised approach to creating games, my creative talents rapidly get lost, then frustrated, and nothing of value ever sees the light of day.

I have had to adopt a more rigorous approach than my natural inclinations would like. I use standardised naming conventions and tree structures to help me keep track of objects, scripts and assets. I keep lists of defects and future features so that I don’t lose track of them or prioritise the wrong things. I comment my code so that I remember what it’s meant to be doing. This last point also helps me solve problems, a bit like talking to a rubber duck.

My BA work is now less “free-form” than it was in the past. I keep lists of what I’m doing. I plan my work methodically – and communicate that plan! My documentation is somewhat more consistent, with each new requirements catalogue looking at least vaguely similar to the last. Working as a consultant BA, it’s more important than ever that those I work with can feel confident in my approach, and being more organised helps me keep on top of the issues and respond quickly to changing priorities.

6 – Avoid ‘analysis paralysis’

A common solution prescribed for Writers’ Block is to just write something, even if it’s not related to your novel.

I tend to have multiple games in various stages of development at any one time. This is because I often find myself hitting a mental sticking point where I can’t see a way of solving a problem. A Dark and Stormy Night has been progressing in fits and starts for a couple of years. It’s currently “on the back burner” because I got stuck on how to make character interaction more intuitive. Whenever I get in this situation with one game, I switch to another (or something totally new) for a while. Frequently, I find that solving problems in one game leads to a “eureka!” moment on another.

When analysing a problem, it’s easy to find yourself equally stuck. Moving to a different problem, or even just considering techniques you might use in different situations, can help unblock your thinking. If I’m stuck on a process logic point, I’ll think about the information structures. If I get stuck there, I’ll consider the teams and roles involved. This means I keep making progress, and often leads to new insights that help me crack the gnarly issues.

A screenshot from one of my games: A Dark and Stormy Night.
A Dark and Stormy Night – one of the games slowly progressing as I face each blocker.

7 – Seek out the wisdom of others

Although every business problem is in theory unique, in reality others will have faced – and solved – very similar situations.

Throughout my journey developing games, I’ve made the most of the experience of other developers. I would frequently be scratching my head puzzling over a coding challenge, only to find someone had created a helpful tutorial on YouTube which would be close enough to adapt to my own needs. When a ready-made solution wasn’t available, I sought out the advice of fellow programmers. There is a great community out there, full of wisdom and keen to share.

As a business analyst, I can’t be an expert in every technique, let alone every kind of business domain. But the BA community is always available for seeking advice, a second opinion, or at the very least a sympathetic ear! I’ve become a regular at IIBA UK’s Brown Bag sessions on a Friday lunchtime, and frequently seek out ideas and insights from other attendees.

8 – Keep honing your craft

I’ve learned quite a lot about developing games so far. As well as countless coding challenges, I’ve been developing my artistic skills, musical talents, planning and estimating abilities, and my storytelling capabilities.

I’ve found that developing new skills has been great for my self-esteem and mental health, and also creates a virtuous circle; every new capability unlocks new opportunities, and these come with new challenges that spur further growth.

I recently got to use the Value Proposition Canvas technique in earnest for the first time. I took some time to learn about the tool in detail and consider how I would apply it in the workshop. This really paid dividends, and we came away with loads of useful insights. Learning to use this tool has even affected my work more widely; I now frequently use terms like “customer pains” when discussing service design. I’ll try and get something up in the Resources section soon!

No matter how experienced you are as a BA, there is always something to learn; seeking out new challenges helps ensure you keep a growth mindset and keeps your talents sharp.

A screenshot from Escape From Planet X.
Escape From Planet X – mastering new skills in coding physics!

Conclusion

I’ve learned a huge amount building my own games, with unexpected benefits to my work in business analysis. In addition to the tangible skills I’ve acquired, my problem-solving capabilities are being enhanced all the time. The ongoing journey helps to keep my mindset open to new ways of doing things, and I’m always looking for ways to put new knowledge into practice.

Most importantly, I’m having a lot of fun.