Collapsing the world, eating and drinking
Between a very heavy workload, and tax week, I didn't have a lot of time to accomplish anything enjoyable this week. This is definitely the one week of the year in which I hate being an independent contractor!
I did show off Nox to a Facebook indie-dev group, and the reaction was generally positive - with a few suggestions that I need to show more depth and less Minecraft-esque graphics. That's probably true.
There's a new build going up this weekend or Monday, with some enhancements:
- The collapse system I talked about last week is live, and working pretty well. Undermining things and then collapsing them with a lever is quite fun!
- Settlers suffer from hunger and thirst. 24 hours without food/drink triggers the "hungry" or "thirsty" status effect, which doesn't do much other than make them seek out food/drink on their next idle-time cycle.
- Implemented the "leisure jobs system". It's similar to the "work jobs", but you have far less control over what settlers do for fun!
- Settlers who are hungry or thirsty will find prepared food/drink and consume it, resetting their hunger/thirst clocks.
- Not eating or drinking for 7 days is very bad for settlers healths; it kills them faster than it should, currently!
- There is a bug (still not resolved) that makes replicated food show "plasteel" as the material; it doesn't affect them (other than making them hard to destroy), but I'm not sure that counts as tasty.
Finally, there is something for settlers to do during leisure time! This will be expanded in the coming weeks into a fairly broad set of ways to entertain your settlers, which is a natural bridge to the feelings and relationships system (and also the end of Phase 0!).
I've been meaning to do this for a while, and I'm getting to the end of "phase 0" (base mechanics) - so now is as good a time as any. The core gameplay (basically everything that isn't graphics or user input) is being pulled into a library, with a relatively clean API for connecting to an engine. Having both ASCII and 3D modes helps a lot here, in that I've already been forced to be relatively disciplined. This isn't something that players will see, unless I break everything - but it helps me keep things clean/tidy in the long term.
It also means that I can change back-end more easily if I want to (whether because my "I should have used Unreal" feeling becomes too strong, or just supporting Vulkan as a way to get OS X builds going again). It's also handy for test writing, and one-shot tool creation.
Some Unreal Learning
A friend (who works in the industry) sent me some resources on Unreal, so I figured I'd spend some time playing with it. It's quite the change of pace - you can do a lot with "blueprints" instead of writing code, and it's pretty easy to get going. It's very much geared towards mostly static maps (it's heritage as an FPS engine shows), but it didn't take too long to get some procedural content going. It didn't take long to get MagicaVoxel content imported, and throw together a blueprint that spawns a city grid with changing traffic lights.
It's also surprisingly easy to crash the whole thing!
(The partly baked idea for a game is that you are a cop (not corrupt!) in a cyberpunk-style town; it's your last night before retirement, and you are trying to foil as many crimes/plots as possible. Current working title is "Lone star: one night in the city". I'm thinking strict turn-based roguelike with lots of shooting. It may or may not ever be made... but it's fine for playing with engine features!)
Collapsing: an infographic:
Unreal engine streetlights test:
Not overly impressive, but not bad for a 3-hour learning session when the last time I fired up the Unreal editor was in the days of the original Unreal Tournament (I dimly remember porting one of my favorite Quake tournament maps). This is pretty simple; an actor spawns a 10x10 grid of blue print actors, each of which displays a MagicaVoxel model and some lights. It's my first dabble with procedural content in Unreal.
I was curious, so I fed the new generic graphics API into Unreal, via static-linking with `libnox`. Embarassingly enough, it has both a better frame rate and lower memory usage - and still manages to look pretty darned great. Here's an Unreal scene of the game! It doesn't actually play, can't build a world (it can only load an existing save) - but it's a fine proof-of-concept. It actually loads all the raw data definitions, uses the regular NF code to de-serialize the world, and passes geometry information (compressed via greedy voxels) through a simple API - so practically no new code was needed! I'm still figuring out how to do materials in a procedural way, so textures are kinda odd.
Leave a comment
Log in with itch.io to leave a comment.