This is a graphical interface technique for Antock players to alter and create NPC A.I.
The design is up in the air as of yet, as there are many considerations to work around in order to produce something that is aptly fluid, scalable, and appealing.
A vein of the game itself will need to guide the player from simple to complex NPC modification, and provide a bank of pre-built A.I. examples to modify.
Of course, the term "A.I." is not being used in the same sense as the modern buzzword, but in terms of the older gaming sense of NPC decision making.
Approximate Stages of Player Development
The player:
- Starts with simple and guided alterations of existing graphical A.I. models
- Dissects larger functions into smaller and more detailed and layered instructions
- Adds on entirely new functions from a bank of options
- Saves portions of custom A.I. instructions to the player's bank, that can be re-combined and re-ordered
- Completely rebuilds entire NPC A.I
- (Maybe) Graduates to full fledged programming features
The player earns access to features of each new stage by proving proficiency in the last one.
Considerations
Game Development Resources and Projections
If
projections of low developer involvement and time/money constraints
denote an eternal-development project, then it is probably better to
simply produce a feature-set that is vastly simpler altogether. (Because
such eternal projects are tiresome.)
Thus there should be several versions of an A.I. interface in the works, some of which are drastically slimmed down.
There
are several different feature-sets within this A.I. sandbox idea that
require varying degrees of project development. Additionally, many
features only make sense in tandem with other features. Thus, in order
to maintain the sense of a holistic game, varying stages of feature-sets
should be decided ahead of time.
Ideally,
the project's development could be done in such a way that would allow
for some interwoven features to be created initially, and yet still
allow additional features to be added later.
Open Source Games Often Lack Cohesion
Premise 1: A good game has a holistic flow
Premise 2: In a good game, this flow emerges naturally through game-play. It does not feel forced.
Premise 3: With a good game, the way in which features are packaged in development does not directly reflect what makes them jive well during game-play.
In other words, I do not want to confuse describing "features" to be developed, with describing features of game-play. These are two very different things. Most open source games reach a point of developing features, but then fail to refine their holistic flow. The games feel clunky and disparate.
Developed feature sets only work if they are woven together until they appear to create entirely different sets of game-play features from the vantage point of the player.
Examples of Graphical Programming for Kids
I'd like to think of something original and more directly pertinent to the purposes of game-play however.
