I've categorized game tools into three general categories and come up with a bit of terminology to describe them:
- Frameworks and engines (Flixel, LÖVE, Quake, etc.)
- GIDEs - Game IDEs (GM, MMF, Construct)
- GGIDEs - Game Genre IDEs (RPG Maker, Mugen, FPS Creator...)
The GIDEs are what I'm focused on since they seem the most interesting but the other two are useful for context. I feel I'm close to the point where I could really pull off one of these tools, at least a 2D one - I'd like to come up with something that powers lots of future game jams
My best guess at the common features defining this area of tools:
- A "finished" data and distribution pipeline, no need to code up your own format support or do nitty-gritty stuff with build processes.
- Built-in content tools: combined paint/animation/collision editor, map editing, etc.
- Scripting language, entity/event model, and engine features are all integrated. Gameplay is typically built through judicious use of the provided models, rather than through extension of the core engine.
The main difference between a GIDE and GGIDE, as I see it, is that the gameplay model is still left undeveloped in a GIDE. Things like setting the experience curve of character classes in RPG Maker come to mind - there are very specific pieces of content tooling in a GGIDE that only help if you want to make an RPG with RPG Maker-type gameplay. As well, the bent of the GGIDE is to ship with lots of prefab content that you can use to start a project by sketching out environments and narrative, while in a GIDE most of the time you start from a truly blank slate for content and are still encouraged to rework the mechanics.
For the rest of this I'll expound on what I see as the present and potential future of GIDEs.Some commentary
As of right now, we have some proven success stories in GIDE use. They're good enablers for both prototyping and "final" works, especially where programming experience is limited. But the best users tend to end up leaving them for a more custom solution. We should fix the things that make them leave.
I'm skeptical about two of the common tendencies in our current GIDE packages:Shipping with visual programming tools.
There's a "comfort factor" thing going on there, yet it seems like users quickly learn to head straight into the text-based scripting when it's available.Built-in physics.
Although the raw collision is usually OK, the physics often get circumvented by power users to achieve a very specific result.
I also think there are some areas that have a lot of undiscovered potential:Underdeveloped event models.
Sometimes I've encountered a need to circumvent the event model, to get certain things triggering in exactly the right order. You don't always want instantaneous, first-come-first-served events; sometimes you want events to have priorities or be "batch processed" later. It's a tricky problem since with too many features, the event model could easily become more complicated than is worthwhile.More domain-specific concepts and tools.
There was a thread here where I talked about doing a timeline language to script things needing a specific timed sequencing without having to maintain your own timers etc. I got that mostly working, but realized I had really overcomplicated it with general-purpose stuff. I'm thinking now that what would be ideal is to mix a good general-purpose scripting language with more limited stuff - besides languages, graphical tools to create tree and graph structures, finite state machines, or even ways to create tuning/profiling widgets(e.g. a slider to control gravity or a gameplay logger to flag levels that test poorly).Scriptable map editing.
My understanding is that a lot of GM and MMF users resort to their own level data formats because the built-in tool doesn't have enough flexibility to fit their game style. This is a tricky area, but even something like being able to write custom "brushes" to paint with is probably going to help here. Alternatively, maybe it's possible to write a GIDE that encourages the "in-game level editor" model - see the above on tuning/profiling widgets.More user-friendly collision.
I imagine that for most games, what is needed isn't really "fast collisions of 1000s of entities" (which when actually used typically leads to a cluttered screen) so much as "easy filtering collision" - stuff that will let you pick out a subset of colliding entities, and reposition them to taste, as easily as a one-line database query. I recently did some pilot work on making a fully hierarchical 2D AABB coordinate model - every box or point attaches to some parent and moves relative to that parent, making cameras, "hovering" objects, projectile spawns, HUD indicators, etc. all super-straightforward to implement. I'm imagining that I could expand on that, and rather than build one physics model, build the tooling around a general collision system to make simple physics behaviors straightforward without forcing you to go entirely into script to fix details.Better entity models.
I tend to end up with a lot of global data structures indexing entities, but with the exception of collision, most of the queries are suited for a "tag" filter - a simple categorization, one index per tag, any number of tags per entity. All the most common queries in games go the same way: "Am I colliding with this thing? Is it the right kind of thing for this action? Now give me all of this other kind of thing so I can update its state according to behavior X." To me, this data pattern largely overshadows the components/inheritance discussion, especially in a language allowing dynamic typing - which is the case for most existing GIDEs. Game Maker comes very close to this model, but it limits you to single Object hierarchies, rather than a complete tagging system.