It’s been a busy/productive week in Black Future land, largely thanks to work easing off a bit. My friends keep whispering sweet nothings to me about getting a Steam greenlight campaign going, but I think that’s premature (and I’d probably need to think long and hard about licensing, since the project is GPL’d right now – but I haven’t taken any external contributions that would need assignment).
- Levers are now in the game. You can take a mechanism, and use it to build a lever. Levers have a bi-state display – they can show either “up” or “down” (this doesn’t make much difference yet; they fire events on change rather than providing an on/off – but it looks better).
- Selecting a lever gives you a menu item, Lever Settings. This opens a dialog showing what the lever is currently assigned to do, and provides a list of entities that can accept a lever command. You can add/remove items to the lever from here. Currently, you can attach to bridges, doors and spikes. Every time you pull a lever, each attached entity will drain some power from your energy banks. I’m still tweaking exactly how much (trying to find the right balance; you can generate energy pretty fast during the day, I don’t want to penalize creative designs – but I also don’t want it to be too easy. Trial and error time!).
- The lever menu also has a pull lever option. Selecting this adds it to the settler’s task list. I wanted to avoid the “Urist, why didn’t you pull the lever?” issues from DF, so I’ve made it a very high priority task: when selected, idle settlers everywhere will start sprinting towards the nearest lever. The first one there will pull it. I don’t have a “repeat” option, yet (it’s in my plans to make a separate “repeater” item for this, with some timing control).
- Your levers can be linked to bridges (build via the new architecture system). Levers toggle the state of a bridge between extended (fully walkable) and retracted (which visually removes the bridge, and makes it impassible). This lets you build a decent passive entry defense, control whether or not a river/canyon is crossable, but doesn’t provide the impregnability of a Dwarf Fortress drawbridge. I may support drawbridges later, but not until they are destroyable by angry mobs!
- Your levers can be attached to doors. The attached door will be locked/unlocked by the lever command.
- Your levers can be attached to a new item, retractable spikes (which are built at a primitive forge, from metal). Once you’ve placed your spikes, they default ot the retracted position. Send them a lever impulse, and they will extend – inflicting damage on anyone standing on them. You can link lots of spikes to a single lever, to make a user-controlled corridor of death.
- Started work on pressure plates, which are like levers but are triggered by an entity entering the tile (with various configurable conditions; you will be able to only trigger on hostiles, trigger on water, etc.). Also started putting in floodgates. I’ve started sketching out a few ideas for including some logic options (repeaters, not gates, and/or gates, etc.) to try and kickstart the creation of truly interesting machinery – but this is just in the planning stage.
- Implemented some food/drink clocks, but it was awful and I reverted it for now. Needs more planning.
- Considerably reduced log spam; your log won’t fill up with “Bob Jones is chopping down a tree!” or “Mercy Hope is doing some mining!” now – but you’ll be alerted to job cancellations, combat, etc.
- Fixed a stupid issue that was sometimes showing two status icons at once, leading to settlers wandering around with an indecipherable blob next to their heads.
- Improved the look of sand/dirt tiles. The previous tiles were too bright – they drew attention away from what was going on.
- Fixed an issue in which bridges were appearing as (number of tiles) entities, rather than a single entity.
- Realized that I really need a build system that doesn’t drive me crazy. The objective is to get automated Windows, OS X and Linux builds in a scripted, repeatable fashion. Spent a couple of sessions tidying up the build system, and getting scripted builds to work. It’s not as automated as I’d like, yet – I have to run the “ship” scripts on each platform, but they do the rest: git pull, compile, strip binaries, assemble dependencies and file structure, zip it up and place it on a server for distribution (see below!).
- Removed the dependency on Boost. This has been the #1 cause of confusion from people using RLTK, and it made the builds easier overall.
- Added scripting to auto change the displayed version to match the currently nightly build date/platform.
- The log window doesn’t display if there is nothing to tell you.
- Building and workflow lists are now sorted alphabetically to make it easier to find what you want.
- Fixed sizing issues on the workflow control window.
- Locked vs. open doors have different graphics.
- Implemented some game analytics, to give me a better idea of what’s going on in-game. It’ll be strictly opt-in for release builds, and opt-out for nightlies (they are really intended for my use!). I was in two minds about this, since I don’t really like programs calling home – so it’s easy to opt out (change
allow_calling_homein config.txt to anything that isn’t “yes”); I’d really like the data, though. It’s pretty primitive; a queue collects analytics events (such as “startGame” or “kill_other – deer”). A background thread periodically wakes up to send the queue as simple HTTP to one of my servers. The only identifying information is anything you choose to put in the
online_usernamepart of the config file – which defaults to anonymous. Events are stored in a database with a game start timestamp (which effectively uniquely identifies the session), version, event header and event details. It’s pretty simple to throw SQL queries at it from there to find out that in my last test session I built 3 buildings and 12 wall tiles, killed 2 deer, 1 settler died, and I played for a total of 4 minutes.
You can now get unstable builds from my build server. These are created by build scripts on some computers I have lying around; they are semi-automatic – I still have to issue the build command on each one. So they aren’t really nightly in the strict sense, but it’s a start.
These are unstable: poorly tested (they run on my test machines, but I haven’t gone through the task of making sure they run on vanilla PCs yet under Windows and Linux – all 64-bit; I’m having some library problems with the Mac build). As I get closer to a release, they will improve drastically. I really wanted to get something going to facilitate rapid releases, to let everyone see progress rather than relying on sharing saturday posts!