วีดีโอ

Thanks. It feels good to be making progress, even if it's not super fast.

Yes, even doing just a little bit regularly is much better than doing nothing!

Thanks. It's a super interesting subject.

It's unnamed, custom built for this project.

Thanks! Garden of Rogues is fun, I like that. I do need to actually pick a name soon but I've been waiting until I've done some more brainstorming around the game's story.

That's a good suggestion. I'm not quite sure it works with the story I have in mind, which I'll talk about in some future devlog.

Thanks! Yeah, Stone Story is definitely an inspiration.

Thanks! I'm surprised you recognize it, most people just think it's vim.

I thought it's (neo)vim at first, but it looked off. I thought it might be Helix, but I found the command at 1:18 and that's how I knew. Otherwise I would ask what editor are you using ;]

Nice. It's an interesting editor, if you're the kind of person who's interested in editors (which you evidently are). I've been using it for years and like it but I wouldn't go around trying to convince vim users they should switch. It's an incremental improvement over vim that changes the command syntax a bit and adds robust support for multi-selections (which is what keeps me using it) but is otherwise pretty similar.

Yeah, what I'm demonstrating here is just the basic low level command system and queries into the game state. The AIs also have access to persistent storage so you would be able to setup any architecture you wanted. I likely won't supply client libraries for specific AI architectures, at least initially, so users would need to develop their own. The visual programming system, which I demoed in a video a couple of weeks ago if you want to see it, is a bit more opinionated about how the AIs will be structured. The focus for that will be to make working with it feel as game like as possible while still allowing for reasonably complex behaviors so I'm not going to focus on a particular architecture persay. Figuring out how that system should be structured is going to be one of the hardest design problems in this project and I'm not that far in to it at this point, so that's ongoing work. I suspect it will end up being roughly a behavior tree type system.

This will be a desktop game. My plan is to target Linux (my personal preferred system), Windows and MacOS if it's not too complicated (I haven't done anything with Macs since the first release of OSX). I'm glad you liked the video. I doubt I will do more videos exactly like this one since so far no one who isn't a subscriber has watched it at all and only two or three people have watched past the intro. So, at least in this format, this isn't something folks like. It might work better in the livestream format and I likely will try that at some point. I'll definitely talk more about technical decisions and details in future videos though. I plan to stick with the two part format where the first half of the video is a showcase of recent progress and the second half is more technical discussion of some aspect of the game. I figure people who are mostly interested in the progress of the game can drop out in the middle if they don't want the more detailed technical stuff.

I realize I didn't answer the question about language choice. I'm using WebAssembly because I want to give players who choose to use the low level API as much flexibility as possible in how they implement their programs. To my knowledge, WASM is the best available choice for that: the compiled code is fast, safe to execute in a sandboxed environment and can be produced from a wide array of languages. I'm using Rust because it's my preferred language at the moment. I like that it is fast by default, has a highly expressive and strict type system, favors explicitness and has a high quality build and dependency management system. It also handles portability well.

You have to condition the conditionals somehow.

Thanks! The agents will absolutely be able to communicate. I'm not sure exactly how yet but I agree that limiting the range is an interesting constraint. Basic communication will be line of sight though I think it might be interesting to have an option to upgrade to longer range bulletin boards later in the game, maybe with some additional limitations relative to local communication so that it can't completely replace that. Or possibly allow agents to leave spatially located messages, like writing notes on walls or something. The very limited communication that currently exists (as a rough prototype which may change) works like this: Agents are assigned an immutable faction identifier at birth (currently it's just "player" or "monster"). Each agent also has a sub-faction identifier which they can set to any value they choose. They also have a "leadership claim" numerical value which they can also set to anything they choose. All three of those values are public and readable by any agent within line of sight. The way I've been using them is to have a Leader AI program and a Follower. The Leader sets it's leadership claim high and the followers set theirs low. The Followers then look for the nearest agent with a high leadership claim and follow them around. A very crude way of forming parties. Obviously you could do more complex stuff with that, up to designing a serial protocol around changing the leadership claim or sub-faction claim each turn and transmit arbitrary data that way. But I do intend to build in something more ergonomic specifically for communicating complex data between agents.

Thanks! Good to hear that you're interested. I probably will go ahead and do that video then.

@@CaudiciformStudios-ik5dj I second this!

@@CaudiciformStudios-ik5dj I third..this? XD

@@arcane3427 Well, lucky for you the two videos after this one were exactly this in Rust and then Python.

Hopefully I'll have a testable demo "soon"

Nice. Cogmind is great.

Thanks!

Thanks! I'm thrilled that there are people interested in my super niche project.

Nearly a decadozen at this point, which is a very fancy sounding number.

Thanks! It does represent a couple of months of work so it's a bit of a dump.

Amazing! I'm glad you found the project then. I'll try to deliver the best programmable-ant-pile game I can. If you want another devlog that's a less programming game but more explicitly a fantasy ant simulation @LycheeGameLabs is working on a project I've really been enjoying watching.

I appreciate that

I see the other comment, so I don't think it got deleted unless there was more than one since my last response. I just haven't had a chance to respond yet so I'll do it here. I'm not totally sure I understand the question. You can certainly use the host language's implementation of conditionals or such but you still need some structure around that to handle the graph like structure of the visual coding system. C#'s conditionals don't come with a scratch like GUI that would allow you to chain the statements together visually so you have to build that part yourself. With regards to your question about using the scratch code, I'm not sure. I haven't looked at their code at all but my experience with things like that is that it's usually easier just to build it yourself unless they are specifically designed to be embedded. But if there is an embedable version of scratch that's compatible with your engine that might well be a good choice.

Super appreciated!

0.00000001?

@@akaithecreator7448 lim x -> 0

ε

I will be talking about more chunks of the system in future devlogs but I'm not sure how useful a tutorial style deep dive on the system I'm using would be because it's very closely tied to AI infrastructure of this particular game. Generalizing it to the point where it would make sense as a stand alone system would be a bigger project than I can tackle right now. If you've got specific questions though I'd be happy to answer them.

@@CaudiciformStudios-ik5dj So, I’m trying to make a game about robots and AI… The bots have parts that can be swapped in and out to modify functionality of the bot. However, I also wanted to include a scratch-like editor that players can increment/decrement values associated with a particular part. Ex: a machine gun might fire 3 rounds per second by default but, the player could modify the script to make it shoot 4 rounds per second. The interface wouldn’t necessarily have to work like scratch… but I wanted an easy to understand high-level abstraction, so players feel like they’re coding/hacking the code without needing to fully understand what’s going on. I want to give the player a point for winning bot battles, which they could then use to increment/decrement values in the scratch-scripts. I guess my question would be… how could I get something similar in my game? I’m wondering if I could directly translate c# scripts in Unity to scratch scripts in the game… basically, could I create a scratch script builder that puts the scratch code blocks together 1:1, using the actual C# code in the background as the reference material?

That sounds like a cool project. I've never worked with unity so I don't really know how code is normally structured in that engine but the way I would approach that is to have each chunk of functionality like "fire gun" or "increment stat" be an object with a bit of code that does whatever the game effect is and also has a list of outgoing connections to other objects. A graph data structure basically, if you're familiar with that. When an object is triggered it runs it's own code to do whatever it needs to do in the game and then it iterates through it's list of outgoing connections and triggers those objects to do their own actions, which might trigger further actions, etc. For an object that represents a conditional, like an if statement or whatever, you would keep two lists of outgoing connections: the ones to trigger if the condition is true and the ones to trigger if the condition is false. Whatever needs to kick off the program, a game tick or turn start or the player pushing a button or whatever, would be setup to trigger the first object in the graph. That's basically how my system works. I have a second set of connections as well that represent the flow of data through the graph so nodes can pass values to each other but you may not need that for what you're doing.

@@CaudiciformStudios-ik5dj Yeah, I have a whole design document for the game lol Thanks for the explanation. I'm in my 4th year of a CS degree, but haven't had enough practical experience to build large applications. Given my inexperience, I'm curious, do you start from a high-level and write what you "think" you'll need in terms of systems, then drill down on those systems to find subtasks that need to be coded, before connecting objects in a branching tree structure that represents the logical flow of the program? Also, do you have a Discord or something I could join to keep up to date with your day-to-day progress?

Yeah, large applications are a very different thing than isolated features or small exercises. I've been programming for almost 30 years and I still have to think very carefully to avoid getting tangled up in larger projects. Especially when working in a new domain, like game dev which I haven't done much of before. For the visual programing environment in this project I'm coming at it from two different angles. First is game systems, those are always designed totally separately from the visual programming stuff. I then build a minimal interface to the game system in my low level AI API and then I implement higher level nodes for the visual environment on top of that API. So the nodes in the visual programing environment are several layers of abstraction removed from the actual game systems because I have these two distinct layers. The second angle for me is a game design one. I want using the programming environment to be game-like and integrated into the over all game rather than being "just" a programming language. That means that when designing the nodes I'm often thinking about how they will be introduced to the player and what role they will play in the game. In practice my process is often like this: I decide I want a creature or the player to do a particular thing, like patrol through a list of waypoints. I realize there's no way to express that yet in the programming environment so I sit down and come up with a set of nodes that could be used to create that behavior. Then I implement those nodes against the low level api. Then I try to actually build the behavior in the game and see how it feels. Then, later, I go back and adjust those nodes, maybe break them apart into simpler concepts or combine simple nodes into a more complex higher level function, according to how I want to expose those capabilities to the player. Maybe that answers your question? I don't have a discord yet. I will set one up soon-ish and I'll announce it here for sure. I know that's going to be a super distracting process for me so I've been waiting until I'm a little further along in the project. But thanks for your interest, that means a lot to me.

Yeah, I've thought about that some. My current plan is for characters to be given a base type, like a class, which defines all their intrinsic stats and abilities and then all "upgrades" are determined by what equipment they currently have. But there could certainly be equipment that increases the agent's computational abilities in some way. Currently agents have access to unlimited cpu and memory, both of which will eventually need safety limits just to prevent buggy code from crashing the game. But it would absolutely be possible to make those limits part of the game design as well. I already have cases where I want some creatures to be slower than others, which I do by just having the AI take an idle action every other turn, but you could handle that by limiting the agent's computation speed. Though I'll probably do it by adding a concept of "action points", allowing some agents to take more game state altering actions per turn than others, and that could potentially be upgradable via equipment. The asynchronous multiplayer is another case where there will almost certainly be design around computational abilities. In general I don't want to force players to write super optimized code if the don't want to, but optimization can be good fun. So I think there will likely be a competitive mode where agents are limited to a certain number of CPU seconds per turn, or maybe chess clock style where they have an allotment of CPU seconds to use however they want over the course of an entire run. And in that context finding or crafting equipment which gives additional CPU time could be a cool strategic addition to the programming challenge of writing tight code.

@@CaudiciformStudios-ik5dj Those are some really cool ideas! I'm hyped now ;]

Yeah, absolutely, thanks. The current nodes are all placeholders and will need a lot of cleanup. One of the open design questions for this is how granular the nodes should be and who exactly the audience for that tool is. If the audience is programmers, then getting a minimal, clean set of basic functionality down is important so people can write arbitrary code. But if the audience is people more interested in puzzle solving than actual programming then it's likely better to have the nodes be higher level and more complex and either not have or demphasize low level operations. Likely the right balance is somewhere in between. Hmm... that was a bit of a rant, sorry, but it's a thing I've been thinking about. Your suggestion of having a parameterizable comparison operator is probably the right thing regardless of how I end up balancing the selection of nodes.

@@CaudiciformStudios-ik5dj You can make it a progressive difficulty curve, where you start at a high level and explore deeper and deeper as time goes on. Additionally, you can make a guided progression and a free mode, where all the complexity is unlocked for the more experienced. A new game that is also a nice reference is "The farmer was replaced", because of its documentation. It uses python I think, but you can learn how that game introduces its concepts. Although it also uses a tech tree to unlock its functions

That makes sense I think. I do intend to have a complexity ramp where I gradually add capability to the system and some of that could be allowing the player to do lower level operations. Thanks for mentioning The Farmer Was Replaced. I've seen it pop up a couple of times but I hadn't actually tried it until now. It's very interesting, they are definitely doing something similar to what I have in mind. And the progression from concept to concept does seem pretty good. I actually had an early prototype of this where the in-game language was python rather than the visual stuff. I switched to the visual system because that seemed to be easier to make gamelike and approachable to a wider range of people, I think that was the right decision but I'm sure there are people who will be grumpy that there isn't a real language, but they can switch over to the Webassembly side, which can host anything, including python. I intend to use collectables accessed through exploration to hand out new capabilities to the player, but that's basically the same as their tech tree just with different genre conventions.

@@CaudiciformStudios-ik5dj Cool! I do think you're going in the right direction. There are plenty of games for programmers that go as low level as binary and assembly code. But accessibility is also important. It'll allow for younger or more inexperienced audiences as well as experienced ones. I personally don't mind visual programming. It's a change of pace, like going from one kind of puzzle to another

Thanks!

Clickpocalypse is pretty cool, thanks for mentioning it. I'd never played that one before though I've played similar things lie Progress Quest, which are definitely an influence on this project.

Thanks!

Thanks!

Thanks!

Thanks!

Highlighting change is interesting. Currently I only show how control flowed through the graph on the last step, so if something changes you'll only see that if you are watching the visualization while it happens. That's definitely something to think about, thanks. Being able to step forward and back is on my todo list. The way the game is implemented should make it _reasonably_ easy to do but there's still some complexity there and I haven't tackled it yet.

Thanks! There is some complexity there, but hopefully not so much that it bogs down. We'll see.

Yeah, I'm a bit worried it's too small a niche, we'll see. Your game looks interesting but the demo didn't work for me on linux. It didn't launch at all from steam and when I try to run it directly using wine it launches to a blank hex grid with just a settings button showing. I couldn't get it to do anything from there, choosing "replay orientation" in the settings didn't do anything.

@@CaudiciformStudios-ik5dj oh, thanks for trying, i've only tested it on PCs. Only the settings button showing is usually when it can't connect to Steam.

Yeah, when launching directly under wine it doesn't get access to the steam api. I'd like to try the game so maybe I'll try getting it to actually launch under steam later. Or if you're using and engine that can do linux builds I'd be happy to test that.

FWIW I figured out what was wrong: I had steam set up to use the experimental branch of Proton and that wasn't working, when I switched back to the stable branch your game ran fine. The programming interface reminds me of a cool music tool called HexoSynth, which has a similar dataflow based programming setup on a hex grid.

@@CaudiciformStudios-ik5dj cool, thanks for checking it out. i've never heard of HexoSynth but will take a look. the interface was inspired by Carnage Heart, an old PS1 game, but it used squares

That sounds like an awesome project! If I were starting this game again one thing I would consider would be just writing wasmtime bindings for gdscript and having the entire game logic (aside from the agent behaviors) be in Godot. I love writing Rust but the Rust<->Godot boundary adds quite a bit of friction. I'm not sure it would be better, having the complex game code in Rust makes it clearer and more reliable than (I think) it would be in gdscript, at least for a somewhat sloppy programmer like me. Something to think about if you're considering the stack for a similar project though. I will definitely talk about testable demos here when the time comes. Glad to have you along for the ride.

I already have like 3 projects that are in progress-ish, so I won't be starting another one anytime soon (famous last words 😅). And having just finished (an MVP of) a fantasy video game console, with a custom programming language, that can be ran in the browser, I think I've had my share of Rust and WASM shenanigans for some time ;]

Thanks!

Thanks. Blueprints is definitely on my mind and scratch too, I actually think it might start to look more like scratch as I polish things. I am definitely working towards some kind of playtest but I'm not sure when exactly. Your reel has some good stuff in it. I'm not sure how I'm going to handle music for this project yet but I'll keep you in mind. Music is one of those things I enjoy as a solo dev but also know that I'm not great at so it is totally possible that I'll bring in someone to do that part.