Is it a good idea to simplify a character-driven game engine to the point where it's unnecessary to learn scripting/programming?

Question

I remember, and I still think, that one cannot even make a prototyped 3D game to test just simple behaviors without using gigantic tools like unity or knowing extensive C++ programming, design patterns, a decent or basic 3D engine, etc.

Now I'm wondering, since I know programming, whether I'm even more lucky than the ones who need to learn programming before knowing how to make something. Even scripted engines such as Unity are not for kids, and to my sense they tend to dictate their ways of doing things. This is not the case with engine like Ogre or Irrlicht.

Now I'm thinking that character-driven games occupy a big part of the game market. Do you think it is a good idea to make a character-control oriented game engine which only allows building AI to the exclusion of anything else?

When I say prototype, I also mean "generic" in the sense that one can quickly choose from a set of gameplay parameters such as the scene manager, the camera POV of the player, the controls, some very basic collisions/physics, and integration of basic steering (OpenSteer for example). The main idea is to make an AI sandbox but in 3D, so it can be demonstrated without the 2D constraints (and also make it more fit to prototype in 3D for a 3D project instead of 2D).

Answer 1

I really like the under-appreciated game engine in Blender. (http://www.blender.org) The sensor-controller-actuator model is really easy to follow even for non-programmers, and it's possible to make a reasonably complete game (move an animated character, fire a weapon, destroy targets, show score, keep track of health, reset level or move to a new one) without any programming at all.

Of course, some things do require programming (especially getting mouse input for an FPS.) However, blender already incorporates Python, and Python scripting is tied very nicely into the model so you never need to replace sensor-actuators with Python. Instead, you just switch from a very simple 'pass-through' controller to a complete Python script that can read all the sensors in the scene and pass control to all actuators.

It is quite feasible to create a game prototype in a few days in Blender (I did it for a project at a local children's museum last year.)

Of course, nothing replaces good-old programming know-how, and eventually, a developer does need to understand programming.

Answer 2

Regardless of the input mechanism, at the end of the day you still need to set up some kind of way of telling the game what the logic is. "Scripting" is a good colloquial term for this. So basically I disagree with the assertion that you can simplify something to the point where you don't need to know "scripting".

That being said, not all scripting needs to be done with a text-based programming language. There has been some work (but not a lot) towards making a visual scripting system. Unreal's level scripting tool, Kismet, is a pretty good example of one. Source engine has a similar mechanic, but it uses entities in the world instead of on a flat plane.

Basically you have boxes that you drag around in some kind of environment that have inputs and outputs. If you need some kind of branching output you have some box that have one input and multiple outputs. Those outputs can go to actions that have data tied to them (i.e. "move to this point", "say this line", "ask this question", etc.). It's usually a significantly lower barrier to entry to get something up and running in a visual language since you don't have to know keywords or syntax, you just have a limited set of boxes to pick from which all have defined behaviors, and you just connect them together.

However it's my opinion that visual scripting engines aren't really worth the trouble. You need to be able to think structured and logically in order to successfully tell the engine what you want to do. If you can think like that, making the jump from boxes with inputs/outputs to basic branching statements and function calls in a scripting language isn't that big of a deal. In fact, after a while the visual part of it is probably a hindrance. Plus, it's a lot more work on the engine side of things. You have to do things like implement undo, copy/paste, maybe have some higher level features for organizing your scripts. With a text-based language you can leave all that to the IDE.

Answer 3

It will in general be a trade off. If you truly want to remove the need to do any sort of scripting you are generally going to be talking about making some sort of an interface that will piece the scripts together in the background (or just connect logic objects or what not). There are entire games where that is the entire point to them, a well defined environment where you drag and drop functionality to see how it interacts with it.

At the end of the day however, it will always be a trade off.. The more simple you attempt to make the interface the more simplistic the things created through that interface.