Pre-Order the Game!

Desura Digital Distribution

Saturday, May 19, 2012

Design Screen update and future plans

It looks like I'm not going to get the basic gameplay working by May 31st :( That's not from lack of effort though, I just underestimated the amount of work required.

But I do have some good news. I updated the design screen to work with the new data-driven ship stuff. It now have icons displaying correct information. There's no ship validation yet (grey out the add button if too much items were added for example). So for now, I'm done with design screen and equipment selection. There's still some things to polish, but for now it's functional.

Here's what it looks like:

In my last post, I asked for feedback about travelling with grid or star-to-star. The decision is made. I'm going with star-to-star movement, and re-introduce "supply range". Yes it was in game previously, but I removed it because I felt that it don't make sense if two systems far apart can contribute to the same project. I just simply gave up with explaining why it's possible to build a death star at an outpost that's not in supply range. Let's just assume that it magically gets its supplies from the other systems :D However, each system still have capacity limits, so if that outpost is just a bunch of hamsters in a shack, then they can't build a death star :)

Here's how it's going to work. I'm going to implement two different options that players can toggle with the supply range. One option is if the destination is within supply range, you can move any fleets from anywhere to that destination, even if the route between start and end is not in supply range (aka MoO 1/2). Another option is to enforce supply range, which means the entire route have to be within supply range. So if your empire is in a crescent shape, you can't go directly from one end to another in a straight line. This can generate choke points on where arms connects to the cluster in a spiral galaxy.

I hear you say "Wouldn't that increase micromanagement? You'll have to click on a star, then wait for the fleet to get there, then set the next destination." My answer is that I will add "Navigation Graph" which will take all places where circles intersect (two points for each circle intersection), then generate a route using those nodes. The game will give you a route if it's possible, and the route will end at the desired destination, but it may not be straight.

For now, I will implement the first option, as it is simplest and requires less coding. Later on I will add the second option, then starlanes at one point (again, starlanes will be an option you can turn on or off). Sounds good?


  1. This sounds like a good decision. Star to star keeps things 'simpler' in regard to space travel then the grid based way.

  2. How are you going to implement enforcing supply range? I did some thinking and for testing if a line lays completely within union of circles, came up with O(n log n) algorithm (where n is number of stars/circles). Do you have something better in the sleeve? In any case, I like the idea!

  3. What I'm planning on doing is to grab two points for each two circle intersecting and generate two nodes from those two points, and connect them to the adjacent nodes, creating a navigation graph. Then when I try and find routes, it will use those nodes to find a route within the supply range.

    This will be a lot of work however, and I'm putting it off until after other more important features are done.