Development

One of the issues with game development that’s become more apparent over the years was dealing with splitting time between new game development and bug fixes/maintenance. When we first released games, they were much simpler, and as a result had less bugs to deal with. You could spend the majority of your time working on new features. Nowadays, our games have become so large that as the solo developer, even I can’t keep everything in my head straight on how certain systems were implemented....

Use: UGameplayStatics::CreatePlayer(World, Index,bSpawnActor) (Docs). When creating a custom game mode it wasn’t clear in the documentation how ones goes about: Spawning a playercontroller Spawning a pawn assigning both to each other and possessing the pawn with the controller So I basically did it all manually inside InitGame(). This cropped up some unwieldy UI focusing bugs. Once I replaced it with a call to CreatePlayer() things started working as intended. Hope this helps anyone who’s starting out in UE4 with C++....

With each game release I’ve noticed I’ve committed less and less time to writing the ‘fun bits’ and more time spent trying to mitigate complexity and find ways to make as many things as testable as possible. I guess that’s the nature of the beast once you go beyond your average ‘asteroids’ clone. With the recent announcement of SFT getting asynchronous play in the coming months, I’ve been scoping out my dev schedule for what needs to happen to make it reality, and the only issue that I keep circling back to is “how the hell do I make all of this testable/bug free”....

Early on in the development of SFT I had concerns about how I was going to do text rendering on the cards in such a way that things stay readable regardless of resolution, while keeping fonts looking nice. I ran into aliasing issues as well as pixelation, since all the fonts being rendered were simply bitmap textures on top of cards that are flipping, rotating, and scaling in 3D space. I had read about SDF (signed distance fields) font assets for text rendering and was wanting to get something implemented for SFT’s cards....

Taking the “conflict” out of shared roles: https://vine.co/v/inaDFBXgFUB We opted to do a ‘ranked preference’ for role selection in SFT. Instead of players joining/leaving and selecting anywhere from 1-3 players to control and then having more UI flow when conflicts arise, or a character is left unselected, or a few other scenarios, we simply take everyone’s preference list and the game deals out character roles based on them. If there’s a “tie” (for instance two or more have captain as their first choice) it’ll be random who gets it....

Finally got another card ability animation implemented into SFT: https://vine.co/v/i12I565Q9zg The method and architecture I’m using for driving game logic I think has served me well for the past few years. I shipped Outwitters on the basics, and expanded the gameplay “engine” for SFT, which allowed for real-time multiplayer (albeit in sometimes hokey ways). The drawback is I haven’t found a good way to untangle it from the animation layer. It’s all 100% unit-testable, but when it comes to driving user input visuals for card play, it’s still a mess of:...

So much work left to do, but we're hitting a point where the game is fully-playable with basic graphics online and off. Hope to write more about some of the technical challenges soon! A delivery made! But barely! Sign up on http://t.co/Y9RSqo47n9 for release updates on SFT! #indiegames pic.twitter.com/pvanWLGG26 — One Man Left Studios (@OneManLeft) September 10, 2015

This week I’ve got a lot done in the way of Steam integration, save files, automated builds, some better randomization for galaxy generation, as well as some much needed bug fixes to make online play smoother. Got a lot done but not much on the visual side of things. But hey: Nice to be one step closer to a shipping product Got basic Steamworks apis integrated as well. Pretty painless with the Steamworks....

Oh, It’ll Be Out By…. Hmm, even now as I look back on what’s been done on Outwitters, I’ve learned a *ton* of new things in regards to game development. I’m not too excited about having only 1 game to release this year (if we even make *that*). Hell, we even planned on having 2 games a year. The take-away from that is game development is not an assembly line process....

This following post is probably going to be useful to an extremely niche audience: anyone developing a multi-user iOS app that has a GAE backend. I’m currently working on Outwitters and debugging turn-based games on the local dev server (dev_appserver.py) is really quick and painless. The problem arises from the nature the game. It’s a multiplayer game, and as such, requires multiple users to function. You can only go so far with creating ‘mock user’ accounts, and fake data populating your local server....