This is how I’d prefer to work, given the choice—I’ve just had a hard time finding a set of tools that doesn’t leave me doing a lot of low-level work in one place or the other.
Here’s a Godot Engine based game coming out on Steam soon:
So, although it’s on Godot 2.1 instead of 3.0, the open-source turn-based strategy game Tanks of Freedom seems to cover almost everything I’d want to do in that field. I’ll have to dig in when I have some time.
Thanks for sharing that! I’ll take a look at it… eventually. If only I had the time… ;)
I’ll have to dig into this when I get a moment.
This might be fun if you’re looking to learn Godot and don’t want to stress over art
I spent a little bit of time this weekend playing around with Godot and Amethyst (the Rust game engine), in hopes of selecting a finalist for my skypirates zeppelin management game. So far:
Godot Pros
- Visual editing is super-nice.
- Support for almost everything I want to do is better out of the box.
- There’s that turn-based strategy game I can use as a jumping-off point.
- Better renderer, if I should get to the point where I want to drop the hex wargame tactical layer in favor of a flight sim tactical layer.
Godot Cons
- The existence of a Godot hex grid library notwithstanding, I think I’ll have to heavily modify it or roll my own regardless.
- I still haven’t wrapped my mind around the (admittedly straightforward) everything-is-a-node abstraction, and I think it makes the (admittedly gigantic) maps I want to do a bit trickier to manage.
- Even typed GDscript isn’t as nice a language as Rust.
Amethyst Pros
- I like Rust a lot.
- If I ever do get around to a flight sim layer, Rust seems like a much better choice for a physics engine.
- The entity-component-system model makes a lot of sense to me, and seems like it would scale very well as I tack more stuff on to the game.
- In general, I like the way Amethyst seems to do things more than the way Godot does.
Amethyst Cons
- Amethyst may have a UI framework, but I’d be doing a lot more of the heavy lifting.
- Same story with hex grids. I can do it just the way I want, but I’m doing it from scratch.
- Less mature renderer, vastly less mature ecosystem. Few examples, very few complete-game examples, few tutorials.
- Lack of visual editing is a bit of a pain for things like UI, especially given that Rust is not a fast-compiling language.
I’d say prototype with Godot, even if your final version requires something else. And btw, nothing prevents you from using Godot for front-end stuff and Rust for backend stuff, so to speak.
I spent some time on the clock a month or two ago doing a C ABI API in Rust, and I’m not eager to do much Rust->native work on the basis of that experience. <.<
The other downside to Godot is the lack of 64-bit floats, which I guess didn’t make it into 3.0—it’s somewhat limiting in terms of overworld positions if I go for a continuous representation (unless I use integers internally, or do a centered-on-the-player bubble). I’m kind of inclined to start in Amethyst, truthfully; in particular, rolling hexes myself seems like a good learning experience, and I think I’ll pretty quickly come to realize whether or not it’s feasible in the longer run.
I think I have actually decided to prototype with libGDX, for a few reasons:
- Kotlin isn’t bad, as languages go.
- I have some combat math set up in a Groovy project already, so the conversion to Kotlin won’t be too bad.
- Both Amethyst’s ECS and Godot’s scene graph seem a bit ill-matched to turn-based games.
- Alternate Rust-y solutions like ggez require a bit too much in the way of internet access, given that I’m going to be doing some of this prototyping on a non-wifi-equipped train and don’t want to blow out my tethering.
(Hopefully this foray into non-Godot game design is okay here!)
It’s way better than plain Java, that’s for sure. And some great stuff has been done using libGDX.
I did! It solves a few of the problems I think handicap Amethyst, compile times in particular, and Bevy’s author says he’s working on a Unity/Godot-style editor, too. I still don’t have a great sense for how to use an ECS engine to write a turn-based game effectively, although I’ve found a few tutorials that might bear on it. The usual idea seems to be to write the turn-based parts outside of the ECS model.
I’ve gotten the guts of my libGDX prototype about as far along now as I had it previously in Groovy, with asset loading (now libGDXified) and a rough take on dogfight resolution. I’ll probably start doing up some UI next, and then tackle hexes. There’s a Red Blob tutorial on hexes-on-a-globe; I might try the unfolded-icosahedron idea for the strategic layer. I think it should be possible to make it more or less seamless, as long as I limit zooming out. If I use the same unfolded-icosahedron for battle maps, I can maybe even just treat battles like zooming in in space and time, so that battles don’t feel as disconnected from the strategy layer as in some open world games.
Mmm, I’m not familiar with this particular engine, but normally ECS fits turn based really well. Your systems do not process unless you advance a turn, and that’s it.
The UI of course would need to be done differently, but that’s pretty usual. You use the UI phase to change the components on your units.
I might be reading my own issues into this, but at least with Unity I run into this problem all the time where I have some objects which are purely model based (e.g. each Faction might have a list of Unit templates that they can potentially build), but I don’t want these models to actually exist in the world (e.g. it seems weird to have a GameObject,Transform, etc for each of these Unit templates for each Faction, when they are purely used for decision making purposes and should never be shown to the player). So then you break the concept apart into a Model side and a View side, and then you have to continually bridge that divide between your purely logical objects and the Entities which represent them in the game world. Maybe he’s running into something like that?
Might very well be. As far as I understand these engines use a proper ECS (haven’t used these other engines), so there there should be no distinction between view side and model side.
In Unity it’s different because game objects are very heavy entities that have some ingrained functionality (it’s not a pure ECS paradigm, although perhaps more convenient for many use cases), so you want to have data and functionality outside the scene in many cases.
I think this is part of what I was missing—how you can control what entities actually have on-screen presence by what systems are running.
Godot or Gamemaker Studio 2 for a civ-like strategy game?
I should preface that i’m not a programmer in real life and am going to learn this in my spare time. Gamemaker Studio is tempting because of its Drag and Drop object editor for someone like me, but before i invest too much time (and money) into it, thought i would drop by here and ask. GMS2 seems best fitted to 2D platformers.
Either could do it.
I think Gamemaker may be easier to learn for a non-coder, and probably has more online support (I’ve not used it).
Godot will give you more flexibility, and is cheaper if you want to go commercial.
There is also Unity of course, where you could probably buy some turn-based strategy framework pretty cheap on the Asset Store to kick you off.
Whichever way you go, it’ll be lots to learn, and lots of (fun) work. :)
Personally, having used both, I would go with Godot. The cost of entry is free, so you can spend a few bucks on some tutorials. Godot is gaining in popularity and has a 4.0 release coming in the next year that vastly overhauls 3D. On top of that, you can easily use Godot (and the same skills) to make non-game apps, too, in case that’s something you’d ever want to do.
That aside, getting started and leaning the basics is not too bad. The community is growing and people are friendly and helpful.
Find one of those Udemy coupons that gets you a course for $10 and get this course. It is a gentle learning path, but as soon as you’re feeling confident, you can start your own project in parallel.
The guy who runs this site has tons of useful tutorials: https://www.gdquest.com/
He has some paid courses here, too: https://gdquest.mavenseed.com/