an idea for polishing the debugging part for knowing what nodes were executed: i personally like how Visual Studio does this for watched variables - if a watched variable changes, it is highlighted red in the watched variables list. things that are unchanged from the last step are not highlighted, so the user can easily identify change (maybe this is already similar to what you’re doing, hence the flickering) this is probably overkill, but being able to turn back time/step backwards in steps would further make debugging more powerful/easier to recreate/replay scenarios after making changes to behaviors
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.
For a while now I've thought about making a game where you program your units (I was considering an ant-colony setting). If I were to make it, I would probably use the same tech stack ;] I shall watch your career with great interest and await a playable alpha/beta/demo!
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 RustGodot 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 ;]
Could you do a deep dive on how you got this working? I’d like to create a scratch-like interface that players can increment and decrement values (+1 health, -1 stamina, etc)
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'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
![🔴 ฟุตบอลแชมป์กีฬา 7HD แชมเปียน คัพ 2024 [รอบ 8 ทีมสุดท้าย] - ช่วงบ่าย](http://i.ytimg.com/vi/M0S_ReCIkxg/mqdefault.jpg)
an idea for polishing the debugging part for knowing what nodes were executed:
i personally like how Visual Studio does this for watched variables - if a watched variable changes, it is highlighted red in the watched variables list. things that are unchanged from the last step are not highlighted, so the user can easily identify change (maybe this is already similar to what you’re doing, hence the flickering)
this is probably overkill, but being able to turn back time/step backwards in steps would further make debugging more powerful/easier to recreate/replay scenarios after making changes to behaviors
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.
For a while now I've thought about making a game where you program your units (I was considering an ant-colony setting). If I were to make it, I would probably use the same tech stack ;]
I shall watch your career with great interest and await a playable alpha/beta/demo!
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 RustGodot 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 ;]
Could you do a deep dive on how you got this working? I’d like to create a scratch-like interface that players can increment and decrement values (+1 health, -1 stamina, etc)
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.
What is the name of the visual code editor?
It's unnamed, custom built for this project.
Nice, I made a "coding" game but am having a hard time getting traction. Hope you do well
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