Avoiding Research as "Overpowered Trait"

Quick update on the development side: I'm almost done adding Sliders to the new UI system, and is currently working on having "Screen within screen", where you can refer to another screen inside a screen to reduce typing.  For example, planet information display in both selected system display and planet list display.  After those are done, I will look into coupling C# scripts with screens, so you can specify which script file works with which screen, and have them share data.  This will allow you extra features such as screen transitions, space combat, etc.  When all of those are done, the bulk of new UI system will be done, and I can finally finish the Galaxy Generation screen.

Now, for the topic -

If I were to ask you which race was the best one in Master of Orion 1 or 2 (without customization), the obvious answer is Psilons.  Why? I mean, they're nerds, don't really have any other advantages in MoO 1, and has disadvantages in MoO 2.  So how are they so powerful?  The answer is that those games emphasizes technologies.  Other aspects in empire management don't affect your empire as much as technologies do.

Here's my approaches that I feel will balance this issue without nerfing the technologies' importance.

1. Production - Whenever you build a technology item, you automatically generate a certain amount of research points in a similar technology.  For example, if you build 100 laser cannons spread across 20 ships, you obtain Gatling Laser technology.  This is similar to real life.  Often when we build stuff, we also seek methods to improve how we build the stuff, reduce costs involved with building, or improve the quality of the stuff that we build (look at our cars for example, they're continuously being improved).  But the caveat is that production won't help you in a new technology field.  So building insane amounts of laser cannons won't obtain you the plasma torpedo technology.  This is to put the production-based races on par with the research-based races while still requiring some effort to research.  The amount will be randomized, and the tech tree randomized as well, so it'll be different each game.

2. Spying - In many 4X games, spying is weak, and is mostly to annoy other races.  Not often that they dramatically alter the outcome of games, unless it's to obtain technologies.  Again, note the importance of technologies?  For Beyond Beyaan, I want spying to be something that is worthwhile, and something that you'll want to invest time in about the same with research and production.  But how to do it?  Well, I'm going to add ability to target specific technologies to try and obtain it.  So instead of random draw of luck, you first scout out what technologies they have, then set bounties on each technology that you want.  You also set security funding on individual technologies (so you can put a lock down on Death Ray technology, but ignore the obsolete +1% Terraforming).  There will be technologies that improves the efficiency of your security funding.  Same for planets, ships, etc.  You can try and blow up their Death Star with your spies, but ignore their fighters.  Or try to incite revolt on a certain productive planet to cripple their economy.  In a nutshell, you micromanage the spying and defense, making them about as equally important as production and research.

3. Diplomacy - For diplomacy, most games basically make a diplomatic-race have good relations with other races.  But what I want is a intrigue-infused political system where you can play games with other races.  Beyond Beyaan will raise events, and those events will open up conversation options with other races.  For example, if your spy blew up a missile base on a race without getting caught, you can talk about it with that race, and your options would be something like "Haha, your defense sucks" (lowers relation without arousing suspicions), "Oh, I'm sorry to hear that, here's some money to help you rebuild it" (improves relations despite it being you who blew it up in the first place!), "I think that race did it, here's some evidence!" (can either impact your relationship positively or negatively, depending on your diplomacy skill).  Also, most of the conversation options that you see will be story/lore options that has a random modifier.  For example, asking about their race's history may improve your relations, and at the same time infuse story in the game.  Or maybe asking about their opinion of your clothes will negatively impact the relations.  As you converse, options will be opened up.  So instead of immediately opening up a trade agreement like in MoO 1, you have to converse with them before that option is even opened up.  The diplomacy perk will allow you to see what an option's impact on your relation will be, otherwise you'd be guessing.  So being diplomatically inclined allows you better control in politic scheming, which can be very valuable.

4. Economy - Another aspect that's largely ignored is economy.  Most games it's just a simple "Oh I have this amount of money, I can boost production or buy/finish this ship".  Anyone played as Gnolams and used their trade to win the game?  I didn't think so.  My approach is to have economy impact your military and production.  How does it impact them?  Let's say that you're not producing enough food to feed your people.  Let's say that you're farming about 25% short of what your people need to eat.  Instead of just them dying off, their production drops by 50% (double the shortage), which in turn drops income by 50%.  Let's say you have 100 upkeep, and 100 income, dropping by 50% means that your ships and ground troops perform 50% as effective due to defective/broken parts, insufficient fuel, etc.  Your weapons will do 50% damage, armor absorbs 50% of their normal rate, and so forth.  There will be a minimum efficiency, but the idea is that having a bad economy is not a minor inconvenience.  It will IMPACT your empire and your ability to fight.  If you just lost a planet that supplies 20% of food to your 100+ planet empire, well, crap, gotta fix that or you'll suffer.  If you lost a tourist planet that supplies 30% of your income, it will hurt.  But if your economy is in excellent shape, surpassing all your population's needs, they actually get bonuses.  Let's say you have 125% of what your people need to eat.  It means they reproduce faster, work more, research more, etc.  There will also be an upper cap on bonuses.  So with this in mind, destabilizing another empire's economy is now a viable strategy.  Instead of destroying all planets, just target those planets that supply the empire with food/money, and presto! their military is weakened, ready for you to attack them!  Spies will also play a part in this.  You can offer or receive empires loans or food supplies, and you can also have the option of declaring bankruptcy if you're in red, which will impact your relationship severely but helps stabilize your economy.

Now with all of those, suddenly specializing in research isn't so overpowered because other fields are now about equally as important!

--------------------------------------------------------------------------------

Another problem that unintentionally caused research to be overpowered is the shields in MoO 1/2.  They basically cancel a part of the damage.  This can imbalance the game because weak weapons are no longer effective in later stages.  Think of a tiny ship with Shield X, and 1000 ships with basic laser that does 5 damage.  They can't kill the tiny ship because Shield X simply cancels 10 damage before starting to absorb damage.

For Beyond Beyaan, I'm doing the shields and armor a bit differently.  Both Shield and Armor will have "Resistance" threshold, with Armor averaging higher.  If resistance threshold is surpassed, the damage is passed on to next level.  However, both shield and armor have a limited amount of "HP", that if 0, they stop resisting and allows all damage through.  So a Shield I absorbs 1 damage, and have HP of 10, it means it takes 10 hits before it stops absorbing.  There's no damage canceling.  A powerful weapon can punch through both shield and armor, while a large number of weak weapons can whittle them down.  This way, you can still use weak weapons effectively (swarms of fighters for example) to attack a powerful ship.  You also can have layers of shields (three shield generators for example) to shield your ships.  The idea is to make the combat feel organic instead of a number-crunching game.  I want to avoid "Min-Maxing" where there's "The One Ship" that can handle everything.  An enemy built an ultra powerful Death Star?  Make massive number of boarding ships and attempt to take it over.  An enemy built thousands of tiny fighters?  Build ships with powerful area-of-effect weapons that easily destroys small ships, but is weak against large powerful ships.  And so forth.

Nurds!

My artist finished the portrait of Nurds, as well as some of the ships. (How it works is that he creates the portrait and some of the larger ships, I look at it and see if the ship style and portrait need tweaking, then he finishes the rest of the artwork).

Here's what the portrait and one of their ships look like (think retro 50's spaceships!)

Things has gotten busy recently, but hopefully in a week or so I'll be able to work on the game.

Shader and Shader Values working!

I know that this probably isn't very interesting to most people out there.  But for modders, this is important!  For stars in my game, they are colored using shaders.  While others may just create different sprites that already have colored stars, I use a greyscale star, and replace each shade of grey with the correct color using a shader.  Same for ships (replacing certain red shades with empire colors for example).  You can see in my last post that the stars drawn are grey.

So I went ahead and added support for shaders in the new UI's images.  I also added camera control to the "CameraView" UI Type that allows you to zoom in/out, and move around, and define the thickness of borders in where it start moving around.  So for now, that part of the galaxy setup screen is done!

Just one more step, that is loading in another script's UI...  Anyway, here's a screenshot of shaders and camera view in action (well, not animated, but you get the idea, it's zoomed out and I moved camera to left and down.  Note the colored stars, which proves that shaders are working correctly):

Since I'm just getting the new UI system to work, the UIType class is one huge class.  I plan on breaking it down to smaller classes after I'm done with the whole thing.  So for programmers out there, pardon my klunky code.

Oh, the "code" for this screen?

Yeah, 21 lines of goodness to generate the above screen!  Starting to see why I'm excited about this?  See how the galaxy preview part is just 5 lines, defining how each star is drawn?

Getting there...

This new UI system is a lot of work, but in the end I feel that it will be worth it.  I've finished fleshing out the drop-down UI type, so that it properly displays and handles both dropped and non-dropped states, as well as interacting with the game when something is selected.

I'm also working on getting star systems to work with the new UI system.  I added a new UI type, "CameraView", this will be used for certain types of objects.  CameraView supports moving, zooming, etc which isn't implemented yet, but that's the idea.  It will be used for galaxy preview as well as space combat.

Here's a screenshot of current version of CameraView (note that galaxy is generated via the new UI!), no shaders, no scaling, no zooming, etc:

What this means is that you can have a galaxy preview inside a screen, maybe planet list screen to show its location, or whatever you think suits your purpose.  There's a lot of work to be done still...

Data working!

The UI now can get its data from game code!  This is big!  This is huge!  While this feature is limited right now, I can easily expand on it in the future to add support for other features.  I was worried for a bit there on if this is even possible, but now with that out of the way, I can easily create new screens and windows a LOT faster than before.  No more worrying about handling mouse events inside a screen (lots of duplicate code there).  I just specify XML files and the game handles the rest!

Here's a screenshot of the galaxy setup screen that I'm working on.  The drop-down on top right contains the list of available scripts that the game code found in the scripts folder.  This is not hard-coded at all!  It's all loaded from a XML file!  The "Cluster Galaxy" text that you see is actually a screen inside another screen, so you can create unique UI (dropdown that contains pictures and text for example).

I plan on expanding this more!  There's two more features that I need to add to the new UI system to finish the Galaxy Setup screen:

Ability to retrieve list of star systems and display them using sprites referred inside the star system class

Ability to load UI from inside a script file (galaxy scripts allows users to specify certain parameters, such as number of arms)

Once those's done, I will chuck out the old galaxy setup.cs file!  The first feature will be the hardest, but if done, will give modders powerful ability to specify how stars are drawn.  For example, draw a name above a star, or below it? Or even on the side?  Fleet icons?  Extra fluff UI to make it look nice?  Draw small planet icons around the star to show its planets? Etc...

UI and Data

Building an UI system that allows you to interact with the game's core mechanisms isn't easy.  It's easy to create a system where you can place buttons and other pre-defined components if the game is looking for them (i.e. hardcoded buttons that you can only specify their location and size for example).  However, the system I'm aiming for is to allow you to control more than that.  The game isn't expecting any particular UI, it only have list of events that can be called from the UI, and a list of functions that can return data.  The tricky part is creating the connection between the UI and the Data.

I originally picked C# because I liked its layout.  Now I'm especially glad that I chose it.  The reason is that while looking for a method of getting a variable name that's hard-coded inside the program, C# have a relatively simple method of doing this!  So I've created a test function that checks to see if I can actually retrieve the values of properties that I'm looking for inside a list of returned objects, and it worked!

Edit: Arg, it ate the greater than/lesser than brackets, so replaced those with () instead (all (T) uses those brackets)


public void FillData(T)(List(T) values, GameMain gameMain) where T : class
{
foreach (T t in values)
{
string value = t.GetType().GetProperty("GalaxyScriptName", typeof (string)).GetValue(t, null).ToString();
}
}


Basically it tells the function T is a class, and contains members.  Then it loops through list of instanced classes (in this case, GalaxyScript class that only contains one string member, GalaxyScriptName) and retrieves the value of the "GalaxyScriptName" property from inside the class.

What this means is that I can return a list of ANY class (StarSystem, Planet, ShipDesign, etc), and this function will work with any of them!  So I can populate UI with data!  However, this is just 1/3 of the work (yet it's the most critical part)!

The other 2/3 is setting up a way where the game recongize that the UI wants certain data, and provides it with those data, and having the UI fill in its controls with those data.  I've already set up a way for UI to tell the game it looks for a certain data (I'm currently in process of converting GalaxySetup screen to the new UI system):

in XML file (blue text is the UI telling the game it's looking for certain data):

Edit: Same issue as above, replacing with ()'s

(UIElement name="GalaxyDropDown" UIType="DropDown" OnSelect="UpdateGalaxyScript,[GalaxyDropDown]" DataSource="GalaxyScriptList" xPos="XMIDDLE+130" yPos="YMIDDLE-275" width="250" height="35" arrowxoffset="10" arrowyoffset="10")
    (Template height="30")
      (SubElement UIType="Label" xPos="10" yPos="5" content="[GalaxyScriptName]" /)
    (/Template)
  (/UIElement)

 

When the screen is refreshed, it sees that one control has a valid "DataSource" attribute, and tells the game to go get the required data as per this function:


public void RefreshData()
{
foreach (var uiType in UITypes)
{
if (!string.IsNullOrEmpty(uiType.DataSource))
{
uiType.FillData(_gameMain.GetData(uiType.DataSource), _gameMain);
}
}
}

So the UI part in letting the game know what it needs is done.  Now for the last 1/3rd part, getting both to actually work together.

Notice the "Template" element in the XML section above?  It basically tells the game that each row inside the parent UI follows this layout.  It can define its size, the child controls, etc.  Each row correspond to each class retrieved from the DataSource.  So if there's 4 galaxy scripts, the drop-down will have 4 options, each corresponding to one script.  Each row will have a simple text as indicated in the Template element.

The Template part isn't implemented yet however.  I'm trying to think of a good way to bind the attributes of a control to a class (If you're familiar with WPF and XAML, you can get ideas of what I'm trying to do here).  Hopefully soon this part will be done as well.

Recent Build Updated to 0.1.52

I've added event handling in the new UI system.  It's pretty basic at this point, but I hope to flesh it out in the future.  This new UI system has already gotten rid of one .cs file, namely the "MainGameMenu.cs" file!  In the future, I plan on removing the Screens directory totally from the project, and replacing them with Screens directory inside the game's data directory.

Changing screens when screen don't exist in the new UI results in this error message:

Right now, there's a command "UseOldScreenSystem" that when called, switches over to the old screen system for Galaxy Setup.  When I convert Galaxy Setup, it will change over to Players Setup, and so forth.

I've uploaded the new version to Desura's "Recent Build" (0.1.52) that includes those following items:
New screen UI system
New mouse cursor
New game launcher
Added License.txt to clarify licensing stuff

Check it out and let me know if you still have mouse issues or find any other issues.  Thanks!