In this devlog I do a live demo of the low level AI API for my dungeon crawl programming game. Come by the Discord if you'd like to discuss the game: / discord
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.
So far seems extremely sequential programming. Is there going to be room for HTN/GOAP principles to be applied? I mean in the visual scripting (I believe you said there'd be a visual (node based?) scripting interface?)
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.
So, what platform are you developing this for? Is there a reason you chose WA and Rust? Is this a web-based game? By the way, this type of content is exactly what I'm looking for. Too many youtube videos look at the coding part of making a game from a high-level. I'm past that level of understanding and am looking for more of the low-level implementation details, including workflow, how scripts work in concert, considerations for how you structure your code, troubleshooting and workarounds, etc.
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.
![🎤 ไปกันต่อออ! จับฉลากร้องเพลง x P’ #XXSIVK [EP.2] (1/2) เพลงของใครจึ้งสุดน้าา 💓🎤 #MXFRUIT](http://i.ytimg.com/vi/mLI_K0sAS4o/mqdefault.jpg)
Looking good! Also, I think it's the first time I've seen a Kakoune user lol
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.
So far seems extremely sequential programming. Is there going to be room for HTN/GOAP principles to be applied? I mean in the visual scripting (I believe you said there'd be a visual (node based?) scripting interface?)
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.
So, what platform are you developing this for? Is there a reason you chose WA and Rust? Is this a web-based game? By the way, this type of content is exactly what I'm looking for. Too many youtube videos look at the coding part of making a game from a high-level. I'm past that level of understanding and am looking for more of the low-level implementation details, including workflow, how scripts work in concert, considerations for how you structure your code, troubleshooting and workarounds, etc.
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.