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 :)

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.

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):

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:

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.

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.

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.

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.

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.

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 :)

Fleet Overview Screen done

The UI layout for Fleet Overview screen is done.  I just need to hook up mouse events and add a dialog for confirming of scrapping ships to both Fleet Overview and Fleet Specification screens, then I'm moving on to Diplomacy and Ground Combat.  After which there'll be only Space Combat and Random Events left, along with general bug fixing, UI tweaks, and minor feature implementations.

The discussion on cross-platform and what to do is still ongoing.  We've discovered that OpenTK works pretty well (Remember the ReMoO project that I started a few years ago?  Laszlo was able to run it after simply updating references in MonoDevelop).  So we might stick with C# but convert to OpenTK.  We're determining which of the two choices (C++ and 2D engine, or C# and OpenTK) we should pursue at this point.

Finally, here's a screenshot of the Fleet Overview:

The idea is that you can click any fleet, and it'll take you to that fleet in the galaxy view.

Fleet Specs and Git

We've got several exciting news!

Arpad invited his friend, Laszlo Gerecs, to help with the programming aspect of Beyond Beyaan.  Laszlo is a Linux developer, and we're currently discussing what direction we should take with Beyond Beyaan.  I believe that we will convert it over to C++ for easier crossplatform development (Linux, Windows, and Mac), but the discussions are still ongoing.

We've also decided to move the source over to git, so from now on, you can find the source code and assets from here: https://github.com/Beyonders.  We will clean up the source files and assets so they match open source format (Assets will be in their own repository, with source code separate in another repository).  You may notice that we have "Mono".  This was an attempt to see if Mono is feasible for our crossplatform goal, but turned out to be difficult to set up.  Hence our discussion if we should go the C++ route.

The code will still be on SVN at google code, but it's depreciated and won't be used anymore.  It's there for reference (I still have the UI XML and other nifty features that I ripped out in there).

I also worked on Beyond Beyaan a bit, and finished up the Fleet Specs window, the one where it displays if you're trying to add a new design but you have six designs already.  Here's a screenshot (For reference, the old one is seen here):

Plan for Beyond Beyaan

It've been a while, but it has been a productive month in terms of design tweaks.  Arpad and I has been discussing Master of Orion 1 and its good and bad aspects.  Arpad helped illustrate the flaws in AI, and after he explained them, I tried a new game on Impossible difficulty.  If you recall, my last attempt failed disastrously.  This time, I'm effortlessly crushing the AI.  I now feel dirty knowing AI's exploits, Impossible is no longer "Impossible".  Our plan for AI is to have AI be actually smart, and reduce AI cheating as much as possible.

So our goal is to not exactly replicate MoO 1, but take the best and improve on the bad.  With mostly input from Arpad, the following are list of changes that Beyond Beyaan will have:

Space Combat - The map will be a hexagonal grid.  This is to improve logistics for missiles/torpedoes, minimize distance discrepancies, and generally balance things out.  This is mostly to help the AI.  It will still be vertical columns of tiles, so it shouldn't differ too greatly from original.

Diplomacy - All races start with neutral relation toward each other.  This will help boost the weaker races (Mrrshans, Alkari, and Darloks especially) while not weakening other races (Humans will have different bonuses as explained below)

Personality - AI won't have "Leader Personality" like in MoO 1, they hurt more than help the AI.  So each AI will factor in their race's strengths and act on them, instead of trying to do something counter-intuitive.

New Races - Since Kickstarter has resulted in success for the three extra races, Arpad and I discussed back and forth on how those will fit in a MoO 1 universe.  We have tentatively set forth their attributes as explained below.

Leaders - Likewise, I promised leaders in Kickstarter, but how to retain the simplicity from MoO 1?  Arpad suggested that they be a random event, with a randomized duration.  I liked this idea, and we fleshed it out.  There will be 22 different leaders, revolving around 11 different attributes that can help or hinder your empire.  For example, there are two financial leaders, one good, one bad.  Good will add a certain amount of income, while bad will reduce amount of income.  You cannot hire or dismiss them.  Each leader only have one attribute that they improve/degrade.  It's possible to have multiple leaders at the same time, based on random event roll.

Both New Races and Leaders will be checkbox options that you can disable when starting a new game, if you do not like those features.

We discussed extensively on how to balance the races in MoO 1.  Psilons, Meklars, and Klackons were the strongest, while Mrrshans, Darloks, and Alkari were the weakest.  We wanted to balance them, but still have each be unique from other races.  We've settled on the below (Left is the original bonuses/attributes, if it don't list a technology field, it is "Average", on right are the Beyond Beyaan's version of the race).  This is subject to balancing and testing, but we feel that this will even things out and still retain an interesting gameplay.  Also the new races were problematic, but hopefully they are unique enough with the listed attributes.

If you have concerns or suggestions for any of the discussed features, please let us know in the comments!

More work on Planet List

The planets' economy system is nearly done.  Planet List screen is almost done as well.  The only remaining features is to implement infusing a planet with reserves to boost its production, and the dialog for it.

After those are done, I will re-do the Fleet Design List window and implement Fleet List screen.  As well as bugfixes and minor tweaks.  At that point, I will upload a new version to Desura.

Here's a screenshot of my progress, note the new taskbar at bottom.

Zygobies race artwork done!

Last fall/winter, I had to put hold on purchasing artwork due to financial constraints.  But things are better now, and I've commissioned my artist to do the 10th race, the Zygobies.  The results are fantastic!  The original description from kickstarter are as follow:

"Spores that has taken over various hosts, often without hosts noticing it, as their personalities and thinking are gradually altered. They are excellent spies for this very reason, and are heavily mistrusted, because you never know if some of zygos has rubbed off on you. Their society is a pure meritocracy, with ranking based directly on the host's brain mass as their intelligence is limited by the size of the host's brain. Despite their name connotations, they are very cunning and clever, not to be trusted."

The concept is that they conceal their host's bodies, so that others won't know which species have fallen under Zygobies' control.  They are master spies and don't care what methods they use to extract information.  They also use stealth styled ships that are designed for speed.  With those in mind, here's a preview of the Zygobies!

We now have 10 races' artwork done!  I'm having the artist do space combat graphics now.  For those who don't know which race imitates which race in MoO 1, here's a quick recap:

Humans - Humans
Nurds - Psilons
Zygobies - Darloks
Salix Cybornia - Klackons
Zero People - Meklars
Araneas - Sakkras
Velociraptors - Bulrathis
Pyrrhans - Alkari
Morions - Silicoids
Space Hamsters - Mrrshans

Later, after all other artwork are done for making a complete MoO 1 clone, I will then commission work on additional 3 races and leaders for MoO 2's version as per kickstarter's stated goal.

A Makeover

Arpad and I continue to test and improve the game.  One of the things I just did was to give the fleet window a make-over.  It now dynamically re-sizes based on the amount of types of ships in the selected fleet.  The scrollbar for fleet list is replaced by next/previous buttons that allows you to change between fleets if there's multiple fleets in the same point.

Here's a before/after screenshot of fleet view window:

Progress report

I sent my latest build to Arpad last week, and he gave me a list of bugs and issues that needs to be fixed.  I've been working on those, and also fixing some other bugs that I discovered.  There's now 8 code issues, 1 art issue, and 2 enhancements left in the list (not counting the "Other" category).  As soon as those issues are resolved, and I've finished the planet list, I will update the Desura build.  Then you all can submit bugs that you discover at https://code.google.com/p/beyond-beyaan/issues/list.

One of the issues I worked on is that ETA wasn't being displayed.  So I took time to implement it, and here's a screenshot of it in action:

Let me explain each of the picture.  Top left is the star being out of range for the colony ship which does not have extended fuel tanks.  Top right shows a scout already en-route, with 3 turns left to arrive.  Bottom right shows you being able to change destination, but since it's already en-route to the first star, it will have to continue there, then it'll go directly to next destination.  Hence two ETAs being displayed.  However, since it won't stop at the first star (it will simply continue to next star without stopping there for a full turn), it won't explore the star.

This latter is very useful in cases when you have ships retreating, and you want them to reroute to another star when they're already en-route, this allows you to make orders without forgetting about the fleet.

Hyperspace communications will of course simply change the route to be direct to the new destination.

Space Scanners Implemented!

I realized that I totally forgot the space scanner part of the planets!  So I took time to implement them, and to fix up issues related to it (such as able to select invisible fleets, seeing other fleets not in range between turns, etc).  I also even added a scanner range visual indicator, by pressing "R" (similar to Fuel Range's "F").  I changed the fuel range to be green, instead of empire color, and radar to be red.

Here's a screenshot with me using Deep Space Scanner technology.  Note, fleet's radar is actually centered at the system they're in, otherwise they'd be centered on the fleet.

Announcing the AI Developer

For those who've been worried about the AI for Beyond Beyaan, worry no more!  I am now joined by a Dr. Arpad Kelemen, who specialize in AI.  Let me introduce him:

"I am the #2 designer and developer of reMaster of Magic, which is the latest open source attempt to revive the best turn based strategy game idea of all time – Master of Magic. Master of Orion 1 is #2 on my list. I am a computer science PhD who is an extreme Master of Orion 1 fan since it came out. I am also a funded academic researcher who leads developments of computer games that involves programmers, doctoral students, and faculty at an American university.  My Ph.D. was in AI theory and AI software development. I published many scientific papers and books on AI and taught AI courses at a university."

Right now, he is assisting me in testing my game and giving me feedback on bugs and things that needs improvement.  When the game reaches a stable state, with all the rules frozen and bugs fixed, then he will start development on AI.

Please welcome Dr. Arpad Kelemen!

Planet code ~95% done!

Yes, you read the title right, the planet's code is about 95% done!  The remaining 5% is for minor stuff like adding to list of notifications the player gets when starting his next turn, bug fixes, stargate which isn't implemented yet, planetary bonuses being applied, and number tweaking.  Now I'll finally go back to the Planets List screen and finish it.

The following has been implemented:

Factories, with robotic controls and refitting

Environment, with pollution cleanup, terraforming, atmospheric terraforming, soil and advanced soil enrichment, and population growth (yes, you can actually generate waste now, and reduce max population)

Missile bases and shields, including upgrading older bases (Yes, missile bases factor in your available technologies when determining how much it costs)

Display text for each of the field to correctly show what that field is working on ("Building Shield", "Atmospheric Terraforming", etc)

Matched the planet type generation to MoO 1 (such as higher chance of hostile planets at blue stars, etc)

Matched the planetary bonus generation from MoO 1 (even though their bonuses are not actually applied yet)

Matched the star type generation percentages from MoO 1 (Such as 25-30% chance of having red star, etc)

Fixed some crashes that I came across.