next »

[Triplefox]

Introduction

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.

[increpare]

A lot of the things your'e talking about already are quite well explored in Unity/UDK I think.  I'll give an outline, as you seem to be unfamiliar, but would certainly recommend familiarizing yourself with both of them if you want to work on your own stuff.

Underdeveloped event models.

Unreal has a pretty ok event model, but I have experienced it becoming a little cluttered, so...

More domain-specific concepts and tools.

UDK has an absurd number of special-purpose tools (lens flare edtior/&c.), in unity these tend to come more as third-party add-ons (angryant made a HSM editor, say).  Though none for constructing particular abstract data structures.  Both UDK and Unity make it *very very* easy  - it's pretty much the default behaviour, for classes to expose their variables to the editor, so they can be inspected and altered when you're playing through in the editor.  Unity (not sure about UDK) offers very easy tools for drawing debug lines/circles/&c. (calls them 'gizmos'), that can help for figuring out what's going on when raycasting, say, or doing other more geometrical operations (rather than having to gawk at vector coordinates and figure out what's going on that way).

Scriptable map editing.

UDK has a special visual language for this, kismet, in Unity it's the same as scripting everything else.

More user-friendly collision.

Unity place objects hierarchically.  In addition (not sure about udk), unity has physics layers, so you can instruct the engine which groups of objects to collide with which other groups of objects - it works out pretty well.  One can also tag individual objects, or assign them to layers, so they can be manipulated in script on a per layer or per tag basis.

Better entity models.

Unity only allows one tag per object (there's a plugin to allow multi-tagging, though) so the easiest way to get this effect is to add dummy components that you can easily iterate through.

"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."

Unity has more of an event-based setup, so you're more likely to cast things in terms of "have I just entered/left area X?".  Queries as to whether you're inside or outside of somethign at runtime aren't idiomatic to it (to my knowledge).  Not sure about UDK.

[moi]

This this the most elegant "UDK sucks, Unity rules" post I've seen in a while

[PGGB]

This this the most elegant "UDK sucks, Unity rules" post I've seen in a while

Why? He mentioned both UDK and Unity as positive examples.

[Triplefox]

Update on this: I decided to focus on building a highly reflective, image-based system like Smalltalk, only with an explicitly game-centric core. The engine is scene oriented and keeps the entire scene in an easily serializable form at all times - so savegames are gonna be really easy. The event system contains timing information, and has fine-grained ordering using buckets(e.g. pre-frame, spawn, despawn, render are all different event buckets that you can post to) but doesn't use listeners, it relies on "iterate through tags" for the roles usually occupied by listeners. More on that next paragraph.

Entities are primarily based on exploiting dynamic types(big property field), but also contain a unique id and tags. Tags combine components and indexes into one thingy - in both cases the key idea is that you can iterate over them to get all the tagged stuff. When added or removed, the tags have the power to manipulate data structures outside the entity(e.g. scenegraph, collision). The outside data structures are aware of the entity id, but serialize separately and don't usually directly deal with tags or the entity's property field - they are pretty "black boxed" from the rest of the gameplay layer. (This is an area I'm still sorting out details of.)

You'll be able to switch between an "edit" and "play" mode - two copies of the same scene, with "play" always being based on "edit." The main difference is that one will post events to update the world and take player input, and the other won't and will show all the editing stuff instead. For both sides, scripting language and REPL will be included to let you script new events, do world manipulation operations, tune stuff, and build more tools on top of the built-ins. One "will happen someday" feature building on this structure is a mechanism to make changes on both the "edit" and "play" sides simultaneously, so that tuning the in-game stuff is super-simple.

And that about covers it. The basic toolset will assume a 2D game with a scrolling camera, sprites, tiles, and rectangle collision. You build entities by applying tags to them, and then writing events to control the tagged stuff. When extending the engine's gameplay layer, most of the time it can be done by adding tags and events or throwing more stuff into entities' dynamic property fields. If something more sophisticated(physics, inter-scene persistence) is needed, the engine core can be extended with more externally serialized data. So it will feel a bit low-level at times, when hooking up the basic render/position/collision relationships, but be extremely flexible otherwise.

It'll probably take a while to build.