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!

Cursor

Some people reported their mouse position being off even after my mouse update.  So I decided to hide the window cursor and have the game draw its own cursor.  This is just a quick report so you know I take your bug reports seriously.

Still figuring out how to handle events for UI, should have it set up soon!

Main Menu using the new UI system!

After much sweat and tears, I've gotten the framework of the new UI system working!  What you see below is similar to the original Main Menu, but it's now using the new UI system.  I've removed the Options and dataset drop-down because those will be handled now by the launcher.  I haven't gotten it to work with the rest of the game, so right now it's stuck on that screen alone.  Once I get this screen to work with rest of the game, I will update the Desura recent build so you guys can give it a try.

It does process mouse events, you can see the "New Game" is highlighted because I'm hovering over it.  When this is more fleshed out, this should help me progress quickly in terms of development.  To a player, the changes isn't really noticeable aside from a slight boost in FPS (it's more efficient on top of being flexible!), but to a modder, it opens up modding approaches that previously required tweaking in-game code.

UI and Velociraptors

The launcher that I added also does one additional thing.  It scans the install directory's data folder to see if there's any datasets that needs to be copied over to local user's application data folder.  If there are any, and none of them exists already on the local folder, then copy them over.  This serves two purposes.

First, with newer OS, modifying or creating files in the install directory in Program Files directory is a big no-no (security risks and all that).  So in order to have save files work, I've opted that the entire dataset is copied over to local folder first, then the game loads from that.  Saved files will be stored there.

Second, it allows you to modify the files without needing to create a backup.  Just modify the files in the local folder, and the game will not overwrite it with its initial data because it already exists.  If you mess something up, or don't like your changes, you can just delete the local folder and the launcher will just copy over the standard data.  You can modify the game's files in the install directory if you really want to, but to revert those changes you'll need a backup, or reinstall the game.

With that in mind, I started work on having the game load the data assets using the launcher's configuration.  On completion, I realized that some of the assets it's loading from are using hardcoded paths (fonts, certain graphic files, etc), and those are used in the main game menu.  The game reported errors when trying to start :(

At this point, I have two choices: Fix the hard-coded stuff so they point to the correct places, or start work on a new UI system that loads the screens from XML files which in turn loads images and resources dynamically.  I decided to opt for the second option for several reasons.

First, what's the point of having a 4X space game engine if you can't modify where or what the UI look like?  For example, MoO 1's UI layout is vastly different from my game, or MoO 2, or other games.  If you wanted to mod MoO 1 into this game, you'd have to change the game's code to accomplish that.  With this system, it'd be now possible to create a MoO 1 mod without changing any of the game's code.

Second, it'd reduce the time spent creating screens and windows, since all I have to do is modify the XML files, and the game will automatically handle it.  I can easily add screens and windows without having to declare them in code, then handling all the events, etc.

I'm taking it slow and will have both old and new UI systems running together.  I'm about halfway done with getting the basics of the new UI up and running.  After it's working, I will re-do the game main menu so that it uses the new UI system, but when you click on "New Game", it will switch over to the old UI screens.

The game will have a list of "events" or "actions" that you can attach to an UI element, allowing you to create your own screens.  In fact, you can create as many screens as you want, and have each link to other screens by "ChangeTo ScreenB" commands.  There will be some hard-coded stuff, such as galaxy rendering, space combat rendering, that you can call in your UI screens.  By those I mean, you can tell the game to "DrawGalaxy" in a window that's 500x500 big, instead of the whole screen.

Right now, I'm just trying to add simple buttons and event handling for those.  But when I get those working, other UI elements should fall in place.  Also, this new UI system uses the new sprite drawing system.  So those two will eventually replace the old UI system and the old image drawing process.  I won't convert everything at once.

Also, my artist just finished the artwork for the Velociraptors!  He will work on Nurds next.  Here's a peek at one of the Velociraptors' ships:

Launcher

While working with some other stuff in the game, I keep running into certain stuff, and finally decided to create a proper launcher where you can select resolution and if it's windowed or fullscreen, and which dataset to use.  With this, you can create a total conversion mod that have its own title screen and such.

The resolution/windowed/fullscreen options are working, however the dataset selection is not yet.  I'll need to re-write the data loading code to work with the new launcher, but in the end, it should be a lot cleaner and less cluttered in code!  As soon as I'm done with this part, I will update the Recent Build branch, maybe next week.  This weekend will be a busy one for me!

Here's a screenshot of the launcher in action:

Concept for Planet Management UI

One other thing about regions that's been gnawing away at me is the "consumption" part.  While it makes sense in the real world that producing something must consume something (i.e. consuming wood to produce lumber/books/etc), does it make sense that you as the galactic emperor should concern yourself about those details?

"Your Highness, report came in from Region IV of Planet VII of Obscure Star!  They're complaining that they're not getting enough copper!"

"Very well, which regions have excess copper?"

"Region II of Planet I of Obscure Star Two does, sir!"

"Alright, let's send them there."

You're an emperor, not a logistics officer!  So I'm going to follow MoO 1's example and have each planet be self-sufficient in that they should be able to provide for themselves (hence the whole purpose of researching colony bases for hostile planets!).  This will simplify the resource model/system in Beyond Beyaan.

So with this change, I brainstormed about how fields should work.  In MoO 1, each slider can accomplish multiple tasks.  For example, DEF can build missile bases, but if you research shield, it builds that first instead.  Or IND with building factories or putting into reserve.  So each field can have a project, or just produce resources.  I like this, but what I don't like is the inability to change which project a field is working on.  If you see some enemy ships coming to your planet and you just researched Planetary Shield XX, which would you rather to do? Build 2 missile bases by the time they get here, or build half of the shield and have it do nothing when they attack?

I'm proposing that with the economy change, each field don't consume anything aside from a percentage of population's "Production".  If something needs to be consumed (i.e. pollution cleanup), have it be deducted automatically from that field's output.  If insufficient, then there'll be penalties.  If excess, then the excess contributes towards the field's current project.

You can select which project a field is working on.  As for what fields there will be in the game, I'm having six fields, they are:

Agriculture - This field feeds only the people in the region, and can also build agriculture improvements.  Excess food boosts population growth.

Environment - This field cleans up after population's production pollution, and can also build improvements that deal with pollution (such as automated waste processing and other stuff).  Also performs terraforming tasks.

Infrastructure - This field allows you to build general improvements to a region, such as trading port, tourist center, government buildings, etc.  If no project, production is "invested" and generates money

Science - This field allows you to build educational/scientific buildings, if no projects then produces research points.  So you have to trade off between building an improvement (a research lab for example) or contributing to current research.

Military - Can build military stuff such as garrisons, regional shielding, etc.  Garrisons and other buildings can boost defenders' chances of defending in ground combat.  Also can build defense platforms for space combat.

Construction - Large scale construction such as starships, stargates, colonizing a region, etc

Here's a concept art for the UI that I've created for managing outputs.  It's missing details such as region details, specials, etc, but I thought it'd help convey what I'm trying to say more clearly.  Remember that space restrictions will apply, so you can't just build everything in a region, and that you can change a region to specialize in one of the 6 fields (i.e. military region boosts defense bonuses and reduces upkeep of military buildings, for example)  Let me know what you think!

Last, but not the least, I've added a new branch in Desura, "Recent Build".  It's not as feature complete as the old version, but reflects my latest build.  So you can finally try the stuff I've been talking about!