tushant.mirchandani
New member
So I initially posted about this elsewhere, but Damon Caskey mentioned it wasn't a good idea to talk about this in a thread meant for tech-notes for development, so I thought I'd start a new topic on this. I wanted to talk about this and argue in favor of a ChronoCrash system / plugin for Godot, so I hope you can indulge me in this.
So I'll start off by quoting his previous post, so I can provide some context:
You're absolutely correct about the reason why we're here! I doubt any other system is as capable as OpenBOR, and the upcoming Chrono Crash, in helping provide something out-of-the-box to build one's games in. Even systems like GameMaker require a LOT of coding just to get those basics to be working, and the fact that we can get 99% it running quickly in OpenBOR is greatly appreciated.
However, even though I've seen the folks here build some really cool-stuff, even beyond the basics provided by its parameters, I don't think even OpenBOR is immune from the need to be technical / engineer minded in order to get something done. A lot of the unique features would actually require you to learn how to code and add scripts, and test whether or not they work or to what degree. I'm not a script-writer no matter how much I tried tinkering with it, and I've never been able to do it "well", so that's one of the biggest hurdles in my own design-requirements — to only stick to what's only possible within the system and think of unique possible tricks with those features, and not just focus on the design itself while the technical hurdles staying out of my way.
I also understand that's not an excuse, because to anything done you need to learn and master the tools. Heck, even Godot requires you to code even the most basic interactions like jumping and punching, something OpenBOR just does automatically.
But I've been keeping an eye on Godot these days, and I've been noticing its evolution. Most of the engineering-minded hurdles you mentioned? They're being rapidly reduced, and more. For instance, having a live-editing system to save your character's position for OpenBOR to start from in the next session may take some scripting-know-how to do, but it seems to be a de-facto feature in Godot. Not only that, but you also get to play with neat bells and whistles that most of us could only dream of, such as 2D lights and normal maps, or PBR-shaders for 3D game development in a free engine.
But those are just luxuries, because what I want to argue for primarily are the basic things. For one, like I mentioned before, the editor for Godot is god-sent for game development, primarily because I believe that every modern game-engine requires an editor to work with it — not because it's easier to work with, but because it's faster (and the time you save can compound to the money you get to earn). Consider creating your levels visually and placing sprites / models in specific locations by hand; it completely beats the need to measure (via Photoshop, Krita, etc.) at which pixel the enemy should spawn in, editing the text-file, saving it, then running OpenBOR just to see if it works as you expect it to. Saves time.
Another thing is the animation system. While I understand that a "good" game requires you to draw 2D sprites by hand (and that's the ideal way to go), but for efficiency's sake for a small developer I would be lying if I said that Godot's animation system wasn't helpful. While, sure, I could just animate something in Blender, export it to sequences, edit the files so that every sprite has the same palette, then create a model-file for OpenBOR,... that still takes significantly more time (and memory space) than simply doing it all in Godot and using it immediately. Again, it saves time.
But this isn't a post about how Godot is better than OpenBOR / Chrono Crash, since I don't think it surpasses what OB / CC can do out of the box. It's about how one system can benefit / complement the other.
I've noticed that Godot has a great plugin system that many developers seem to be taking advantage of. See, what it allows you to do is using code — the same way you'd write the code for the game — to create tools, buttons and window-boxes for the editor itself. In other words, you can quickly edit the editor while INSIDE the editor! It's like... Editception (pardon the old joke). And I don't think it's just the editor, but rather you could possibly apply it to the entirety of the engine itself.
And some folks have put that to some really good use. For instance, they understood that, if you were to make a Visual Novel or Adventure Game or something, it would be a pain in the ass to use Godot's native script (or even Python and C#) to draw each and every dialogue-box, place the character, add text, etc. So what they've gone and done is create a Ren'Py like system called "Escoria" which makes that task easier, faster and less-tedious — no scripting required. I'll link to an image to illustrate what I mean: https://i.imgur.com/p3vHCf0.png
If such a framework can so easily be created for any other such use, I'm pretty positive that one can also create it for Beat-Em Ups. It should, then, theoretically be possible to create a BOR-like system for Godot, where you approach the design the almost the exact same way as you would in OpenBOR, such as its parameters where you can define if a model is a Player or Enemy, or Obstacle, or whether it will summon something in the duration of the animation. With that framework, you could also theoretically assign for freespecials in the exact same way. You can also have X, Y and Z directions for movement for a good 2.5D gameplay, considering Godot also supports isometric so there' potential for other perspectives.
Not only that, but such a framework / plugin can also benefit from Godot's own system which OpenBOR couldn't do without scripting, such as helping the developer quickly and intuitively create a menu / character-select system with fluid animations, making the games feel a bit more modern. It could also be paired with an RPG-like item-inventory and stats system / plugin, like a Dungeons & Dragons game around here, which would otherwise be a very tedious task to accomplish via OpenBOR alone.
Creating such a framework / plugin for Godot has great potential, because it gives you a nigh-complete toolset to work with. The same system that works for 2D BOR-like games can also then work for a 3D Beat-Em Up, something like Arkham Asylum, and it can also allow me to just do things far easily with the animation-system what I've always wanted to do in OpenBOR — advanced camera solutions depending on type of game, or sprite-based cutscene system without interrupting gameplay. Plus, Godot might end up exporting to Nintendo Switch soon (judging by Lian's tweet), so there's that.
So, creating a framework for Godot may actually be faster than having to build an engine from scratch, like with Chrono Crash. That said, I'm not in no way implying we should abandon Chrono Crash either, considering that OpenBOR may be doing so many things right that Godot just can't (or may never will), such as a palette-based system for older or specific devices. I believe the native OB / CC system outside Godot has its own value, doing things in ways even better than what Godot has to offer, and having complete autonomy over your own system to make it work exactly as you want it to must also be respected because it allows you develop fast and take great pride in it.
I'm merely offering an idea that may potentially co-exist with Chrono Crash / OpenBOR.
I also want to end this post saying that I appreciate all the work you guys do and I respect the decisions you take. You don't HAVE to make something just because I might want you to; you guys do it all for free out of your spare time for the love of it, something I'm grateful for, and given that I've contributed next to nothing I also am not entitled to anything (except good Linux builds, because goshdarn, the community needs moar Linux builds xD). So consider this post to be nothing more than an attempt to offer my perspective, or perhaps some ideas that may or may not be helpful. If nothing else, then at least as a conversation starter.
It took me a while to write all this, but that shouldn't discourage anybody from taking umbridge to all this. Feel free to roast me for this wall text, and I will blame no one for it. xD
EDIT: Need to make an addendum. I'm just a simple artist, so I don't understand much about the technical side of programming and development, so I'm also probably very ignorant about the feasibility of what I'm asking here. If there are some necessary things that I haven't considered, that I also should understand, feel free to correct / inform me about it.
So I'll start off by quoting his previous post, so I can provide some context:
Damon Caskey said:It's fine to talk about other engines, though perhaps not right in the tech notes thread for development. We actually have a forum area for non-OpenBOR projects.
Anyway, Godot is a great engine, and like many out there it appears to blow OpenBOR away at first glance. I've been tempted myself a few times to jump over there. But once you get past all the hype and glitzy bullet list eye candy, OpenBOR holds its own just fine.
The biggest problem with Godot is the technical gateway. The editors look pretty, but you'll very quickly discover that without a mind for engineering, that's as far as you'll get. For all the flack some of you like to give us about OpenBOR being too hard, there's a reason you're here. There just isn't anything out there that lets you get so much done with so little prior knowledge - and the unified community to back it up.
For turn based RPGs, 3D, and simpler platform 2D projects, Godot is nice (though Unity is tough too). But for action oriented 2D games, especially when the Z axis is involved, OpenBOR has already done 99% (no, really) of the work for you.
Choose the right tool for the job.
DC
You're absolutely correct about the reason why we're here! I doubt any other system is as capable as OpenBOR, and the upcoming Chrono Crash, in helping provide something out-of-the-box to build one's games in. Even systems like GameMaker require a LOT of coding just to get those basics to be working, and the fact that we can get 99% it running quickly in OpenBOR is greatly appreciated.
However, even though I've seen the folks here build some really cool-stuff, even beyond the basics provided by its parameters, I don't think even OpenBOR is immune from the need to be technical / engineer minded in order to get something done. A lot of the unique features would actually require you to learn how to code and add scripts, and test whether or not they work or to what degree. I'm not a script-writer no matter how much I tried tinkering with it, and I've never been able to do it "well", so that's one of the biggest hurdles in my own design-requirements — to only stick to what's only possible within the system and think of unique possible tricks with those features, and not just focus on the design itself while the technical hurdles staying out of my way.
I also understand that's not an excuse, because to anything done you need to learn and master the tools. Heck, even Godot requires you to code even the most basic interactions like jumping and punching, something OpenBOR just does automatically.
But I've been keeping an eye on Godot these days, and I've been noticing its evolution. Most of the engineering-minded hurdles you mentioned? They're being rapidly reduced, and more. For instance, having a live-editing system to save your character's position for OpenBOR to start from in the next session may take some scripting-know-how to do, but it seems to be a de-facto feature in Godot. Not only that, but you also get to play with neat bells and whistles that most of us could only dream of, such as 2D lights and normal maps, or PBR-shaders for 3D game development in a free engine.
But those are just luxuries, because what I want to argue for primarily are the basic things. For one, like I mentioned before, the editor for Godot is god-sent for game development, primarily because I believe that every modern game-engine requires an editor to work with it — not because it's easier to work with, but because it's faster (and the time you save can compound to the money you get to earn). Consider creating your levels visually and placing sprites / models in specific locations by hand; it completely beats the need to measure (via Photoshop, Krita, etc.) at which pixel the enemy should spawn in, editing the text-file, saving it, then running OpenBOR just to see if it works as you expect it to. Saves time.
Another thing is the animation system. While I understand that a "good" game requires you to draw 2D sprites by hand (and that's the ideal way to go), but for efficiency's sake for a small developer I would be lying if I said that Godot's animation system wasn't helpful. While, sure, I could just animate something in Blender, export it to sequences, edit the files so that every sprite has the same palette, then create a model-file for OpenBOR,... that still takes significantly more time (and memory space) than simply doing it all in Godot and using it immediately. Again, it saves time.
But this isn't a post about how Godot is better than OpenBOR / Chrono Crash, since I don't think it surpasses what OB / CC can do out of the box. It's about how one system can benefit / complement the other.
I've noticed that Godot has a great plugin system that many developers seem to be taking advantage of. See, what it allows you to do is using code — the same way you'd write the code for the game — to create tools, buttons and window-boxes for the editor itself. In other words, you can quickly edit the editor while INSIDE the editor! It's like... Editception (pardon the old joke). And I don't think it's just the editor, but rather you could possibly apply it to the entirety of the engine itself.
And some folks have put that to some really good use. For instance, they understood that, if you were to make a Visual Novel or Adventure Game or something, it would be a pain in the ass to use Godot's native script (or even Python and C#) to draw each and every dialogue-box, place the character, add text, etc. So what they've gone and done is create a Ren'Py like system called "Escoria" which makes that task easier, faster and less-tedious — no scripting required. I'll link to an image to illustrate what I mean: https://i.imgur.com/p3vHCf0.png
If such a framework can so easily be created for any other such use, I'm pretty positive that one can also create it for Beat-Em Ups. It should, then, theoretically be possible to create a BOR-like system for Godot, where you approach the design the almost the exact same way as you would in OpenBOR, such as its parameters where you can define if a model is a Player or Enemy, or Obstacle, or whether it will summon something in the duration of the animation. With that framework, you could also theoretically assign for freespecials in the exact same way. You can also have X, Y and Z directions for movement for a good 2.5D gameplay, considering Godot also supports isometric so there' potential for other perspectives.
Not only that, but such a framework / plugin can also benefit from Godot's own system which OpenBOR couldn't do without scripting, such as helping the developer quickly and intuitively create a menu / character-select system with fluid animations, making the games feel a bit more modern. It could also be paired with an RPG-like item-inventory and stats system / plugin, like a Dungeons & Dragons game around here, which would otherwise be a very tedious task to accomplish via OpenBOR alone.
Creating such a framework / plugin for Godot has great potential, because it gives you a nigh-complete toolset to work with. The same system that works for 2D BOR-like games can also then work for a 3D Beat-Em Up, something like Arkham Asylum, and it can also allow me to just do things far easily with the animation-system what I've always wanted to do in OpenBOR — advanced camera solutions depending on type of game, or sprite-based cutscene system without interrupting gameplay. Plus, Godot might end up exporting to Nintendo Switch soon (judging by Lian's tweet), so there's that.
So, creating a framework for Godot may actually be faster than having to build an engine from scratch, like with Chrono Crash. That said, I'm not in no way implying we should abandon Chrono Crash either, considering that OpenBOR may be doing so many things right that Godot just can't (or may never will), such as a palette-based system for older or specific devices. I believe the native OB / CC system outside Godot has its own value, doing things in ways even better than what Godot has to offer, and having complete autonomy over your own system to make it work exactly as you want it to must also be respected because it allows you develop fast and take great pride in it.
I'm merely offering an idea that may potentially co-exist with Chrono Crash / OpenBOR.
I also want to end this post saying that I appreciate all the work you guys do and I respect the decisions you take. You don't HAVE to make something just because I might want you to; you guys do it all for free out of your spare time for the love of it, something I'm grateful for, and given that I've contributed next to nothing I also am not entitled to anything (except good Linux builds, because goshdarn, the community needs moar Linux builds xD). So consider this post to be nothing more than an attempt to offer my perspective, or perhaps some ideas that may or may not be helpful. If nothing else, then at least as a conversation starter.
It took me a while to write all this, but that shouldn't discourage anybody from taking umbridge to all this. Feel free to roast me for this wall text, and I will blame no one for it. xD
EDIT: Need to make an addendum. I'm just a simple artist, so I don't understand much about the technical side of programming and development, so I'm also probably very ignorant about the feasibility of what I'm asking here. If there are some necessary things that I haven't considered, that I also should understand, feel free to correct / inform me about it.