Pre-Order the Game!

Desura Digital Distribution

Tuesday, May 7, 2013

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.

Friday, April 26, 2013

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?

Thursday, April 25, 2013

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...

Thursday, April 18, 2013

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...

Wednesday, April 17, 2013

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.


Sunday, April 14, 2013

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!

Saturday, April 13, 2013

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!