John Hargrove

Tatzen

It’s me, tatsumi_oreo, aka tatsumi, aka Tatzen, aka John Hargrove. It feels good to be posting something to the v-rpg domain after all these years. Half the reason I’m doing this is for that feeling alone.

What Have I Worked On?

Over the last couple of decades I have left a trail of abandoned game development projects. Probably 100 of them. I don’t think that is an exaggeration. I average 5-6/year, and have for most of my adult life. So, probably approaching 100 abandoned projects. Anyway. I have a new victim!

The Project

I am currently working on a small project based around space fleet management. I play a lot of idle and management games. I like making numbers go up. It’s a simple mechanic. Key components of the genre are:

One or more numbers that just get ever bigger.
Geometric growth of some numbers, such that continuous linear gain becomes ineffective after some hours of play, requiring the introduction of a new scalar.
Leaving the game idle is beneficial but doesn’t scale. E.g. you may increase X by some linear amount, but due to your inaction, you have missed out on additional growth.
Offline support. The game still grants you resources while you are not playing. (Usually by simulating lost time during game loading.) I don’t know if this game will support this. I’m working that out.

The current vision is that you will start with a small amount of credits, which you may use to purchase your first mining vessel. You may assign this vessel to mine a planet. Rarer resources will be located in the extreme reaches of the solar system. The mining vessel will have a fixed storage (related to its low tonnage and optimized-for-drilling design.) In the early game, your ship will fill up with a small amount of resources (perhaps several tons), and then fly this back to earth where it will be delivered to your orbital warehouse. At this point, the player may liquidate the resources into credits. The credits may then be used to expand the fleet.

Over time it may become apparent that the mining vessels are good at mining and bad at transporting things. This will necessitate the production of large shipping vessels, which are quite expensive (for balance reasons), but can do the business of moving goods around the star system while the miners are performing mining operations. This will require construction of an orbital warehouse around the mined planet.

I have a lot more to share but I don’t want to make this into a design document. So with that in mind I will lay out some quick points:

Orbital mechanics, physics, etc. The game does not simulate orbital mechanics. Planets orbit stars, but they do so based on basic trigonometry and known orbital periods. I.e. the planets have no simulated velocity, only a present location, a known orbit, and a current timestamp. This is easier for me to simulate. It may cause issues. Ships may orbit planets or stars, and they may change orbits or travel between objects in the system. These maneuvers assume the ships have significant impulse power, and thus do not rely heavily on traditional orbital transfer mechanics. In other words, there are no “launch windows”. If a ship wishes to orbit another body, it will reorient itself in an approach vector, accelerate into the vector (smoothly) and arrive. Currently this includes flying through other objects (for example, the sun, ha.) I may correct for that but I have no intention of correctly implementing orbital physics.
Scale. Planets, relative to each other, are realistically sized. Relative to their orbits, they are not. The sun has been scaled down. Ships appear huge, literally planet sized in some cases, but I need them to be a playable size, and so it shall remain. I’m tweaking these size relationships constantly as I feel the adjustment is needed.
My design here is loose. The game is as much a technical challenge for myself as anything, and as such I may spend time focusing on details that are not super important to the game design but are technical challenges of personal interest to me.
The game is built in Unity. It is my engine of choice, mainly because I like C#.
This game may never be completed. My hope is that posting here will help me avoid that, but I am aware of my personal limitations and my desire to spend some of my free time playing rather than making video games, and depending on my personal stress level which I may choose one or the other.

Screenshots, Demos, etc.

No demo yet, but here are some screenshots.

Fleet departs earth for a mining mission

A small fleet in orbit around Mercury

A view of the inner solar system

A View of the mid-solar system

What’s next?

We’ll see. Over the next week I am working on the core gameplay loop. By next week I would like to be able to show the full loop of resource, acquisition, ship construction and money-making. Perhaps even building of orbital improvements, but that might not happen. Hopefully my day job is not crazy this week.

Tatzen

Devlog #5

This weeks update is brief, due to a lack of visible progress on the game. At the end of last week I predicted this week would be “design heavy” and result in a lack of visible progress, but I feel that progress was even less than I predicted, for several reasons:

I have decided to try implementing Research Ships as an early game mechanic to give the player something else to care about while waiting for miners to produce resources. I don’t want to dramatically increase resource acquisition in the early game, nor dramatically reduce resource costs, as this might trivialize later game scale. As such, I began implementing a research ship. Which leads me to problem #2.
From the outset of this project I have just been dumping increasing amounts of logic into the AI Update() tick for mining ships. The problem is that a substantial amount of what mining ships do can be generalized for all space fairing vessels, be them ships or stations. At this point I had a choice: continue adding more complexity to this already monolithic piece of logic, or refactor. I chose the latter which leads me to problem #3.
There are a lot of AI design patterns for games, and it’s not really my area of expertise. I have implemented a few of them over the years but I wanted to do a better job this time. Part of why I make games is because I want to refine my command of the artform. So I spent a lot of time looing at the work of others, and made some prototype implementations of a few approaches:
1. Simple state machine. This works pretty well but I start having issues with state history, nested states, etc. The complexity becomes pretty ugly.
2. Hierarchical state machine. This allows for multiple states to exist within a single state, by giving some states their own internal state machines. It’s a lot of complexity but it allows for the flexibility I want. Maybe slightly overblown for this project, but again, I’m partly here to learn and I want to see how it goes. I am currently implementing this model, but it is not yet working.
3. Behavior Trees. This is pretty interesting but it seems most useful for AI that needs to exist in a more dynamic world where unforeseen conditions regularly arise. The game I’m building isn’t really like that, so I didn’t see a strong need to implement something like that.

To make the week more interesting, my primary development workstation began having issues with the CPU overheating. After reapplying the heatsink and fan with a fresh clean layer of thermal paste, it was still not able to stay cool. Ultimately I bought a new cooler (liquid based) and now the system is running both cooler and quieter. Unfortunately that took some time.

Some Progress

There were some minor UI improvements. Mostly minor fixes here and there, such as:

The drone status bar works now.
You can now use the shift key to apply a larger number of drones to a job. This can reduce clicks by about 90%. But, it is a stopgap, because the problem will just resurface when the number of drones you have increases by an order of magnitude. I will need to add a way for the user to specify their default click amount, and let the shift/alt keys determine multiples of that.

There will be no video update this week as I have nothing to show, and the game doesn’t even compile at the moment!

Next Week

I will finish the AI fixes this week, and see if I can get the early game research system working. I hope to have a nice big video update a week from now.

Tatzen

Weekly Update

This week I spent time working through design issues I identified last week. Mainly, how to complexify the resource gathering pipeline, the ship license system, and some of the UI. I’m still struggling a bit with some of these concepts, but I’ve gotten far enough that I can work through them by building prototypes and seeing how fun they are.

This week I:

Partially implemented a new building: Sorting Facility. This building will pull Unprocessed Ore from an Orbital Warehouse orbiting the same planet, and filter it into various buckets. Once a given bucket is full, a batch of that type of Ore will be delivered back to the Orbital Warehouse. For example, a miner may return 10 tons of “Unprocessed Ore” from Mercury, and deposit this in the warehouse. The Sorting Facility will pull the 10 tons out and into the sorting hopper, to be filtered into each appropriate bucket. Once the sorter has filled the “Iron Ore” bucket, let’s say, a batch of Iron Ore is returned to the warehouse. I have not decided what the ratios are here yet. (i.e. how many “iron ore” outcomes from the filter = 1 ton of iron ore. I think it may just be 1:1.
I removed the currency UI in the bottom right corner and integrated it into a new “top bar” UI. This will become the consolidated location for systems which are not associated with a particular building or ship orbiting a particular planet. For instance, government functions (licensing, lobbying, politics, system-wide market statistics (more on this in the future)). This frees up the bottom-right corner for some UI I need to include for controlling your ships. Currently you cannot tell how many ships you have selected, or easily see what commands are available for those ship types.

I did not meet my goal of completing the gather-build-gather resource loop this week, but I accomplished plenty on other fronts and feel good about that. This coming week I will work on the licensing system, and begin UI planning work for ship/improvement construction.

Watch the video below to see this week’s work in action.

Video

Tatzen

Devlog #4

This week I spent some time implementing numerous UI fixes and improvements, feature gating behind game progress, and prototyped out some of the design ideas I proposed last week.

I am encountering new design challenges, which is that there’s not a lot to do at this point. The game goes into an idle state very quickly, and you will be bored earlier. Periods of time where there isn’t much to do are a hallmark of the genre, but every good idle/incremental has an initial “hook” that grabs the player and says “hey look at this! you want MORE of this!”. Generally idle games can be pretty “high touch” during the first few hours. I’d like to find a way to make the early hours more enticing, and so I will spend the coming week thinking of ways to do that. The void of space is pretty hard to overcome, though.

Overall, this week was dense with lots of accomplished small tasks. I expect next week, being largely a “design heavy” week, will not involve a lot of visible progress. But maybe a spark of inspiration will change that. We will see.

Week in Review

In summary, over the last week I accomplished:

Finished the sorting facility implementation.
Added a way for the UI to display “tooltip” style UI elements.
Added a way to select planets from the UI.
Added a new UI element to show your total resources in the UI.
Added ship license purchasing and progress system.
Reworked the Spacedock UI.
Improved navigation of the world by allowing use of the middle mouse button for dragging of the camera.
Began prototyping a new UI widget to track drones.

Screenshots

The new license acquisition system:

Drone Assembly UI:

As always, see the video below for a more in-depth view.

Video Update

Click below to watch it on YouTube:

Tatzen

Week 6

This week I spent a large amount of time designing and implementing a new ship type: Research Vessel. This ship allows the player to generate Research Data, which, upon accumulating 100,000 units, becomes a Research Point. Research points are then used to purchase levels in various Research Projects. Under this system the player will gain enhancements for other game mechanics: ship performance, access to new orbital improvements, enhancement of those orbital improvements, etc.

There is a new UI screen that shows the status of research data accumulation, points, and projects:

Ongoing Struggles & Next Week

With the introduction of research the game is beginning to feel more engaging – there’s more to look forward to for the player, there are more decisions to be made (which ship type should I spend my next license on?), more goals (completing projects). That said, the game still feels very empty, and I really need to identify a way to flesh out the resource acquisition and processing. Currently there is acquisition (mining), sorting (the sorter), and that is the terminus.

I would like to experiment with processing, perhaps adding an Orbital Autofactory building type which can produce materials of various types. I have mentioned this before – turning Iron Ore into Iron Plates, for example. This will require significant design and development, as I have not yet implemented player-built orbital improvements. Currently the player starts the game with a Spacedock, an Orbital Warehouse and an Orbital Sorter. The UI for these buildings is just a series of buttons at the bottom of the screen, and it will not scale well for having a large number of improvements. I need to consider an icon-based system (perhaps a grid, almost like an “inventory” of building types. Maybe they have different sizes? I’m imagining a Diablo-style inventory system. Literally thinking “out loud” while I type this.)

Finally, I need to consider the credits system, which is currently the only “money” in the game. I need to decide how this will be used, if at all, and what the benefit to the player is.

Video Update

I am back with a video update this week. Click below to see the Research System in action.

Tatzen

Week 8

This week I spent time re-envisioning the space game. I have been really unhappy with the state of the game and not finding the “fun” that I want out of it. Over the last week I did make substantial progress and I have a new path I’m taking.

I have decided that the game will give you multiple fleets, each with an associated capital ship. The capital ship will be the “hub” of activity for that feature, and every capital ship will have some kind of “top level” idle mechanic associated with it. In the current version, there is one capital ship: the mining capital ship. This ship acts as the resource hub for mining, allowing you to move it to wherever you want, and having your miners mine nearby planets. This allows you to reduce roundtrip times between the mining node and the resource hub.
I have pulled every menu that was associated with planets (e.g. spacedock, warehouse, sorter) and merged them into top-level features so you can access them without having to locate them in the world. This feels a lot better to the player.

Here is the UI for the new, combined “Mining Fleet”:

The new capital ships can serve as an orbital body for smaller ships:

Here the fleet is mining:

Lastly, I am working on adding a game progression feature to the mining fleet, which is engineering & crafting. The idea here is that every capital ship should provide some core “growth” mechanic for the game as a whole. For mining, this means converting resources into projects and components, which can be used to upgrade your capital ships. More on this later.

Managing my Motivation & Coming Weeks

My motivation for this project has waned significantly. I think I am reaching the point I reach with a lot of these projects, where I have yet to “find the groove” in making a game I enjoy making and playing. This is an expected and not at all surprising outcome.

As a result, I’m going to spend the next couple of weeks working on it less and trying to redevelop my interest in it. I make games as a hobby, not a profession, and it competes for my spare time. I am also a Path of Exile player, and there is a big content patch later this week so I expect my “game playing” time will reduce my “game making” time. Again, this is good. I do this for fun, and so it competes with other fun things.

Idle Overworld?

I have been thinking about returning to an older project of mine, which was another idle game involving an RPG overworld. I don’t think I will, but the fondness with which I look upon the work I did there is a reminder that part of my loss of motivation on these projects is that I simply get tired of looking at them. So, maybe the time focusing on other hobbies over the next couple of weeks will renew my motivation.

Here’s some screenshots of my older project:

Definitely had “good bones”. Might come back to it.

Weekly Video

No video this week. I will resume posting videos when progress continues.

Tatzen

Week 9: Not Much

This week I took time off from my personal projects and basically worked a lot and focused on Path of Exile.

As a part of that, I did build a small simulator that modeled the damage output of the Path of Exile bleed mechanic, but it’s not something I plan to share with the world. Here’s a screenshot:

Next Week

More of the same, I predict. I’m taking a brief break from game dev. But I wanted to continue posting here so it is easier for me to transition back into active dev work.

Tatzen

Update from Last Week

This week I worked on a lot of core mechanical issues. Last week I set a goal for myself: have the core gameplay loop working, so that I can collect resources and spend them to buy more ships. I give myself about a 50% success on this one, as the ships now collect resources, return them to the nearest Orbital Warehouse (OW), and the OW user interface displays them. What I did not accomplish is the purchasing of new ships. This currently still costs the player nothing, as I have spent a lot of time throwing ideas against the wall to figure out how I want the cycle to work.

Design Challenges

Originally, I wanted “credits” to be the core currency. An ever-rising number that you make by selling resources. The loop is then: build ship -> obtain resources -> sell resources -> buy more ships. This felt transparent and boring, and I have decided that I’m going to add resource processing to the game, in the form of orbital improvements that can turn X resource into Y.

For example: miners collect “Raw Minerals”, which is basically “mineral rich dirt”. These need to be sorted in an Orbital Centrifuge, which will fill up “buckets” of various ore types until the progress bar is full, and the player will obtain 1 ton of that ore type. The ore shows up in the adjacent warehouse, and then can be picked up by an Orbital Metals Refinery, which can turn the ores into various products. Much of this still design stage, though I have worked on some UI mockups.

Next Week

This coming week I would like to implement the Orbital Centrifuge and Orbital Metal Refinery, allowing production of Iron Plates, which will be used to build ships, upgrades and orbital improvements. If I end next week with those two buildings fully working, I will feel accomplished.

Video Demo (Click for YouTube)

Tatzen

Week 7

This week I spent some time doing pixel art and VFX for a new feature in the game: capital ships. I’ll admit that this week was more of a “fun tasks” week, which basically involved me spending some time doing art, and obsessing over some unimportant but otherwise satisfying visual presentation stuff.

I have wanted for a while to add a feature to the game that gave players a more important “ship” to manage. Right now all ships are very small and perform specific isolated tasks. I think upgrading these ships should be noncomplicated, perhaps either automatically occurring with experience level and research projects. But I want an experience in the game where the player can “kit out” a vessel with modules, better engines, etc. So, I had this idea for capital ships:

A capital ship is a massive ship, much larger than your small mining and research vessels.
Moving them is slow and time consuming.
They should have impressive visual effects and a paperdoll design for showing player customization.
They should be able to be named, with the default name pulling from a library of cool names.
They should be customizable, allowing the upgrading and replacement of several components.
They should be hard to obtain, but introduced early.
They should primarily form a support role, amplifying the effect of other ships.
They should have an area of control either based on an heliocentric “donut” so they can buff multiple planets. This should be expandable with ship upgrades.
Obtaining ship modules is TBD. I’m thinking crafting. But the game needs crafting and it currently doesn’t have it.

I started by looking at some references from sci-fi movies, tv shows and books, as well as other artwork. First I blocked out a “massing” to get the size right:

Added some details and more sense of volume, as well as thrust that matches the engine design:

More details:

Video

I posted a YouTube video update as well:

Tatzen

Week 9: Not Much

This week I took time off from my personal projects and basically worked a lot and focused on Path of Exile.

As a part of that, I did build a small simulator that modeled the damage output of the Path of Exile bleed mechanic, but it’s not something I plan to share with the world. Here’s a screenshot:

Next Week

More of the same, I predict. I’m taking a brief break from game dev. But I wanted to continue posting here so it is easier for me to transition back into active dev work.

Tatzen

Week 8

This week I spent time re-envisioning the space game. I have been really unhappy with the state of the game and not finding the “fun” that I want out of it. Over the last week I did make substantial progress and I have a new path I’m taking.

I have decided that the game will give you multiple fleets, each with an associated capital ship. The capital ship will be the “hub” of activity for that feature, and every capital ship will have some kind of “top level” idle mechanic associated with it. In the current version, there is one capital ship: the mining capital ship. This ship acts as the resource hub for mining, allowing you to move it to wherever you want, and having your miners mine nearby planets. This allows you to reduce roundtrip times between the mining node and the resource hub.
I have pulled every menu that was associated with planets (e.g. spacedock, warehouse, sorter) and merged them into top-level features so you can access them without having to locate them in the world. This feels a lot better to the player.

Here is the UI for the new, combined “Mining Fleet”:

The new capital ships can serve as an orbital body for smaller ships:

Here the fleet is mining:

Lastly, I am working on adding a game progression feature to the mining fleet, which is engineering & crafting. The idea here is that every capital ship should provide some core “growth” mechanic for the game as a whole. For mining, this means converting resources into projects and components, which can be used to upgrade your capital ships. More on this later.

Managing my Motivation & Coming Weeks

My motivation for this project has waned significantly. I think I am reaching the point I reach with a lot of these projects, where I have yet to “find the groove” in making a game I enjoy making and playing. This is an expected and not at all surprising outcome.

As a result, I’m going to spend the next couple of weeks working on it less and trying to redevelop my interest in it. I make games as a hobby, not a profession, and it competes for my spare time. I am also a Path of Exile player, and there is a big content patch later this week so I expect my “game playing” time will reduce my “game making” time. Again, this is good. I do this for fun, and so it competes with other fun things.

Idle Overworld?

I have been thinking about returning to an older project of mine, which was another idle game involving an RPG overworld. I don’t think I will, but the fondness with which I look upon the work I did there is a reminder that part of my loss of motivation on these projects is that I simply get tired of looking at them. So, maybe the time focusing on other hobbies over the next couple of weeks will renew my motivation.

Here’s some screenshots of my older project:

Definitely had “good bones”. Might come back to it.

Weekly Video

No video this week. I will resume posting videos when progress continues.

Tatzen

Week 7

This week I spent some time doing pixel art and VFX for a new feature in the game: capital ships. I’ll admit that this week was more of a “fun tasks” week, which basically involved me spending some time doing art, and obsessing over some unimportant but otherwise satisfying visual presentation stuff.

I have wanted for a while to add a feature to the game that gave players a more important “ship” to manage. Right now all ships are very small and perform specific isolated tasks. I think upgrading these ships should be noncomplicated, perhaps either automatically occurring with experience level and research projects. But I want an experience in the game where the player can “kit out” a vessel with modules, better engines, etc. So, I had this idea for capital ships:

A capital ship is a massive ship, much larger than your small mining and research vessels.
Moving them is slow and time consuming.
They should have impressive visual effects and a paperdoll design for showing player customization.
They should be able to be named, with the default name pulling from a library of cool names.
They should be customizable, allowing the upgrading and replacement of several components.
They should be hard to obtain, but introduced early.
They should primarily form a support role, amplifying the effect of other ships.
They should have an area of control either based on an heliocentric “donut” so they can buff multiple planets. This should be expandable with ship upgrades.
Obtaining ship modules is TBD. I’m thinking crafting. But the game needs crafting and it currently doesn’t have it.

I started by looking at some references from sci-fi movies, tv shows and books, as well as other artwork. First I blocked out a “massing” to get the size right:

Added some details and more sense of volume, as well as thrust that matches the engine design:

More details:

Video

I posted a YouTube video update as well:

Tatzen

Week 6

This week I spent a large amount of time designing and implementing a new ship type: Research Vessel. This ship allows the player to generate Research Data, which, upon accumulating 100,000 units, becomes a Research Point. Research points are then used to purchase levels in various Research Projects. Under this system the player will gain enhancements for other game mechanics: ship performance, access to new orbital improvements, enhancement of those orbital improvements, etc.

There is a new UI screen that shows the status of research data accumulation, points, and projects:

Ongoing Struggles & Next Week

With the introduction of research the game is beginning to feel more engaging – there’s more to look forward to for the player, there are more decisions to be made (which ship type should I spend my next license on?), more goals (completing projects). That said, the game still feels very empty, and I really need to identify a way to flesh out the resource acquisition and processing. Currently there is acquisition (mining), sorting (the sorter), and that is the terminus.

I would like to experiment with processing, perhaps adding an Orbital Autofactory building type which can produce materials of various types. I have mentioned this before – turning Iron Ore into Iron Plates, for example. This will require significant design and development, as I have not yet implemented player-built orbital improvements. Currently the player starts the game with a Spacedock, an Orbital Warehouse and an Orbital Sorter. The UI for these buildings is just a series of buttons at the bottom of the screen, and it will not scale well for having a large number of improvements. I need to consider an icon-based system (perhaps a grid, almost like an “inventory” of building types. Maybe they have different sizes? I’m imagining a Diablo-style inventory system. Literally thinking “out loud” while I type this.)

Finally, I need to consider the credits system, which is currently the only “money” in the game. I need to decide how this will be used, if at all, and what the benefit to the player is.

Video Update

I am back with a video update this week. Click below to see the Research System in action.

Tatzen

Devlog #5

This weeks update is brief, due to a lack of visible progress on the game. At the end of last week I predicted this week would be “design heavy” and result in a lack of visible progress, but I feel that progress was even less than I predicted, for several reasons:

I have decided to try implementing Research Ships as an early game mechanic to give the player something else to care about while waiting for miners to produce resources. I don’t want to dramatically increase resource acquisition in the early game, nor dramatically reduce resource costs, as this might trivialize later game scale. As such, I began implementing a research ship. Which leads me to problem #2.
From the outset of this project I have just been dumping increasing amounts of logic into the AI Update() tick for mining ships. The problem is that a substantial amount of what mining ships do can be generalized for all space fairing vessels, be them ships or stations. At this point I had a choice: continue adding more complexity to this already monolithic piece of logic, or refactor. I chose the latter which leads me to problem #3.
There are a lot of AI design patterns for games, and it’s not really my area of expertise. I have implemented a few of them over the years but I wanted to do a better job this time. Part of why I make games is because I want to refine my command of the artform. So I spent a lot of time looing at the work of others, and made some prototype implementations of a few approaches:
1. Simple state machine. This works pretty well but I start having issues with state history, nested states, etc. The complexity becomes pretty ugly.
2. Hierarchical state machine. This allows for multiple states to exist within a single state, by giving some states their own internal state machines. It’s a lot of complexity but it allows for the flexibility I want. Maybe slightly overblown for this project, but again, I’m partly here to learn and I want to see how it goes. I am currently implementing this model, but it is not yet working.
3. Behavior Trees. This is pretty interesting but it seems most useful for AI that needs to exist in a more dynamic world where unforeseen conditions regularly arise. The game I’m building isn’t really like that, so I didn’t see a strong need to implement something like that.

To make the week more interesting, my primary development workstation began having issues with the CPU overheating. After reapplying the heatsink and fan with a fresh clean layer of thermal paste, it was still not able to stay cool. Ultimately I bought a new cooler (liquid based) and now the system is running both cooler and quieter. Unfortunately that took some time.

Some Progress

There were some minor UI improvements. Mostly minor fixes here and there, such as:

The drone status bar works now.
You can now use the shift key to apply a larger number of drones to a job. This can reduce clicks by about 90%. But, it is a stopgap, because the problem will just resurface when the number of drones you have increases by an order of magnitude. I will need to add a way for the user to specify their default click amount, and let the shift/alt keys determine multiples of that.

There will be no video update this week as I have nothing to show, and the game doesn’t even compile at the moment!

Next Week

I will finish the AI fixes this week, and see if I can get the early game research system working. I hope to have a nice big video update a week from now.

Tatzen

Devlog #4

This week I spent some time implementing numerous UI fixes and improvements, feature gating behind game progress, and prototyped out some of the design ideas I proposed last week.

I am encountering new design challenges, which is that there’s not a lot to do at this point. The game goes into an idle state very quickly, and you will be bored earlier. Periods of time where there isn’t much to do are a hallmark of the genre, but every good idle/incremental has an initial “hook” that grabs the player and says “hey look at this! you want MORE of this!”. Generally idle games can be pretty “high touch” during the first few hours. I’d like to find a way to make the early hours more enticing, and so I will spend the coming week thinking of ways to do that. The void of space is pretty hard to overcome, though.

Overall, this week was dense with lots of accomplished small tasks. I expect next week, being largely a “design heavy” week, will not involve a lot of visible progress. But maybe a spark of inspiration will change that. We will see.

Week in Review

In summary, over the last week I accomplished:

Finished the sorting facility implementation.
Added a way for the UI to display “tooltip” style UI elements.
Added a way to select planets from the UI.
Added a new UI element to show your total resources in the UI.
Added ship license purchasing and progress system.
Reworked the Spacedock UI.
Improved navigation of the world by allowing use of the middle mouse button for dragging of the camera.
Began prototyping a new UI widget to track drones.

Screenshots

The new license acquisition system:

Drone Assembly UI:

As always, see the video below for a more in-depth view.

Video Update

Click below to watch it on YouTube:

Tatzen

Weekly Update

This week I spent time working through design issues I identified last week. Mainly, how to complexify the resource gathering pipeline, the ship license system, and some of the UI. I’m still struggling a bit with some of these concepts, but I’ve gotten far enough that I can work through them by building prototypes and seeing how fun they are.

This week I:

Partially implemented a new building: Sorting Facility. This building will pull Unprocessed Ore from an Orbital Warehouse orbiting the same planet, and filter it into various buckets. Once a given bucket is full, a batch of that type of Ore will be delivered back to the Orbital Warehouse. For example, a miner may return 10 tons of “Unprocessed Ore” from Mercury, and deposit this in the warehouse. The Sorting Facility will pull the 10 tons out and into the sorting hopper, to be filtered into each appropriate bucket. Once the sorter has filled the “Iron Ore” bucket, let’s say, a batch of Iron Ore is returned to the warehouse. I have not decided what the ratios are here yet. (i.e. how many “iron ore” outcomes from the filter = 1 ton of iron ore. I think it may just be 1:1.
I removed the currency UI in the bottom right corner and integrated it into a new “top bar” UI. This will become the consolidated location for systems which are not associated with a particular building or ship orbiting a particular planet. For instance, government functions (licensing, lobbying, politics, system-wide market statistics (more on this in the future)). This frees up the bottom-right corner for some UI I need to include for controlling your ships. Currently you cannot tell how many ships you have selected, or easily see what commands are available for those ship types.

I did not meet my goal of completing the gather-build-gather resource loop this week, but I accomplished plenty on other fronts and feel good about that. This coming week I will work on the licensing system, and begin UI planning work for ship/improvement construction.

Watch the video below to see this week’s work in action.

Video

Tatzen

Update from Last Week

This week I worked on a lot of core mechanical issues. Last week I set a goal for myself: have the core gameplay loop working, so that I can collect resources and spend them to buy more ships. I give myself about a 50% success on this one, as the ships now collect resources, return them to the nearest Orbital Warehouse (OW), and the OW user interface displays them. What I did not accomplish is the purchasing of new ships. This currently still costs the player nothing, as I have spent a lot of time throwing ideas against the wall to figure out how I want the cycle to work.

Design Challenges

Originally, I wanted “credits” to be the core currency. An ever-rising number that you make by selling resources. The loop is then: build ship -> obtain resources -> sell resources -> buy more ships. This felt transparent and boring, and I have decided that I’m going to add resource processing to the game, in the form of orbital improvements that can turn X resource into Y.

For example: miners collect “Raw Minerals”, which is basically “mineral rich dirt”. These need to be sorted in an Orbital Centrifuge, which will fill up “buckets” of various ore types until the progress bar is full, and the player will obtain 1 ton of that ore type. The ore shows up in the adjacent warehouse, and then can be picked up by an Orbital Metals Refinery, which can turn the ores into various products. Much of this still design stage, though I have worked on some UI mockups.

Next Week

This coming week I would like to implement the Orbital Centrifuge and Orbital Metal Refinery, allowing production of Iron Plates, which will be used to build ships, upgrades and orbital improvements. If I end next week with those two buildings fully working, I will feel accomplished.

Video Demo (Click for YouTube)

Tatzen

It’s me, tatsumi_oreo, aka tatsumi, aka Tatzen, aka John Hargrove. It feels good to be posting something to the v-rpg domain after all these years. Half the reason I’m doing this is for that feeling alone.

What Have I Worked On?

Over the last couple of decades I have left a trail of abandoned game development projects. Probably 100 of them. I don’t think that is an exaggeration. I average 5-6/year, and have for most of my adult life. So, probably approaching 100 abandoned projects. Anyway. I have a new victim!

The Project

I am currently working on a small project based around space fleet management. I play a lot of idle and management games. I like making numbers go up. It’s a simple mechanic. Key components of the genre are:

One or more numbers that just get ever bigger.
Geometric growth of some numbers, such that continuous linear gain becomes ineffective after some hours of play, requiring the introduction of a new scalar.
Leaving the game idle is beneficial but doesn’t scale. E.g. you may increase X by some linear amount, but due to your inaction, you have missed out on additional growth.
Offline support. The game still grants you resources while you are not playing. (Usually by simulating lost time during game loading.) I don’t know if this game will support this. I’m working that out.

The current vision is that you will start with a small amount of credits, which you may use to purchase your first mining vessel. You may assign this vessel to mine a planet. Rarer resources will be located in the extreme reaches of the solar system. The mining vessel will have a fixed storage (related to its low tonnage and optimized-for-drilling design.) In the early game, your ship will fill up with a small amount of resources (perhaps several tons), and then fly this back to earth where it will be delivered to your orbital warehouse. At this point, the player may liquidate the resources into credits. The credits may then be used to expand the fleet.

Over time it may become apparent that the mining vessels are good at mining and bad at transporting things. This will necessitate the production of large shipping vessels, which are quite expensive (for balance reasons), but can do the business of moving goods around the star system while the miners are performing mining operations. This will require construction of an orbital warehouse around the mined planet.

I have a lot more to share but I don’t want to make this into a design document. So with that in mind I will lay out some quick points:

Orbital mechanics, physics, etc. The game does not simulate orbital mechanics. Planets orbit stars, but they do so based on basic trigonometry and known orbital periods. I.e. the planets have no simulated velocity, only a present location, a known orbit, and a current timestamp. This is easier for me to simulate. It may cause issues. Ships may orbit planets or stars, and they may change orbits or travel between objects in the system. These maneuvers assume the ships have significant impulse power, and thus do not rely heavily on traditional orbital transfer mechanics. In other words, there are no “launch windows”. If a ship wishes to orbit another body, it will reorient itself in an approach vector, accelerate into the vector (smoothly) and arrive. Currently this includes flying through other objects (for example, the sun, ha.) I may correct for that but I have no intention of correctly implementing orbital physics.
Scale. Planets, relative to each other, are realistically sized. Relative to their orbits, they are not. The sun has been scaled down. Ships appear huge, literally planet sized in some cases, but I need them to be a playable size, and so it shall remain. I’m tweaking these size relationships constantly as I feel the adjustment is needed.
My design here is loose. The game is as much a technical challenge for myself as anything, and as such I may spend time focusing on details that are not super important to the game design but are technical challenges of personal interest to me.
The game is built in Unity. It is my engine of choice, mainly because I like C#.
This game may never be completed. My hope is that posting here will help me avoid that, but I am aware of my personal limitations and my desire to spend some of my free time playing rather than making video games, and depending on my personal stress level which I may choose one or the other.