Untitled Space Game – Episode 3: Finding a Path Forward

There are 2 major systems in the space game I have planned: 1)a free-roaming trade simulator game not unlike Sid Meier’s Pirates or Mount and Blade, and 2) a tactical space combat game not unlike FTL. Lacking any particular reason to start with one or the other, I chose to start with the tactical ship view because hey, why not? Except… one thing has already reared its ugly head, and is making me reconsider: pathfinding.

Turns out having 2D characters navigate across a 2D grid in “smart” ways is… well, a difficult problem. Not an unsolved one, to be sure, but one that is quite a bit more difficult than I originally considered. I guess chalk this up to growing pains, and a relative lack of experience tackling programming problems. It’s one of the tricky bits with making a game solo, is having to be the one to solve all the problems, even the ones I didn’t expect to need solving. There are no shortage of A* pathfinding whitepapers available online, and even a few general-purpose algorithms and libraries available for free. There are also a handful of extensions and plugins available in the Unity asset store, which might just be what I turn to in the end, as developing an efficient, scalable, interactable 2D pathfinding system is just not that exciting to me. I recognize its necessity, and can see the tuning and calibration being of interest, but not the low-level function of the thing.

So I’ve spent most of the last day pouring over different options in my head, thinking how fundamentally I’ll need to consider the ship architecture I was considering, wondering if I should just make my own solution or if I should rearrange things to better support a pre-built solution, until I had done a whole lot of pondering and worrying and self-doubt, and nothing very tangible (except applying to some more jobs that I will probably never hear back from). In my frustration and impotence, I even did some chores around the house like hanging curtains over the stairs, such was my urge to not have today go to waste.

And then I sat down, and decided, hey, I should calm down, document this particular hurdle, and maybe take a step back. I’ve banged my head against that particular problem for a little bit now, and am not moving forward, but fortunately there is still plenty of other game to move forward on, namely the free-roaming trade rpg part I mentioned, and shifting focus might give my brain the breathing room it needs to tackle these pathfinding challenges.

The job search is an ever-present thorn in my side reminding me that, hey buddy, you aren’t making any money. There’s a lot tied up with that, and sometimes I wonder if I’m just using “searching for jobs” as an excuse to not solve the hard problems involved in this space game. On the other hand, ignoring the job search in favor of working on Unity projects also seems unwise. On the other other hand (or like, the foot?) getting more experience with the tools and workflow of Unity can directly benefit my job skills and increase the likelihood of landing another job somewhere. On the other other other hand… sometimes there just becomes too much to think about, and without someone else imposing a deadline from the outside, it can be easy to spin in circles and make no progress on anything at all.

I wouldn’t say I’ve ever fully come to terms with my motivation when it comes to personal projects, and this bout of unemployment is really putting that internal struggle to the test daily. The positive side is it gives me lots of practice in honing techniques to stay focused… or lots of time to vent on a blog that no one reads instead of working.

Untitled Space Game – Episode 2: More like C Dull, amiright??

Weekly update on space game project – I’ve developed the core concept a bit more in xmind format, and decided I was ready to roll on to step 3 (because who needs ordinal lists?) and begin to prototype some of the basic systems involved. I figured I would start with the ship interface, and step number one was to lay out the basic hierarchy and variables for what that even entails.

For starters, I’ve decided that the ship will essentially be laid out into a square grid, the dimensions of which are a “character” wide. The very core components I need are:

  • A ship class
    • A grid class that contains info about each grid tile
  • A character class
    • Knows how to move around between grid tiles

After much wrangling of Unity objects and planning of eventual organizational flows, I got it in some semblance of a working prototype, after many hours of struggling with even the most basic C# syntax and unity APIs. It’s definitely been slow-going, but I feel like I’m dusting off the old C# cobwebs some and starting to get back into a groove. There’s definitely a “R&D/Refresh my Programming” phase of this I’m going to need to factor in though. It’s also a good reminder that while I list scripting and programming on my resume, and do in fact have a decent amount of background in it, I am in a lot of ways quite rusty, and I should really take this as a learning opportunity if I hope to apply those skills to my next job.

Part of what is making this tough, I think, is that I am still recovering from a flu (or some similar plague) that knocked me out for several days (including hastening my departure from PAX south – I only was there 5 hours before I had to call it quite and drive back home). Today I’ve felt mostly better aside from congestion and a cough, but I won’t claim my head is 100% in the game. That seems to be the pattern with sickness – you approach total wellness asymptotically, and there’s never a single day where you wake up and suddenly everything is back to 100%. So in the meantime you just soldier on at reduced capacity and energy. I guess in a way taking those steps is probably what gets you the rest of the way there.

So in that vein, while I am not making a ton of tangible progress, I do feel like I’m picking the pace back up and learning along the way. The next micro-step will be to refine the movement so that characters move from grid tile to grid tile, and then maybe to add a second character and make them selectable.

Untitled Space Game – Episode 1: The Drawing Board

This is the first in a hopefully many-part set of blog posts in which I will attempt to document my thought and work process in my efforts to make a game in Unity. So far, the broad strokes of the project are:

  • Strategy/rpg set in space, heavy on exploration, crew/ship building and tactical combat
    • Like Wing Commander Privateer, sorta, but more strategy-oriented
  • The ship-to-ship engagements should resemble FTL, or Dungeon of the Endless
  • Semi-realtime – player can pause/fast forward time in certain contexts
  • 2D isometric/top down art
  • Done in Unity engine
  • Moddable – because as a solo dev, content is going to be hard to do, so crowdsource that shit

I’ve had these broad strokes swimming around in my head (and in various forms of written/electronic media) for a while now, but have been looking for the best way to start. Already just sitting down and really pondering the workload and plan, there are noticeable differences in thinking this out for myself vs for a team, which is a context in which I have much more experience working. For example, part of me wants to heavily design the thing out on paper, but another side of me realizes that any design work I do is solely for the benefit of helping myself shape the eventual game, rather than communicating a vision to a team or solving for manpower and production constraints. Of course, I could similarly call into question the point of this blog, but I’ll leave that bottomless rabbit-hold of self-reflection for another time, and try and focus on creating.

So how to actually begin? It’s weird, after all this time, to have the only real constraint be my own time/ability. The drawing board is big and blank and terrifying in front of me, and as much as I want to simply paste a snapshot of the finished thing in place and just trace over it, I know I have to begin somewhere. First steps and all that jazz. So the way I see it, I can divide up my effort as if I had a 3 man team consisting of a writer, an artist, and an engineer, and focus on 3 main big-picture things, in basically this order:

  1. Designing the world, lore, and gameplay rules
  2. Defining the general art style
  3. Pick some of the core systems to start prototyping in isolated projects, to figure out the tech involved

Even as I wrote those out I edited and revised them like 10 times, and now I figure that steps 1 and 2 are roughly parallel, but step 3 really relies on the other 2. I may be able to enlist the aid of some artist friends of mine to help get #2 rolling. In particular Erik and Jon might have some good ideas, although I don’t know how much they’ll be willing to do out of charity. As for step 1… I’ve made some decent progress in outlining the gameplay basics in Xmind format. The next step, given that it’s a 2d semi-turn-based strategy, might be to model out some of the mechanics in physical cards and paper. I bet I could enlist the aid of my tabletop RPG buddies in playtesting and tuning the core mechanics, even. I have to admit to a certain disdain for actually producing physical things, as I try and live my life as much digitally as possible, but I have to acknowledge a certain ease of creation and editing when the thing is just comprised of index cards, and it bypasses the tendency to get buried deep in the idiosyncrasies of a particular algorithm or section of code, and lost sight of the whole in the process.

So there we go. Step 1 – make a card game. Actually, I guess step 1 is get some cards. That’s my first goal for tomorrow. I should have some free time to do that I think.