Pre-Order the Game!

Desura Digital Distribution

Friday, March 29, 2013

Regions and Sliders Design

I'm going to overhaul how regions are done, and introduce an exciting new feature, but let me explain why I added regions in the first place.

In Master of Orion 2, in end-game, when you've obtained most or all of technologies, colonizing a new planet is a pain in the butt.  Why?  Because you need to queue up buildings that you want to be built.  Which buildings?  It don't matter, because they all help your planet out (Automated factories usually go first because it speeds up production of other buildings).  So in the end-game, you don't really care about which buildings to build, just that you want all of them built.  This kinda defeat the purpose of having unique buildings.  Unique buildings aren't important when you just want "All of the above" approach.

I wanted to have "unique" buildings/areas on a planet where you just can't have "All of the above", and took my inspiration from MoO 3's regions.  While overall, MoO 3 may be a disappointment, but I've found many elements inside it that I really like, and this is one.  With regions, you can have different races inside one region, and each region have their own improvements, limiting which buildings you can build on a planet.

However, I'm now at the point where I need to rework the UI and stuff for planets to work under the new system, I realized that I may be looking at it wrong.  Having unique buildings across specialized regions across planets across the galaxy can easily defeat the whole purpose by introducing tedious micromanagement with little rewards, where you just don't care about that one little building that boosts farming by 10% in an obscure corner of the galaxy.  It also makes each unique building lose their significance.  It'll devolve into "I need more food, let's build an farming region on the next available region and build all farming region buildings there!"

I spent some time thinking about how to avoid this and reading people's suggestions about my game (particularly the one over at rpgcodex), and I think I finally stumbled on an elegant solution that will help me achieve what I originally wanted.  So here's how I'm doing this:

Regions will be replaced with "SectorObjects".  You may be thinking, wait, isn't a planet a SectorObject as well?  The idea is that each SectorObject can have a subset of SectorObjects (aka regions).  This means that you can be as detailed as you want while modding (Having cities in regions in a country in a planet for example), and the game will handle it automatically.  

If a SectorObject contains a subset of SectorObjects, then it derives its population and economy from the subsets and adds them up for the UI to display statistics. Only the bottommost SectorObjects can be controlled by an empire, and as a result, they're the only ones with projects and sliders.  SectorObjects can be changed to different SectorObjects as a result of projects (for example, changing from Farming to Mining region, or terraforming from Desert to Terran planet).  Sliders are defined in data files. If only one slider is defined for a SectorObject, then it's hidden and always at 100% (this allows you to mimic Moo 3's regions).

What does all of this mean to you as a player?  It means that you can share planets with other empires!  Owning a SectorObject requires that certain requirements are met, such as sacrificing a colony ship, creating a project to colonize one, or having migration be able to migrate there without owning it first.  Once owned, your people will automatically migrate there, reducing the need of manually moving around your people.

Now, what about ground combat?  How will they be handled?  I think I have another brilliant idea.  Since each subset SectorObject has a parent SectorObject, you can choose to either invade the whole parent SectorObject, or invade each subset individually.  So if you're invading a planet that is 50% owned by an ally, you can choose to invade only the enemy regions, leaving the allied ones alone.  However, if none are friends of yours, you can invade the whole planet.  The ground combat will be handled like MoO 1.  Also, if you feel that you're outmatched, you can choose to invade only one region and establish that as a foothold.  Same goes for planet bombardment (selecting all of the planet, or just a few regions to bomb)

How does this help me achieve "Unique buildings"?  Another change is that the SectorObjects will have "limited space" for development.  This means that if a region have only 20 "Space", and you build something that takes up 10 spaces, it'll force you to choose carefully on what you want to build.  Also, with sliders back in, you can leave a region "Unspecialized" which don't give any bonuses or penalties for producing something, or change it over to specialized.  For example, if you change from Unspecialized to Farming, then the farming output is doubled, while mining, industry, and commerce are all halved. Then you can build few certain buildings (some may be restricted to certain types of regions, such as Automated Mining for Mining regions only) to further enhance the bonuses or to alleviate the penalties.  Each region can have their own special bonuses/penalties such as fertile grounds, radioactive deposits, etc.  If you change to a different SectorObject, any improvements that don't meet its criterias will be automatically scrapped.

All of this can be managed from one screen that for now I'll dub "Economy Management", you will be able to filter out planets or regions, apply broad changes (such as increasing food output to 50% across all farming regions) or even individually manage each region and their project.  This should help in reducing the tedium in managing planets, while allowing hundreds of planets under your control!

Tuesday, March 26, 2013

Finished with Gateways!

I've fixed and finished all four algorithms for connecting gateways (Maximum Spanning didn't really make sense, but if popular demand requires, I can add it later).  Here's what I really like about this new approach is that it allows for isolated islands across the expanse.  This is what happens if a star is randomly allowed between 1 to 4 starlanes:

Note the 5 stars on top right area that's connected together, but not to the rest of the galaxy?  Yeah, they didn't have spare starlanes to connect to the rest of the galaxy.

This is what happens if you change the amount to 2 to 4 starlanes per star:

All stars are connected  This new approach is actually better than my old implementation of starlanes, in that it don't have those random extremely long starlanes.

I also got rid of the 2D engine's capture of mouse, and instead used Windows mouse events to handle clicking and moving.  It performs exactly the same, but with three benefits: No more weird mouse jerking when FPS is low, it don't change the mouse speed when entering the screen, and it should fix some incorrect mouse position issues that some people reported.

I also updated the background stars to use the new BBSprite, and it've boosted the performance a bit!  In case you're wondering "Isn't that a bit too many nebulaes?", the galaxy generation script is very simple and has 33% chance of spawning compared to a star or black hole.  I plan to tweak it in the future so there's only one nebula of each type, up to 6 nebulaes, in a cluster galaxy.

Saturday, March 23, 2013


I've added a "SpriteManager" that allows me to load in sprites via data files, instead of hardcoding the locations of sprites inside the code itself.  I plan to revamp the UI drawing algorithm to be dynamic based on the sprites that it's using.  For example, if you have a 2x2 corner sprite for a background window border, it'll correctly draw that.  Same for 200x200 corner.  That way, I don't need to worry about manually setting the size and positions of UI in code, it'll handle itself.  It'll help speed up creation and tweaking of UIs in future.

SpriteManager should allow me to render stuff faster because instead of looking up a sprite then drawing it, all objects that contains a reference to the "lookup" will now instead hold a reference to the sprite itself, cutting down some processing time.

I've replaced the star sprites with BBSprites, and they're now animated!  Black holes are animated as well, but seeing it in motion, I'm not too happy with it, so I'll have my artist re-do the black hole soon.  However, I found a bug, since they're holding a reference to the same BBSprite, all stars of the same color twinkle at the same time.  Oh well, at least it's rendering and loading stuff correctly!  Here's a screenshot of a couple of stars twinkling (Blue and Orange is twinkling, they're a bit bigger than normal):

Monday, March 18, 2013

Wormholes and Starlanes! Well, kinda...

I've re-worked the old drawing code for starlanes to work with the new system.  Note that when you define a "gateway", you also define the distance multiplier and its color.  For example, a stargate would be not connected, has multiplier of 0 (meaning it takes 1 turn to move to other system with a stargate).  A wormhole is connected, has multiplier of 0, and has the color of green.  A starlane is connected, has no multiplier (uses default distance), and is white.

You then define which, if any, and amount of each, that a star system can have.  So this way, if you dislike starlanes with a passion, you can just remove it from the data files, and the game won't even know it's not there.  Likewise with wormholes.

When I got the rendering working, I realized that my connecting algorithm (closest/farthest) didn't exactly work...  For this test, each star has a minimum of 2 starlanes, and maximum of 4.  So theoretically, each star should be connected to at least one other star, right?  Well... here's the result (note that black holes have 50% chance of having a wormhole, so it may connect to a star that have 5% chance of wormhole).  I'll need to fix the connecting algorithms, but this is the first screenshot with wormholes!

Saturday, March 16, 2013

Nebulaes and new stars

I'm currently working on overhauling the starlanes/sectors/etc system so that it's mostly data driven.  So far, the new galaxy generation code is complete, with two of the five connecting algorithms implemented.  I've explained that you can set a sector type to be a gateway, meaning that it connects to another star system.  You can pick one of the five available connecting algorithms.  They are:

Shortest - This algorithm is greedy in that it goes through the list of star systems and connects the closest systems, even if those systems have other systems more close.  Example, Star A have 2 starlanes, and it connects to Star B and C.  However, Star B has two other stars, D and E, that are closer, but since Star A was processed first, it's connected to A and D instead.

Farthest - Opposite of shortest - Useful for wormholes

Random - Systems are connected randomly - Useful for wormholes - an alternative

Minimum - This uses Minimum Spanning which attempts to connect all stars in the "smallest" tree possible.  This is similar to Shortest, but is not greedy

Maximum - Opposite of Minimum, with longest paths, but avoids intersecting existing paths, so it won't have systems connecting on opposite sides of galaxy

I've implemented Shortest and Farthest because they're relatively simple to do.  The other three are put on hold while I re-work the starlane drawing algorithm.

The galaxy generation script now specifies the type of star to place.  Before it'd just generate a list of points, then have the game randomly pick the type.  But I realized that some modders may want more control, so I've updated the game to allow the script to specify the type.

Another thing that I decided to change is the size of the stars.  They're now 32x32 pixels instead of 64x64, and have animation (random flare-up similar to MoO 1).  The artist has supplied me with the new artwork.  Included are 6 new nebula artwork, they are visitable locations in the game with random surprises.  Black holes are also reduced to 32x32, and are constantly animated.  The animation part is not working yet, I'll need to add an image handling class that handles animation and other stuff.  But here's a screenshot of the new artwork!  It no longer feel like you're up against the screen (this is at closest zoom) :)

Thursday, March 7, 2013

Status Update

Thank you all for your help in making the kickstarter a success!  I apologize about the delay in updates, I've been sick on and off.  Anyway, I will post updates here and on Kickstarter.  As a result, only significant updates will be posted on kickstarter, while both those and small updates will be posted here.  The big updates will include information from small updates as a review so kickstarter guys won't miss anything.

I've been sick on and off, today I'm going to a specialist doctor to start investigating the cause.  Hopefully I'll be able to figure it out and fix it.  I'm starting to suspect that I may have developed a new food allergy, but we'll see what the doctor says.

I've sent out surveys for the tier awards, and most have responded!  For those who haven't responded yet, don't worry, take your time (unless Kickstarter has a time limit on surveys? I'm not sure about that).  Kickstarter sends out automated reminders, so if you want to take more time, ignore those.

Anyway, I've started to feel better today, so tonight I'll send out the Desura key codes for backers.  I apologize for taking a long time to do this, but the stupid sickness has drained my energy.

As for the development side of the game, recently I got a 4X game called Armada 2526 Gold since people said it is pretty similar to MoO 1/2.  After "researching" it for a bit, I have realized that I need to make some changes to my game to make it more pleasant and fun.

First of those changes are the stars themselves.  Currently, they're 64x64 pixels, and takes up a lot of real estate, and makes it feel like you're zoomed in really close.  Also, they're not animated.  So I've asked my artist to re-do the stars after he's done with spiders, making them 32x32, and have animation so they'll occasionally flare up (similar to MoO 1).  Black holes will also be constantly animated, and 32x32 as well.  Nebulae will be added back, but as a visitable destination instead of being in the background.  As soon as those art are done, I will add them and show a new screenshot!  This should help make the galaxy feel more alive.

Speaking of spiders, I've decided on the name "Araneas" as per feedback from you!  They are actually peaceful, except when they're hungry, so the name fits :)  The artist is almost done with this race's artwork.  Here's a peek at one of their large ships :)  Customers of this game will get the full artwork.

In case you don't know how the ships are rendered in the game, I use a shader to modify the red color to become the empire's color.  So you see the red paint on the spider ship? Those will be replaced with appropriate shade from your empire's color.  This enables me to have the same race across multiple empires, and to be able to distinguish between them in space combat.  I will add a game configuration option to limit one race per game to have it match MoO 1/2, but for stock Beyond Beyaan, you can have multiple empires of the same race.