With the main parts of my game "Character Limit" in place, efforts turn to planning the last bits of development and testing, with administration becoming a more important element as release approaches.

I think it's fair to say that the vast bulk of the core of the game's development is behind me. Getting systems in place for everything from picking letters to scoring, the main interface, and even multilingual support, are the most important elements of the game to make.

That's not to say that Character Limit is close to completion. Far from it.

The reality is that there's many smaller, less-obvious tasks that need to be completed before a game can be released. I divide this all down into three general areas: development polish, administration, and marketing.

The development polish covers anything involved in making the game itself. There are many fiddly bits of the game left to put in that feed off what's already there, which need to be implemented now.

Dark glitchy game menu titled CHARACTER LIMIT with large white text on the left and stacked grey buttons labeled in Welsh on the right, including daily game, endless practice, challenges, settings, and quit

The main menu of the game, in Welsh.

For example, I still need to finalize the additional game modes, add a gameplay stat system, bulk out the settings panel so it works on desktop Mac and Windows as well as iPhone and iPad, and implement a tutorial system. While the game does work, it also has areas that need polish, such as improving sound effects or making the knobs on sliders less badly pixelated.

Not to mention fixing the ever-growing list of bugs that have slipped in as development has progressed. At least, the ones I've caught for myself.

This is all just stuff that I have determined needs to be done. Once I start actually testing the game using actual potential players, I'll receive feedback on things that also need to be fixed.

That means I have to get the game into a state that I would be happy sending out to testers.

Planning problems

Any previous readers of this series will know that I am a fan of whiteboards. I count a total of six around me of various sizes and uses right now, and I yearn for more.

There are benefits to using whiteboards, including how they are a quickly edited and very flexible medium for temporarily containing ideas. Having a board with a list that you can tick and erase within your eye line does a fair amount to drive productivity.

However, it's not really a great way when you have massive lists of tasks to complete. Even if you have more whiteboards than available wall space.

You can add a plethora of lists, but you are limited to the amount of space available to you. If your handwriting resembles a drunk spider clambering out of an inkwell and crawling across a page, those lists could become unreadable to even you in the future.

There's also the severe lack of portability. It's one thing to have the list on a wall at your desk, but another when you're sitting in Starbucks on an iPad, trying to remember what tasks you have to do.

The whiteboard list can't easily be shared with others, either. Admittedly, I have taken photos of whiteboards to send to people, but I don't expect anyone to want to open Photoshop to make changes to the image-based list.

There has got to be a better way. And funnily enough, it's already a solved problem.

Obvious ways include using Apple Notes or Reminders. If you have to work with others, options like Trello exist, in both free-use and paid subscription forms.

Project management dashboard showing colorful category cards at top and a Kanban-style board below, listing game design tasks grouped by priority levels such as High, Medium, and Low.

A typical screen in Codecks

In my case, I've gone for Codecks. It's a project management tool that is aimed at game development in a number of ways.

For a start, it's based on cards, similar in ways to Magic: The Gathering or Yu-Gi-Oh, which represent tasks in different decks, or topic areas. Users can make changes to the cards, add them to their hand to work on, and then turn them in.

It's a project management system, certainly, but a very well-disguised one that doesn't feel "corporate" at all. It's also got a free tier, which is good enough for me.

If I have to bring someone else onto the project, I now have a mechanism to show them where the project stands and to bring them up to speed.

It may not happen in this particular project, but at least it's there.

Account flips

One thing that needed to be fixed was developer account registrations. Specifically, they needed to be registered under a limited company name rather than as an individual.

I don't expect massive sales or anything, but putting them under a UK limited company reduces my exposure for things going badly wrong. For example, an errant lawsuit over the created intellectual property could be very expensive to lose, and a limited company registration helps insulate my finances from that.

What can I say? I like home ownership.

This change did mean having to make some administrative changes. After getting a bank account set up, which took four weeks and resulted in way too much anger, the next things were to inform Apple and Steam.

In both cases, the developer accounts were set up for individuals, but now they had to be changed to work for an organization or another legal entity.

When it comes to Apple, the process is oddly quite easy. Apple's documentation explains that you need to submit a request to them as a founder or co-founder, and to submit business documents, along with a DUNS number.

Apple Developer webpage form for looking up a DUNS Number, showing organization information fields including region dropdown, legal entity name, and instructions to use Roman characters only

Apple wanted a DUNS number. I still don't quite know what that is...

Thanks to some emailed PDFs from the UK's registration system and other details, it all got transferred over a series of emails with an Apple support team member. A few elements followed, such as the tax information, but that was relatively painless.

Even better, I didn't have to re-pay the yearly registration fee. It was simply a change in account details.

The same can't be said about Steam. You can't actually change a Steamworks account from an individual to a company, but you can transfer a game you produced between accounts.

That does mean going through the process of registering for a Steamworks account again, as the organization.

An unexpected foible did surface as the re-registration progressed. It turned out that Steam expects the app fee to be paid again when registering this second account.

Under Steam, the $100 fee is intended to pay for a game to be listed and eventually released on the platform, and is per-game in nature. It's game-specific, not account-specific.

I checked with its support team whether I had to pay the fee again, and it turns out that another payment would be required because Steam incurs various onboarding costs.

However, once set up, the app can be transferred from the individual account to the company account, while retaining its paid-for status. The result is the company account will end up with the paid-for game listing, as well as one app credit on standby for a second game.

This isn't ideal, but at least it saves some of the cost of getting the second game into the world.

Testing times ahead

With the admin bits done and the planning schema in place, the only thing left to do is the work itself. However, as a natural-born procrastinator, that's easier said than done.

So, to proceed forward, I need to set myself a deadline. Much like this job, which has deadlines issued by Mike and strong words if they are not appropriately met, I need to do something similar.

The alternative is to keep noodling on the game and never really getting to the endpoint. That simply cannot stand.

Game settings screen with sidebar menu, language and mode dropdowns, line graph labeled Time Survived, and detailed statistics table showing scores, times, word counts, accuracy, and assists

Gameplay stats are one of those noodling things that need to be finished.

I had vague intentions of a release in time for St David's Day to match the whole Welsh thing, but I know that cannot be met. Add in that I have to do some level of testing before release, and a date that soon is improbable at best.

So, instead, a mid-point deadline is to actually start testing. The Apple developer account has transferred, so I can actually get to grips with using TestFlight and have players hammering on the game when I'm ready.

I can't set it for the end of February, as that's simply too much of a lengthy runway for the work at hand. Similarly, a week could be too short, and doesn't give any wiggle room for bug fixing.

My intention is to get to Valentine's Day (February 14th) and to start testing by that point, if not within a few days of that date.

Here's hoping that I make it.