Tag Archives: user interface

Closer To A Video

This is the Spacecraft Editing Screen as it stands this morning.  The grid is drag-drop, although all the component art is just gray rectangles at the moment.  The abilities and properties readout is to the right.
This is the Spacecraft Editing Screen as it stands this morning. The grid is drag-drop, although all the component art is just gray rectangles at the moment. The abilities and properties readout is to the right.

Yesterday I got the component and ship designer up to their base level with the new interface elements.  I’m very excited — this is a major step forward toward getting the game into a demo-able state.  I hope to have a video in the beginning of March, probably a week or so before we start any crowdfunding efforts.

One of the big questions I’m waffling on right now is how to handle ship construction, and especially launch stack construction.  Right now the game treats every spacecraft as a unique flower — when you design it, it is built and launched just like that.  There’s no design that’s retained to copy to other ships.  That’s generally OK for the spacecraft themselves, but it also means that the launch stack for each ship needs to be constructed along with it, and that’s just not fun — the huge rockets and fuel requirements to launch the spacecraft is a fun problem to solve once, especially when you’re  lifting something particularly huge, but I’m thinking I want to allow you to declare a spacecraft as a launch stack, and then simply have the system use it to send up the other ships and stations you design by automatically mating them together.

I’m going to think about it some more, but how ship designs vs. ships vs. utility objects interact is a UI issue that I’m going to have to put some serious thought into.

Interface Elements

One thing I’ve felt particularly dirty about while working on Slower Than Light is the amount of code replication I have.  I’m not talking about code I wrote; in order to get the interface to look right, I’m having to implement a control system that rides on top of .NET and replicates a fair amount of the functionality of the standard System.Windows.Form controls.  I have Text Boxes and Listboxes and Buttons and Labels and so on, and a carefully crafted series of rectangles and flags to handle redrawing them only when they need to be redraw, and so forth.  All of these things are done, arguably better than I could hope to do them, by the extant controls.  So what am I doing?

Part of it is that my earlier working with Mono, the cross-platform .NET implementation, sometimes gave me considerable grief with windowing.  I could count on having draw surfaces and control input work more or less how I wanted them to, but sometimes the controls would act differently on Linux than they would on Windows, which makes one-man support for a cross-platform product a nightmare.

The other part of it is that I could not control the art and appearance quite the way I wanted with the basic controls.  Being able to draw controls is one thing, but being able to rotate and move them when I need to without converting out of System.Drawing.Drawing2D and then back in is really nice.  I am quite sure when that art and UI design take the main stage in a couple months, I will be very grateful for the investment I’m making now.