Pre-Order the Game!

Desura Digital Distribution

Thursday, June 4, 2015

New Website

The official website for Dominus Galaxia has launched!  It contains goodies such as media page, news page, and even forums.  So feel free to get involved in discussions over there!

The new website is located here: www.dominusgalaxia.com, and the regular posts will be under the "News" page.

Note that we may make changes to the website, but from now on, important updates will be posted there instead of this blog.

Progress and all that :)

Sunday, May 17, 2015

First Milestone Passed!

It took us a little longer than expected to finish the first milestone.  There were some personal reasons that cropped up.  Also there were a lot of little details and bugs that we worked out.  We also implemented wormholes, pathfinding, and a bunch of under-the-hood code.  We also added some features that enhances the gameplay experiences, such as ensuring that homeworld is near at least one habitable planet, and at least two planets within 6 parsecs.  (6 parsecs is our new base range, with the "extended fuel range" doubling the fuel range, instead of adding 3 parsecs, due to larger galaxy size).

What we're doing now is cleaning up legacy code from Beyond Beyaan and Jeff's previous project that we don't need anymore, and refactoring stuff to make development easier and less susceptible to bugs in the future.  Ivan has done some work on data-driven development, so we hope to integrate that soon.  We're almost to the point where we can have Arpad start working on AI.

I will post some more screenshots below, after I detail our future plans and some of what we hope to accomplish with Dominus Galaxia.  First, the general overall direction of Dominus Galaxia:

We're working on a new website for the game, since it doesn't really make sense to post Dominus Galaxia stuff under Beyond Beyaan blog.  Jeff is working on that part, and we hope to get it up and running soon.  So it's very likely that the next post I make on this is a simple redirect to the new website.

We're also currently in process of finding and hiring artists.  We're not doing pixel artwork anymore like Beyond Beyaan.  Our first experiments with the ships in 3D space combat scene failed, it didn't look as good as we'd hoped.  So for races, we hope to be able to have similar artwork as Stardrive's race portraits, and for space combat, we're still figuring out what to do.

Speaking of races, we're revamping the list of races, to have a more gritter/serious list of races.  The racial perks will be similar, but the artwork/concepts will be different (though we may retain some races from BB that we really like).

Some of you may have caught the mention of "data-driven development".  What I mean by that is the ability to mod some aspects of the game.  We don't know to what extent we'll be able to support, but I hope it to be very flexible.  If it don't go well, we may just hard-code everything, then look at it again later when the game's done.  So right now we're trying to get what Ivan has put together working.

The downside with developing data-driven code is that there's not really much exciting news to post, and it'd look like we're not really doing much when in reality we're doing a lot behind the scenes to get it working.  So while Jeff works with UI and graphic aspects of the game in Unity, Ivan and I will work together to get data-driven working.

With that said, our second milestone is as follows:
- A working research screen with prompts on discoveries, and UI for managing technology fields' research allocation
- Fleet list screen that allows you to view list of all fleets, to scrap ships via various options (scrap design, scrap fleet, scrap ships in a fleet, etc), plus ability to center to that fleet in galaxy screen.
- Planet list screen where you can view empire's financial details, as well as view/manage list of planets.
- Ship design screen - Design new ships with new technologies.
- Data driven code - Have basics of it implemented (hopefully starting with technologies being data driven)
- Save/Load games
- Start of artificial intelligence players
- New Game screen re-worked to be more aesthetically pleasing.

We hope to accomplish those within the next couple of months!  Now for new screenshots!


Above shows wormholes (the animated squiggly lines) and proof of colonization functionality.  In a real game, the number of wormholes will be reduced.  Note that there's no "Factory" or "Cloning" sliders.  Those have been fully developed, and are no longer needed, reducing UI clutter and making the colony UI an instant resource to see what a colony lacks.  So this streamlines MoO 1's already streamlined UI even further.


This one shows a snapshot of the animated travel path (it looks a lot better in action).  One difference between DG's wormholes and MoO 2's wormholes is that fuel range propagates through wormholes.  So if you have fuel range of 10, and a planet is 4 parsecs away with a wormhole, you can explore planets up to 6 parsecs away on the other end of the wormhole.  Pathfinding takes into account wormholes and dense nebulas in determining the fastest path to destination star, and finds a valid path if blocked by antimatter nebulas.

Wednesday, April 29, 2015

The Stars, Like Dust

We're quickly approaching our first milestone!  This milestone consists of:

A working colony code with all sliders implemented.
Actual production of missile bases, ships, factories, etc.
Generation of research and tax
Exploration of star systems
Fleet movement
Colonization of habitable planets
And UI for all of the above.

Most of those are done, or being worked on. We hope to have the first milestone done within a couple of days or so.

With that said, time for another DG vs MoO 1 update!  This time, I'm focusing on the galaxy generation.  In MoO 1/2, all galaxies are random stars scattered across a rectangle.  While this isn't a bad thing, it does make gameplay follow a predictable pattern.  So what we did were to create a "density map" mechanism where players can create their custom galaxy shapes.  The map ranges from black to white (it averages the red, green, and blue values), with white being highest probability, and black being absolutely none at all.  Each density map comes in its own folder, along with a text file setting the star ratio.  The higher the ratio is, the more far spread the stars are.  This way, people can tweak the ratio until they're satisfied with the galaxy size (the size is based on ratio, one size may not be suitable for all galaxy shapes)

So, you can simply create a png image, and an accompanying text file for the ratio, and put it in a new folder, and the game will automatically include it in list of galaxy shapes.

Some of you may raise some questions: "How do you ensure that all stars are accessible?  Wouldn't having isolated stars break the game, if a homeworld is one of them?  What about anti-matter nebulae blocking all access to a star?"

When we considered those problems, we realized something.  In MoO 1, one issue in late-game is the size of the galaxy and the range/engine technologies.  Even in Huge size, going anywhere with hyper engines won't take more than 3 or 4 turns.  So the defenders don't really have much time to prepare.  Having the galaxy size small and making the stars cluster close to each other actually reduced the strategic aspects of star layout (I discussed the issue of having everything open in an earlier post, leading us to add new types of nebulas).  Imagine if stars were 15 or so parsecs apart, and the fastest engine tech only does 9 parsecs per turn, it'd give defenders more time to prepare.  This also make stargates more useful.

So what we're considering is upping the range technologies, but keeping the engine speeds the same, and spread the stars out a bit more on average than MoO 1.  How do we ensure that there's no isolated stars?  The answer is wormholes.  We will have an algorithm that ensures that all stars are reachable.  It generates a list of star groups that are not accessible to any other star groups.  It then picks a random star from two star groups and generates a wormhole, and repeat until all groups are connected.

With this, a person can create a galaxy that's so big that the only way to reach other stars are via wormholes, or so small that wormholes aren't needed.  There will be also random wormholes thrown in for variety and spice.  Without wormholes, we cannot guarantee that the galaxy is not broken.

With that said, here's some more screenshots!  The first one is our galaxy screen, with most of the UI finalized:


This next screenshot demonstrates the galaxy shape mechanism.  I used this image:


To generate this 250-star galaxy (You can easily see it's a part of the ring):



Thursday, April 2, 2015

Planet UI and Mechanisms

Hello all!  Work is progressing very well with Dominus Galaxia!  Nearly all code from Beyond Beyaan has been salvaged and converted into the new project!  We also debated and argued about small aspects of MoO 1.  We really want to get DG right.

As I mentioned in my last post, whenever there's a major difference between MoO 1 and DG, I will explain why we did what we did.  For this post, I will focus on economics and planet management.  While MoO 1's approach was simple and easy to use, it had several issues.

First, the slider dilemma.  There are only five sliders.  Each may have one or more item to perform (i.e. build shield and missile base in defense slider).  The problem is that you cannot pick which one you want the planet to focus on.  You see enemy ships incoming to your relatively new colony?  Tough, you gotta build that shield first, even if you could have built a couple of missile bases instead.

Another issue is that all sliders must add up to 100.  This means a lot of fiddling with sliders to get them right.

So here's how we're going to solve those annoying issues:

There will be an individual slider for each main item.  So shield and missile bases are split out into their own sliders.  Cloning/pop growth, terraforming, and soil enrichment are all split into three sliders, etc.  Those sliders are only visible when they're actually available.  So the shield slider won't show up until you actually research a shield technology.  It will disappear after you've built the best planetary shield.  So at a quick glance, you can easily see which items your planet can build, and what it's missing.

Also, instead of having all sliders add up to 100, we will have sliders use weighted distribution.  So you can have all sliders at 100%, it means the planet's production will be divided equally among all the sliders.  Or if you have one slider at 100%, and another at 50%, and all others at 0%, it means the first slider gets 66% of the planet's production, and the second gets 33%.  The advantage to this approach is that you can easily increase or decrease a slider, and all other sliders are impacted proportionally to their slider position.  For example, when a planet finishes terraforming, the terraforming slider is simply removed, and all existing sliders do not change positions, but they get a boost in production in proportion to their slider position.

Second, the waste.  It's annoying having to fiddle with eco slider to spend the minimum on clean-up when you've accidentally nudged it.  So we're going to simply deduct the waste from the planet's production, similar to MoO 2.  No more slider for waste clean-up.  Less useless micro that adds nothing to the game aside from frustration.

Third, the tax/reserve infusion.  There's an exploit in MoO 1 with ultra-rich planet where you can produce more than you take penalty for.  Ultra-rich triples the production on a planet, which means that you put in 150% into reserve instead of the normal 50%, and you can pour it back into the ultra-rich planet to boost it even further to 300%, without any penalties.  There's also the issue with having to remember to pour reserves into planets occasionally.

To avoid this exploit and reduce the annoying UI micromanagement, we've introduced a slider that goes from -100 to 100, with default value of 0.  When doing -100%, the planet pours everything it has available into generating reserves.  When doing 100%, the planet takes in enough reserves to double its production automatically.  This means you can leave it on at 100% on an artifacts planet, and it will always try and double its production when possible, if the empire has enough reserves, for the entire game without you having to remember to put in reserves.  With this approach, instead of having two separate UI controls, one for putting in reserves, and one for taking out reserves, we've merged the two, and eliminated the exploit of ultra-rich feeding itself.

To clarify, even if you do -100% on ultra rich one turn, then next turn change it to 100%, it will double the production for THAT TURN ONLY, and cannot produce any reserves at the same time it's getting reserves.  You cannot pour in more than a planet's total production for multiple turns like MoO 1.  You can only do one turn at a time.  So even ultra rich now suffers from the 50% penalty in taxes.

Below is a preview of the planet screen (note the reserve slider on very bottom).  Yes, it uses the same UI artwork from Beyond Beyaan, but we used DLight to "3Dify" it and make it look pretty:


Tuesday, February 17, 2015

Nebulas and Galaxy Generation

As a reminder, the objective of Beyond Beyaan was to be a MoO 1 clone.  With the merge with Jeff's project into Dominus Galaxia, we still want to make a game like MoO 1, but it won't be a straight clone anymore.  Our goal is to dissect MoO 1's weaknesses (as well as MoO 2's) and strive to try and eliminate them, while retaining MoO 1's feel.

So when there's any major difference between DG and MoO 1, I will regularly post about them, and why we do it a certain way or this way to explain our reasoning behind our decisions.  I'm going to start with the fundamental object of MoO 1, the galaxy.

One major issue in MoO 1/2 is that the galaxy is very open.  There's virtually no "strategic" locations to defend or attack, aside from planets with bonuses.  There's no bottlenecks, no natural obstacles, etc.  Some games has attempted to add strategic elements by adding features, for example, starlanes in MoO 3, unique travel mechanisms in Sword of the Stars, etc.  The major complaint is that they're "unnatural", despite adding a lot of strategic depth.

We wanted to retain MoO 1's simple fuel range, but wanted to make the map more interesting, and not have kludgy features that don't feel "right", while keeping it relatively simple.  So we took MoO 1's "Nebula slows ships" concept and expanded it further.  There are now three types of nebulas.  They are:

Anti-matter (Orange color): No stars spawns within it.  It reacts with everything else in the galaxy, thereby preventing the ability to travel through it.  In game, it's static, blocking any direct travels through it (similar to MoO 2's black holes).  Don't worry, the game will have dynamic pathfinding, so it's possible to traverse around it to your destination without having to go to other stars, provided that the entire journey is within the fuel range.

Heavy (Purple color): This is similar to MoO 1's "Slow Nebula", but it only affects the travel speed.  It does not affect shielding.  If ships were to travel at high speeds, they'd be shredded.  So ships are constrained to travel 1 parsec/turn while in heavy nebulas.

Radioactive (Blue color): Atoms are radioactive, emitting alpha, beta, and gamma.  There's so much noise in the nebula that it's impossible to detect ships within it.  Ships inside it are blind and cannot detect other ships.  In battles, it interferes with electronic systems, reducing the effectiveness of targeting computers, shields, and any technologies that has guiding mechanisms (reducing missles and torpedoes' effectiveness for example).

We've devised a method of generating nebulas that makes them look organic.  A player can control how much chance there are in spawning nebulas in the game setup screen.  Note that there's no code that ensure that all three types show up.  Some galaxy might have only one or two types, or even none.

Now for the eye candy (and also the first galaxy screenshot of DG!):

In the above screenshot, we see the anti-matter nebula taking up 1/3 of the galaxy size (this doesn't happen often!), with some radioactive nebulas on bottom (sorry about jagged edges, I cropped screenshots together).

In the above screenshot, we see dense nebula sprawling over west part of the galaxy, with anti-matter nebula on east part.


For those who may be concerned that the nebulas looks pixelated if zoomed in like my old nebula, rest assured.  Above screenshot is fully zoomed in, you can see that the nebula is not pixelated, and that the planets are 3D.

Now, for galaxy generation part.  MoO 1 and 2 basically have one shape, but several sizes.  A square-ish map of varying sizes.  We decided to create a feature where it reads in a density map to generate stars and nebulas.  The density map is a greyscale image in png format.  The more white a pixel is, the more exponentially chance of having a star spawn there.  Black means absolutely no stars at all.  Each galaxy shape is stored in a folder, with a config file that dictates how much space is needed (the player picks number of stars to play with, it will automatically calculate the size of galaxy to accomodate the number of stars).

The config file dictates which density map image is used for which.  There can be up to 4 density map for a galaxy:  Stars, Anti-matter nebula, dense nebula, and radioactive nebula.  If no nebula density is specified for a type of nebula, it defaults to the star density map.  So it's possible to create a galaxy shape with only one density map.  The reason for multiple density maps is to allow for variety of galaxy types.  For example, a ring galaxy with anti-matter nebulas filling the center to prevent travel across the center.  The possibilities are endless.

With those two features (three nebula types, and density maps for galaxy generation), we've solved the issue of MoO 1's maps being open and not very interesting, while retaining the open feel.

Thursday, January 29, 2015

Plans and a bit more of teaser

Jeff and I worked out some more details, and with feedback from previous post, here's what we plan to do:

For sure:

1. All people who have bought Beyond Beyaan (either through kickstarter, paypal, Desura, or a sci-fi promo from a while ago) will get Dominus Galaxia.
2. The source code for Beyond Beyaan will remain open source, available for anyone to use.  Dominus Galaxia will be closed source as Jeff is a full-time developer and has to make a living somehow.  I will re-use a lot of internal game logic from BB into DG to speed development up

Tentative plan:
We'll try and salvage as much artwork as possible from BB into DG, as long as they fit the graphic style.  How?  Jeff and I just found out about Sprite DLight, and it does exactly what we wanted.  So it's looking good for us to salvage some ship artwork from BB to be used in DG's space combat.  We'll see about other artwork (Jeff isn't too much of a fan of the pixel art, but with this, he's a bit more willing :) )

Here's a sample of what it can do.  A Zero People's ship before being processed by Sprite DLight:


It's flat, has no 3Dness to speak of.  Compared to pretty 3D, it's rather bland.  But look at what happen when we add 3D light magic thanks to the awesome tool (I just loaded it up in Sprite DLight and it automatically did everything, I just turned on the light!):


And here's a rendered still:

Pretty awesome, huh?  This allows for awesome lighting effects during space combat.



Tuesday, January 6, 2015

Teaser

By fate, Jeff Graw and I met somewhere on the interwebs.  He was working on his own MoO 1 clone, he has saved up enough so he don't have to work for a while, so he can work on game development full-time.  We got together and discussed about the idea of merging our two projects.  After extensive discussions, we agreed that this is the best course of action.  As a result, we came up with a new name for the game.  What we gain from merging is:
His multi-platform (developed in Unity with C# scripts) that can be published for Linux, Mac, and Windows
His fantastic 3D graphics/UI
My nearly complete game logic

With those two combined, we solved the three main issues that Beyond Beyaan faced:
No multi-platform support
Unattractive graphics (I personally liked the pixel art, but it's not for everyone)
Non-descriptive name of game. (Beyond Beyaan doesn't imply a grand 4X game)

Plus the development will go along a lot faster due to Unity's support of C#, and Jeff being a full-time game developer solely for this game while I will continue to work as a hobbyist.

It is now my pleasure to introduce the new project going forward, Dominus Galaxia!


More details will be forthcoming shortly.