Pre-Order the Game!

Desura Digital Distribution

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.

Wednesday, October 29, 2014

Progress report Oct 30, 2014

We have great news to share. Our team continues to work on BB. Currently Laszlo is spearheading the technical upgrades to make BB cross platform.
I quote one of his many contributions:
"I vote for using QT.
Here is why:
- support for Mac,Win,Linux, Android, IOS, Raspberry Pi (SFML is only for Desktop currently, but it is under development)
- good support in Linux repos
- high level abstraction or low level programming is also possible
- good documentation, a lot of examples
- Qt is complete framework, not just OpenGl wrapper:
- easy to install IDE for all Desktop platforms
- GUI description language with easy syntax ( QML )
- support in qml: buttons, lists, sprite, animated sprite with smooth transition, web browser, video, image, rotation, transition,...
- new QML objects can be implemented in C++
- javascript scripting
- sound wrapper
- build system (like CMake)
- and so on....
- you can also embed SFML widgets in QML programs! So this is also an option.
Disadvantage:
- the performance can be slow because of the high abstraction but I think there is not much animation in BB
Pros:
- it makes easy for new developers to start using it
- it is productive for GUI development.
- we can achive better results later, if new components are developed for QT.
With SFML only we have to implement each GUI feature".
He already implemented several demos including screens, custom buttons, galaxy windows, and stars. So far so good, but too early to declare full success for all platforms.

So we are moving from C# to C++ and use QT runtime environment for now unless we find a dead end or major performance problem. We maintain open source repo.

Meanwhile Brent and I had lots of discussions and made some key changes in design and have early implemenations, such as hex based space battle.

Ivan contributes with technical expertise, experience, and testing for now.

In addition, I have searched for and hired 2 master composers who agreed to compose original music for this game. Fingers crossed that they will actually deliver as promised.


So everything is heading in the right direction, but please volunteer if you think that you can help and feel the burning desire like us to do something good about this project. We do it in our free time as a service to the community and our progress is slow.

Wednesday, July 23, 2014

GSSB race done!

The artist just finished another race, bringing up the total races to 12.  The 13th and last race is currently being worked on.  Here's a look at the new race, called "GSSB".  It parodies the fact that if aliens are female, they must be attractive, thereby humanoid with distinct human features, with one or two minor differences such as color of skin or some other such cosmetic feature.  Note, this is not intended to be derogatory toward women, but rather, how female aliens are portrayed in older sci-fi games and shows.

I nearly called them Orions in a nod to both Star Trek's Orions and the name of Master of Orion, but realized that there's already another race called Morions, and it would be only a difference of one letter.  So I'm going with GSSB which stands for Green Skinned Space Babes.  However, I'm open to suggestions for other names.

This race is equivalent to Master of Orion 2's Elerians.


Thursday, July 3, 2014

Pudelhunds, Linux, and C++, oh my!

Good news, everyone!

Laszlo (the Linux programmer) and I investigated different approaches to C# and C++ that would be cross-platform.  C# was a major pain in the butt porting over to Linux (I couldn't even set up the Windows version of the test program that Laszlo threw together for Linux).  So we felt that even if we manage to get it working, it'd detract many potential contributers away with over-complicated setup requirements.  So we decided to look at C++ alternatives.  Laszlo found a very good alternative, SFML, that is almost identical to the Gorgon engine that I was using in terms of framework and way it handles things.  The only thing missing is word-wrap functionality.  We're currently looking at a third-party GUI library, but if it don't work out, we'll add the functionality ourselves.

I've created a test SFML branch to test various features that will be required for Beyond Beyaan to work (shaders, image manipulations, text drawing, etc).  Both Laszlo and I was able to run the same code on both Linux and Windows.  So once we've finished investigating the GUI library, we'll start converting Beyond Beyaan into C++, and also test on Mac.

Ivan Kravarscan has also offered to join in the development efforts, so please welcome him!  Also, I'm giving Arpad access to post posts on the blog, so expect to hear from him from time to time.

Last bit of news, the artist finished the Pudelhunds race artwork (They're the Gnolams equivalent).  Here's a preview!  They're mafia-esque, with ships inspired by old popular mafia cars used in Chicago.  Yes, the pudelhund in portrait is holding a tommy gun :)