So, those following the progress of Middlecrest have probably noticed I haven't updated the source recently. Actually, that's an understatement since my last update was... November (had to go back and look).

Most of the reason is due to contract work I picked up. I underestimated the lack of time I have to devote to projects outside of my day job, which technically is also another project I work on :) I get paid at my day job. I don't get paid to develop Middlecrest.

The other part of it is that the Middlecrest source code hit a brick wall.

I haven't been the architect of a large and complicated project before. I'm used to taking code written by others, sussing out how another organization's codebase works to do whatever update I am assigned to do, and getting it done. There is a world of difference between doing that and architecting the codebase yourself.

While the codebase is great at generating locations (caves, landscapes, etc.), it is horrendous at generating areas (provinces, which are groups of locations). The codebase wasn't nearly as extensible as I thought it was. I've devoted time to correcting the deficiencies in my object model and it has forced me to re-vamp the code considerably.

I will have a fix for the province issue soon. However, since the re-engineering was so extensive, the roadmap has changed. I will release the province generation code in a bug release (a stripped down version featuring just the province code) and add the old functionality and features incrementally, in future updates.

Hopefully, that explains a few things. Middlecrest is still in development, even though it is in fits and starts :)
I recently discovered the advantages of Lua while doing research and doing some reading regarding ToME development. I've known about Lua in name only, but hadn't taken a long look at it until I noticed how much ToME relies on it.

It's an interesting approach and I'm excited about the capabilities to embed scripting abilities into Middlecrest. I've always envisioned the core of Middlecrest to be a library (or engine, of sorts) and this seems to be able to push the direction of the project more into that realm. I can also imagine that as Middlecrest grows, the sheer amount of source to compile will become an unwieldy time sink.

I've identified modules to begin scripting. Transitioning the code into a model where Lua becomes the logic of Middlecrest and C/C++ becomes the engine/driver of the lua modules will take some time. And I'm not sure I will be masterful enough with Lua to be able to convert everything over and compartmentalize things the way I want. I'm not sure enough bindings and support are available for Lua and the language itself is a little wonky.

Bindings for Lua and SQLite seem to be only partially implemented for version 3 (the best I've found so far is a project at 0.7) and seems to require a dll (trying to stay away from Windows-only setups for easier porting... I've been successful so far!). Lua is really high-level and so I'm not sure I will have such a fine control over the program as I have with C and C++, which limits me and I've been unsuccessful at being able to call C++ functions from Lua (which you should be able to... but, I'm still learning Lua). Tutorials are sparse, although documentation seems fair but spartan. And Lua has some wonky aspects to it that are interfering with the learning curve, like having to call the rng function twice on Windows machines, else no random number generation. Things like the rng issue aren't properly documented and probably only known to Lua gurus (or hours of googling and a lucky hit).

All these things may mean the ideal set-up of C/C++ (driver/engine), Lua (game logic), SQLite (data) may be more hybridized (C/C++ and Lua as the engine/driver and logic, and SQLite for data).

May have to see if there are other embeddable and interpreted languages out there for C++?
One thing I definitely am not is a graphic designer. I've known (dated, even) graphic designers and people who do graphic design as a hobby. While I've learned a trick or two from them, that is about the extent of it. Tricks don't produce good design. My college art classes were a disaster, mind you.

So, here's the conundrum: I have a UI that I have to design with a somewhat limiting medium (ASCII). While some would say, "Dude, use something else, for chrissakes!!", I say, "Dude, development is a exercise in minding the quicksand". Said differently, I only have so much time I want to devote to certain aspects of design and implementation and I know that I CAN devote my time to learn curses. That's relatively simple for me to do. Also, non-ASCII graphics are a turn-off for some roguelike players. So, nyah!

Given this design decision, I've been reading some articles on roguelike UI's, coupled with my own experience of having to deal with user interfaces and those tricks I learned (yay, tricks!).

One article was rather interesting. Although, the article is somewhat crude, the ideas presented are worthwhile. Essentially, the article dovetails with many of my own thoughts on roguelike UI, regarding the steep learning curve. Many roguelikes have massive amounts of commands to memorize and it is rather frustration having to look at the manual every 5 seconds. I've never been good at memorization by rote, so having to memorize a billion key-bindings is no good for me. It makes me feel for the newbies.

Solutions )

So, any other interesting ideas/approaches to ASCII-based user interfaces?

May 2012

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 26th, 2017 07:15 pm
Powered by Dreamwidth Studios