I've been posting a lot lately about wanting new menu features, using tiles as storage classes, and generally abusing Pulp by trying to create something that was never really in-scope for the Pulp devs...
I've made some progress!
My code isn't entirely consistent - sometimes I use a single TILE to represent general behavior and use its frame as a state variable (e.g. for the TOOL tile). Other times I use a single TILE as a quasi-class with TILE_n variants each implementing their own behavior (e.g. in the MENU and MENU_n variants).
You can see in the above animation (about halfway through) that the player tile is always drawn above the "fill" command. this is unfortunate for my usecase, where I want to drop a blocking progress meter over the UI. I'm looking into ways to fix this - maybe I'll push the player tile into the top-right corner (a location in the HUD which the user can't otherwise visit), then restore the user afterwards...
I think my approaches to randomized room tiles, complex menus, and using tiles as quasi-classes may be decent examples for others to use and improve on - so i've dropped the JSON into the zip above.
For this game/experiment my goal-posts are still moving... but currently I'm heading in this direction:
Story
A story-driven game that starts with the user directly controlling a robot to explore some distant planet
Over time the user gains access to write programs on the robot. Some shenanigans are planned here regarding AI, sentience, data corruption, and survival instinct
Eventually the player transitions from a human controlling a robot, to something like the robot's internal narrator - because the wireless link to humanity is lost (gasp!)
I've got some basic script written that covers a period of time so long that only a robot could truly appreciate it
Implementation
Fully randomized "rooms" will be used, full of hazards, impassable terrain, and some just plain old sand. I've mocked up just a sliver of this so far, but will reuse some of my prior experiment: "Loot'n'Scoot"
Rooms might not be re-entrant; that is, once you leave a room it's just gone for good. Caves collapse, trailheads are lost, something shiny in the distance distracts you and POOF you are lost again... that sort of thing
I use lots of tiles as containers for scripts to track unique behavioral components of the game; it's nice to use tiles for this - i think it is working best in the MENU tiles, but the TOOL tiles aren't horrible
Menus... not what i would call a LOT exactly, but perhaps more complex than was anticipated by the Pulp devs
Tool usage models which cost energy, take time, and (will) perform a function
An in-game programming model will provide a basic automation scheme
So far you're mostly looking at some core mechanics and a plot description... so it makes sense that it doesn't yet make much sense...
In a sense I'll be creating a logical effect similar to what you use in Comet - the player can't see unless they explicitly do something to enable sight (the lantern for you, a sensor on a remote robot for me). If something happens outside the field of view then it goes unnoticed until the player does something to see that region (possibly for a second time). Rather than just light-based vision, my little robot has a few different sensors:
camera: lines up with vision well, can't see past solid objects, can differentiate between walls and items, scans a straight line from the robot in one direction up to 3 tiles away
sonar: can tell if something is solid or not, but can't differentiate between items and walls. scans are tightly constrained, just 1 tile from the player, but scans the entire proximity around the player (like a circle of light from a lantern might?)
radar: scans in a cone shape ahead of the user. i think this will see just walls, blind to items entirely. also think i'll have this scan through walls.
GPR (ground penetrating radar): can detect underground hazards in a small area ahead of the player.
each sensor uses energy, and players will need to recharge from time to time. for that i have another tool, "charger". recharging takes time (i'm still toying with the idea of using the crank - i implemented it already, but it's hard to gt a sense for how it will feel on real hardware).
the last cool thing i have up my sleeve for this, the part that's taking all the time, really, is that the player can program the little robot. i wrote a small scripting language right in the game with 4 variables, 2 registers, 16 instructions, and room for 4 "programs" with up to 8 instructions each. This part still needs more work - in-game documentation is really difficult to present to the user with the current menu implementation --- i'll likely need to just rewrite the menus using all custom code rather than the native widgets. i'll get it done though, eventually
I think i'll need to provide a way to save and load whole programs too...
This doesn't look like what I was expecting from a pulp game, which I mean as a compliment!
The different sensors sound like an interesting mechanic, I'm intrigued how the different feedback from those will be displayed and differentiated (and overlap?) on a 1-bit display. It all sounds (and looks) very information dense, which I think is what you are going for!
I'm toying around with several "pie in the sky" ideas right now, but also feel like getting a playable v1.0 should take priority.
towards a playable v1.0 i'm thinking of:
I'll create a couple more tools; e.g. a "spark gap" transceiver to briefly make nearby "artifacts" light up
some sort of "operators manual" type widget the player might open up (draws and fills to make it look like a book?) to explain the tools well
implement a few of the "hazards" already modeled; this are basically hidden and static "bad guys" that push you deeper into a pit (increase the depth level)
some short term goals: maybe collect 1 each of several artifacts in order to exit a room?
a long term goal: exiting some rooms moves you higher in the pit; get to the top and you're free (done)
some way to score the game: maybe like golf where higher is worse... each time you step on a tile you've already stepped on adds 1 to your score?
anyway - i really want to get some form of this "complete" before the end of the month. once that's done i'll take another pas at in-game programming of the robot and the "sentience" idea (i don't want to give away too much about that yet as i think a lot of the fun to be had will come from experiencing it unexpectedly in-game). Call those v1.1 and v1.2 ... eventually
