Pre-Order the Game!

Desura Digital Distribution

Thursday, April 11, 2013

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:


3 comments:

  1. How much customization will be available in XMLs? Images only, layout, logic?

    ReplyDelete
  2. The goal is to give the UI as much access as possible. So for example, if I want to add a background image that stretches across the screen, I'd specify x and y pos to be 0, and the width and height to be "WIDTH" and "HEIGHT", which the game will translate to the game's resolution size.

    There are events that each UI can have. For example, button have "OnClick". In case of "New Game" in main menu, it'd have "OnClick=ChangeTo|GalaxySetup". ChangeTo is a command, and GalaxySetup is value, telling the game to change to GalaxySetup screen.

    I also plan on adding "Template" that a screen can use. For example, planets screen, each row uses a Template that are the same, but fills in information individually from a loop. So you can design nearly everything, using events and commands that the game provide.

    The UI elements themselves (Buttons, sliders, etc) are defined in another data file. So for example, if I want to use "New Game" button with certain graphics, I define those in the "UITypes.xml" file, with the images in "Sprites.xml", and finally put them all together in a screen.xml file in Screens directory.

    ReplyDelete
  3. Awesome ship. I can't wait to see all the game art together when it's ready.

    ReplyDelete