I was actually planning to make a post anyway, so the answer is: Slowly, but going.
I don't know what it's like for other programmers, but for me the hardest part about making a game is the interface. Which, since you need an interface of some sort to do anything, is also the very first thing to do and has proved a deadly roadblock to my last couple of projects. This is really more of a console game problem, since a more 'graphical' interface that can make use of the mouse would be a lot easier to handle.
I think this is an instance where I've actually learned too much about design theory from my job. When you look at console games from NetHack on through Cataclysm, you realize that their interfaces are incredibly simple (a half dozen 'screens' at most with hardcoded buttons-to-effects) and could and probably were bodged together a little bit at a time and built right in the program's guts. I work for a company that makes webservice-accessed applications with C# internals - as such, if it's not modular and extensible, I can't even allow my head to wrap around it. Which, for a project that rests entirely on my own efforts, runs smack into my ancient problem of, "if its not perfect on the first try, it's not worth doing".
There's basically two ways you can make a console interface. The obvious is the hard-coded way, aka the easy and stupid way. Every 'screen' has all of its functionality built right into it as essentially a static object (if you're working with an objecty language), and your program is essentially a conductor shuttling you back and forth between screen-modes. This is great for building something basic and as quickly as anything in programming ever is, but turns into a big pain the ass whenever you have to expand the function of a screen, let alone make a whole bunch of interrelated ones.
The other way to make an interface is the objectified way, aka the mad pro skills way. This is the way that I have oriented myself into working, both because it's how I'm supposed to approach a problem like this professionally and there's no reason to fuck up my style, and also because I realized that just building out one main function of the game - assembling a unit from members, items, and standing orders - would require upwards of ten different interconnected screens with any number of buttons and navigable lists between them. This might actually be the hardest part of the project until I get into dynamic AI or something.
While I did spend most of the last week just jotting down notes about granular features and such, I finally put shoulder to wheel over the weekend implementing the basic elements of interface framework. Nothing to show until all the pieces click into place, but it's going a bit smoother than I thought it would. Mainly because I'm recycling and updating some concepts I last used (and abandoned) for my roguelike in October or so when I let the complexity overwhelm me. Since then I feel like I've hit my stride at work, and I'm itching for a challenge again.
Pointless details: the functionality of each screen will still be hardcoded into it, in terms of what each key-binding does (like fuck am I going to bother with remappable keys for now) and where stuff is drawn on the screen, but all the buttons and lines and lists and whatnot will be repeatable dynamic objects I can add/remove/toggle with ease. Screens can be backed out of and remember the settings of the last screen you were at all the way back to the main one, buttons light up by situation, and text can be oriented abstractly without worrying about the page design. At least, that's the operating theory because I can't actually see any of it in practice yet. But it's getting there, and not bad for how little time it's actually taken so far.
By the way, before anybody suggests it I am doing all this with Libtcod because the console sucks balls, and I am aware of Libtcod's mouse support. I don't anything about how to implement it though, and while that would be a great feature I'm not going to worry about it until I think it's worth the effort.
So yeah. How it's going is, I am ass-deep in gritty details wrestling with the skeleton of an interface, but it's putting up less of a fight than every time before. Still confident here.
Author
Topic: Aqizzar makes a game (Read 15472 times)