XCOMRL

Interfacelift

by Kyzrati on 20111213 , under ,


It's been a surprisingly long time since the last post. Sorry about that. Not that nothing's been happening over here, but I prefer having something concrete to show with every post. I'm still chipping away at the todo list, but the current stage of development involves spreading out into quite a few new areas of the game code, certainly much more time-consuming than banging out simple and well-documented game mechanics!

Plus, I don't want to screw something up now in the core program that'll become a source of endless headaches later.

Recent developments have been all about paving the way for a new interface. The HUD is still waiting on the sidelines, mostly because I have yet to decide what exactly it should contain and how to organize it all. Instead I'm testing the system by implementing a simple inventory window. I know your soldiers are getting antsy about the fact that they just *know* they have more ammo in their backpack, but, um... forgot how to get it :)

Well, now they'll finally be able to stock a few extra grenades and missiles, and do it in style!



Okay, so it doesn't look like much yet, but look again... it's alive!



The system is capable of far more than you see here. This sample is powered by a simple, generic window-drawing script; the interface animations are completely exposed in text files, similar to the weapon particle effects. So, just as you see weapons producing a range of snazzy effects, windows can do all that and more, and can be tweaked, or even rewritten, from the text files. (For those interested in the dev aspect, the system is very basic but powerful nonetheless: every visual component of the engine (window/control/button/etc) inherits from the same console base class, and every single one comes with its own lightweight particle engine--I LOVE PARTICLES! Besides making it not too difficult to implement good-looking effects, giving every object its own particle engine also makes control/manipulation fairly easy: even windows containing complex interconnected animations can be manipulated piecemeal and the flow seems to work almost automagically!)

In the game you won't have to watch entire windows be redrawn every time they're accessed--the way I have it now only the content portion will be redrawn after seeing the complete animation once (per run).

In its current state, the inventory screen should already be pretty informative and usable, showing TU costs, weight/encumbrance changes, highlighting valid/invalid targets for moving items or reloading, and telling you exactly why you can't do something, etc. It'll be expanded later on with additional functionality like the ability to define and apply set loadouts/equipment kits, and direct manipulation of other units' inventories (tanks that hold things, or those with modular weapons that could be swapped out by an engineer?).

In terms of control, the inventory is 100% controllable by obvious and intuitive keyboard commands. I used the mouse in the video so you could better understand what the heck was going on...

I originally thought the inventory interface would be a bit more graphical, but that wouldn't be as compatible with the new arbitrary inventory slot system. Armor and inventory slots have now been completely exposed in the text files, enabling simple creation of different kinds of armor which provide unique amounts of storage space and locations. Races are also connected to the slot system (also through the text files), so different races can specify different natural slots (which combine with armor slots to give a unit's total inventory layout). As each unit keeps track of its own available inventory slots, eventually adding the possibility of losing a limb won't be too much trouble (it'll still require a more specific body part list, though, which would also be compared against armor to make sure a given armor is usable by a certain unit at all).

Soon/next I want to finally integrate some sound effects into the particle engines to see how that should work with the animations. Hopefully those windows will be bleeping, blooping, whishing, and whooshing in no time. The audio engine is already in place, I just have yet to put together the resources and add ways for particles to trigger sounds.



8 comments more...

8 comments

  • Jaunmakenro

    Whoaw ! It seems as fancy as useful ! Knowing how a poorly designed interface could ruin a great game (Dwarf Fortress I write your name...) I could only cheer you to speed insane amount on time on designing it !

  • Kyzrati

    Yeah, I wish DF had a better interface, since entering commands can be a huge time sink, but I still voted for it over in the Roguelike of the Year competition. Show your support for X@COM and put in a vote! X@COM certainly isn't roguelike of the year, but it can't hurt to raise awareness! Check out all the other entries, too!

    I'd love to spend more time on the project, but I'm so busy these days it's really quite annoying. If only I'd started X@COM a couple years back--I used to spend at least 40~50 hours a week coding for fun!

    As for the UI, I'm going for both maximum usefulness and cool factor. Just finalized the R5 TODO list yesterday, and it'll be mostly about interface improvements.

  • Kyzrati

    Haha, I had to put the video to something since the UI sounds weren't in yet! (Didn't have anything else "tech" enough...) And you're right, the UI scheme certainly does fit the season.

  • Canageek

    Oh, I'm liking everything I see here. Have you considered using multiple console windows if the player wants, so that they can have a UI window and a battlescape window? It seems like it wouldn't be hard, if you have everything modular anyway, and it might ease the UI design, as they aren't locked to the same dimensions.

  • Canageek

    Oh, forgot to mention: The other idea I had there was you could decouple the font sizes: Have a nice large, legible font for the UI window and a smaller font for the battlescape so that you can see more at once. This would also let people fullscreen the battlescape in one window and put the UI in the other.

  • Kyzrati

    Individual subwindows won't be resizable, but there could be different orientations available, and in some cases smaller windows could be moved. However, SDL doesn't do true multiple windows, so all of this would be within a single game window. I'm definitely going with static game window grid dimensions--it's as is: 80x60.

    I have been thinking about muliple fonts, separating the UI and battlescape font, but mostly for readability purposes rather than size, since overlapping windows require that underlying console views have the same font cell dimensions, so that wouldn't be variable within the same game console. You can mix font glyph sizes, but the amount of space is constant throughout the console for a given font.

Post a Comment