spent a lot of time as well leaning on some supabase inspiration here and implemented row sorting. this works at both the high level sheet level, but also allows you to sort independently on nested lists. these nested sorts also persist across any visible versions of that list, which is nice for comparing comsistent sorted values!
A member registered Nov 15, 2014 · View creator page →
Creator of
standalone editor for static game data — edit json like a spreadsheet
Some backgrounds for the Troika Tarot Jam
a manifesto about making games for no audience
Recent community posts
another thing that I wanted to add in was a REST client. I want other tools to be able to easily communicate with running Depot instances, so now the server that serves the images also provides a REST api so other tools can hit the endpoint to do stuff! there is still the websocket connection that the client uses, but REST is easier to understand and setup (you can just use curl!) so I've been loving it.
cool things possible here are things like dev builds being able to write data back to the db itself, either to tweak values, write in new entries/etc. whatever you want!
took some time to clean up the UI a bit, mainly unifying row size. also been very inspired by linear/supabase recently for UX stuff and added in linear-style row selection to clean up the little "x"/"c" buttons. now you can select rows, delete them with delete, or duplicate them with cmd+d. it all just works. oh also there is undo/redo! im using the giant cantata depot file here (~3MB), loads almost instantly and no lag in the interface for scrolling/operations/etc.
so first step here —getting Depot up and running with Svelte 5 in electrobun. it works! needed to fix images but this is just validating that the tool operates and can open an existing .dpo file. i'll likely update the depot schema itself in this process and auto-upgrade stuff that's imported, but for now it works!
also for reference, here is the same sheet opened up in old depot:
one thing on my mind as I do all this is trying to think of all the ways I did stuff in the first Depot, and trying to determine if those ways are intrinsic to how depot should operate (like nested views), or are things that were done due to how vscode worked (like file-centric operation), or are things that were more the limits of my own coding ability (like no re-arranging columns) or my own product-thinking ability (like the big chunky field buttons). we'll see what stays/goes!
Well that was an adventure. I just coded a Hearthstone-style rules system in a few days, only taking d8 psychic damage in the process.
But I think it's pretty cool. Here's the basic "entry" for the rules logic for a given action:
public void Wait(Action onComplete = null) {
Depot.Generated.dungeon.logicTriggers.wait.Emit(Systems.Logic.RootEvent, postExecution: e =>
{
Dungeon.Track.Act(e);
}, onComplete:onComplete);
}This is doing a few things. First is that that long string of Depot path is the type-safe data emitted from my Depot integration that allows me to reference whatever I put in this, directly:
On top of that I then wrote extension methods that actually "Emit" the event into the action graph (again channeling this blog). I had a stroke of genuis for this bit that I think is worth a proper standalone blog about, and maybe as its own follow up to that blog I'm referencing, but basically what I do is bind the keywords themselves to a static dictionary that maps to "loose" static IEnumerator functions.
"Adding an event to the graph" then basically creates and underlying Event object that saves the references IEnumerator, and then invokes it when it's the events turn. The other thing I did on top of this was tie in sensible event lifecycle callbacks to modify the action graph as it runs, primarily through OnExecuted and OnComplete.
OnExecuted runs when an action graph node has been executed... which is a perfect time to add side-effect nodes as children of that node! The event polling system finds the new children, and executes as normal. What's also cool is that when you use the Emit function, it scans for matching keywords from cards such that it will also then tack on the "Will Do X" events to a node before execution, ensuring they update first.
OnComplete is called when a node is FULLY complete, as it has no more un-executed children. Tying into here can basically surface top-level callbacks for actions that may have had hundreds of reactions, etc. Here's a more robust example of how to trigger the "basics", and keeping in mind that under the hood all the graph event stuff is being automatically generated!
public void Move(Action onComplete = null) {
Depot.Generated.dungeon.logicTriggers.move.Emit(Systems.Logic.RootEvent, postExecution: e => {
Depot.Generated.dungeon.logicTriggers.discard.Emit(e,new Systems.Logic.EventData(Dungeon.Track.Cards[0].ID),
postExecution:e => {
Dungeon.Track.MoveTrackCardsToLatestTrackPositions();
Depot.Generated.dungeon.logicTriggers.draw.Emit(e,onComplete: () => {
Dungeon.Track.MoveTrackCardsToLatestTrackPositions();
});
});
}, onComplete:onComplete);
}The idea is that you have a unified entry point for all the main actions in the game that have pre-determined steps that execute, but at the same time any cards with interesting keywords/effects can automatically tie into this to build out a more robust graph of effects!
What's ALSO cool is that, to debug stuff, I tied in a simple way for the graph to report itself using Mermaid, so I can basically (visually) peek at the internal graph at any time. I'll set a breakpoint in the middle of that function above, and here's what the graph spits out:
flowchart TD 0[_0]-->7[move_7] 7[move_7]-->9[discard_9] 9[discard_9]-->10[draw_10] 0[_0]-->8[DeathReap_8]
Which visually resolves to:
This is a pretty simple state to visualize but it's cool to see it all working!
With this in place a ton of things are now possible so I'm hoping to actually crank on content between now + deadline and get some real gameplay in. Oh and I guess and inventory... and some spells.... we'll see!
7DRL Challenge 2024 community » Devlogs · Created a new topic Mystery Dungeon Hand - Balatro x Shiren
MYSTERY DUNGEON HAND
I've had an idea gestating for a while that I realized I wanted to make for 7DRL - the idea is to make a mystery dungeon style game (basically... a traditional roguelike) played through cards. But unlike other card action roguelikes like Slay the Spire or card-driven roguelikes(likes) like Forward: Escape the Fold or Card Crawl, I wanted to focus more on the deck itself and treat it like a "Room" that you encounter and "move" through. Then also trying to do things where you're seeding/upgrading a deck over time based on deck "primitives". It's maybe weird to explain but in practice I think works really well.
Another game worth mentioning that was a bit of an inspiration is https://store.steampowered.com/app/2338240/Searching_For_Rest/ - a (based on reviews) mostly unplayed game that I think has some really good design ideas in it.
So I put together some paper ideas for the game:
I don't expect too much of those docs to be legible, but thought they were fun to share anyways!
Dinghy
The other big part of this is that I'm doing all of the game in my own C# 2D game framework called Dinghy. It's a fully custom thing, built on top of Sokol + STB, and I think it's pretty cool. Here's some demo videos of what the engine itself can do:
The whole idea of the engine is that it's meant to be something like Heaps/Cermaic/HaxeFlixel but for C#. And it's specifically targeting trying to be able to quickly put games together with nice-to-have basics that can then tease out to be more robust. So for an example here's how easy it is to get a sprite on screen:
//Program.cs - seriously this is it
Dinghy.Engine.Run(new (800,600,"dinghy",
() => {new Sprite()},
() => {Console.WriteLine("update");}
));
It's got a fair number of nice things as well, including source-generated integration with Depot files and Heaps-style type-safe access to res/ files, meaning you can type-safely reference stuff like this (imagine you res/monster.png exists):
new Sprite(Res.Assets.monster) // no strings!
I'm using 7DRL to really put the engine through its paces for the first time, and am learning/adding a lot along the way already. Dev updates will probably be split between engine/game stuff as well to just talk about both as they evolve.
The biggest stretch goal for me for this jam is seeing if I can get it all compiling to wasm for the web. The tech stack allegedly supports it, but the compile toolchain for it all will likely need a days worth of time to even figure out if I can do it. But here's hoping!
Current state
Here's where we're currently at. I've got all the data hooked up with Depot which is populating the cards above:
I also got text rending working in the engine, but tbh on tying it up properly.
My current task is making the logic ECS proc properly in a card-action type way. Dinghy's backend ECS uses Arch so I'm tying into that a bit, but also doing some nice "I have access to Depot" type stuff for Logic event procing:
What this means is that from code I can then directly emit a "logic" event based on the type-safe logic triggers I get access to from Depot:
And then you can emit these events like:
What's nice is that again the logic event is type safe, so you can easily check Card keywords that respond to the logic events with a direct equality check, no strings required (they are literally the same "logic"!).
I'm excited now, but this is also the third iteration already of trying to get this stuff to work so I'm a bit in the doldrums of converting the old logic code to this. However once it's all setup, there's no code maitence required for incorporating new words/triggers. The only thing I'll need to do is just emit the logic even where it happens and everything else will just work as normal!
Off to coding, and hoping to report back more later tonight!
(Deleted) community » Bugs and Tech · Created a new topic ROAD mode - ended up with the UI off screen which led to a crash!
