Utility AI (Discussion)

First there is article on Gamasutra for reference.
Are Behavior Trees a Thing of the Past? - Gamasutra
I think title is more than click bite, but content is good n my opinion.


I am planning to implement Utility AI based on weights, using ECS. But not making (at least at this point) any visual editor.

Just as from article example.



I have general concept how to approach it in terms of coding.
But here I am not asking about the specific algorithms. Rather doing more research in the topic.
While there is plenty to read and resources available on the net, that I can refer to, I would like simply ask, if you have any good additional references in your opinion, which may be worth to share and read.

However, if you have better alternative to Utility AI, or own point of view, please share as well.

Many thx in advance.

Edit: Unity forum has lost images (again). Had to reupload them.

 

Check out AI For Game Developers by David M Bourg (and another guy I'm too lazy to recall right now). Its got some good introductory stuff to things like Fuzzy Logic, pathfinding, and stuff. It was an easy read.

 

Thx, I found his book on a multiple stores / websites.

AI for Game Developers
Creating Intelligent Behavior in Games
by David M Bourg, Glenn Seemann

Synopsis

Very last sentence says, what you just mentioned indeed.

 

For a working reference (obviously it has been written OOP):
http://apexgametools.com/learn/apex-utility-ai-documentation/apex-utility-ai-scripting-guide/

Mostly the same or similar like Jakob's article, but maybe contain some extras:
https://alastaira.wordpress.com/201...unctions-for-modelling-utility-based-game-ai/

I like the Utility AI-approach, although it's very hard to do it good by a one-man-show like me. Mainly because of the separation of design and behavior. So either you hire a lot of Q&A, DIY Q&A a lot or risk that unwanted emergent behavior will creep up in the application.
Obviously it's mainly because of the added complexity and abstraction. When you make a BT-approach it's more clear when your agent will do what (usually). In exchange Utility can have very fun emergent behavior. But it's a nightmare to test. On the other hand I have very limited experience since the one-man-show thing, obviously. So I may be doing it wrong.

 

Both links are very nice readings.
Second one has more like reinforced few of my concept, adding extra, regarding more type of curves.
Regarding first article, this is something I will come back and read again through. There are few keywords listed, of some I want to get more familiar with.

Yep, this is some of my potential concerns. But way I may try to approach it, is by limiting, of how many utilities graphs I can plot, to evaluate score at once. Then maybe create I create sub system with another Utility AI. Just kind of like Behaviour Tree leafs work. That would be kind of hybrid approach.
However, this concept is not yet decided.

While I like this concept generally, and I may implement it as well at some point, I am not convinced yet regarding expand-ability, in case of my moddable game. On other hand Utility-AI can indeed creep out strange behaviors, if untested graph is being added But BT feels to me more strict. This is my main reason, to hold me back against it atm, toward U-AI.

This is what I am aiming for. Even for the cost of testing disadvantage. In worse case scenario, I will be back to BT.

Definitely for limited time and knowledge, we can do only so much, in certain time span.
I did investigated BTs and U-AI last year already. And multiple sources I looked into, also indicated concerns and points, you just have raised.

 

I'm doing utility AI in my game right now and I've found the book "AI for games" by Ian Millington & John Funge really useful.
http://lecturer.ukdw.ac.id/~mahas/dossier/gameng_AIFG.pdf

 

This is cool. Over 800 pages to enjoy reading

What I found interesting so far, is task time factor ( page 408) and "smell" concept at page 425.
Of course smell can be interpreted as distance to the target, or cover, to decide weather shoot, or hide.

Included good references to games. For example sims.

Overall I like it. Many thanks.

 

Just got a thought, which I would leave it here, so I don't forget.

Since I am focusing on modding aspect to implement Utility AI, I am consider develop spreadsheet as design stage, which will match relevant utility and behaviour. Then generate output data, in form of fields, or maybe Json, containing trend line functions, ready for import to Unity, where algorithms will take care for the rest and execution.

 

this was a real eye-opener. so utility-ai is a decision engine based on the evaluation of animation curves.

made a prototype.
first a script that creates curves and adds keyframes to it in runtime
if want to add a new value on a time that has already a keyframe it's overwritten with the new value

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class AnimCurveExample : MonoBehaviour {
6.  
7.     //ADDS NEW KEYFRAMES TO A CURVE
8.     //AND MODIFIES EXISTING KEYFRAMES
9.     public AnimationCurve curve;
10.  
11.     public KeyCode addK = KeyCode.Keypad0;
12.     [Range(0.0f, 1.0f)] public float time;
13.     [Range(-1.0f, 1.0f)] public float value;
14.  
15.     public int maxKeyFrames = 10;
16.  
17.     Keyframe[] ks;
18.     [HideInInspector] public int i = 1;//for new key 1-9
19.     int x;
20.     bool removed;
21.  
22.     void Start()
23.     {
24.             ks = new Keyframe[maxKeyFrames];
25.  
26.             curve = new AnimationCurve (new Keyframe (0, 0), new Keyframe (1, 1));
27.             curve.preWrapMode = WrapMode.Once;
28.             curve.postWrapMode = WrapMode.Once;
29.     }
30.  
31.  
32.     void Update()
33.     {
34.         if (Input.GetKeyDown (addK)) {
35.  
36.             removed = false;
37.             for (x = 0; x < ks.Length; x++) {
38.            
39.                 if (ks[x].time == time) {
40.                     curve.RemoveKey (x);
41.                     ks [x] = new Keyframe (time, value);
42.                     curve.AddKey (ks [x]);
43.                     removed = true;
44.                     print("key removed " + x);
45.                     return;
46.                 }
47.             }
48.  
49.             if (!removed && i<ks.Length-1) {
50.                 ks [i] = new Keyframe (time, value);
51.                 curve.AddKey (ks [i]);
52.                 print("key added " + i);
53.                 i += 1;
54.             }
55.         }
56.     }
57.  
58.  
59. }
60.  

.
and here's a curves-evaluator example
drag timeExample variable to see highest

 

This is simple and neat.
Many thanks for sharing.

I am glad that topic become useful otherwise.

 

I was planning to use behaviour trees at first, but they are so predictable that I've been looking into GOAP (Goal Oriented Action Planning), which is very similar, but for the player it's harder to predict the behaviour (which in the end is very important, because if the player can predict all the AI actions, that remove some of the fun).

I haven't (yet) looked in depth into the Utility AI, but it seems to me that it may be quite hard to balance for complex systems.
Each time you change a 'weight' in order to make the AI favor one choice in one case because it's the obvious course of action, you take the risk of degrading other decisions the AI may take.
That's the main reason I was interested in Behaviour Trees in the first place, it seems that they can stay manageable even in large and complex systems.


To be honest, I think there's no golden solution for the AI.
I think that the most efficient way to approach AI in a game (if you need some complex one), is to use several tools.
I really doubt that one tool can fit for all situations, so in the end I guess I'll end up with 4-5 different AI tools, maybe more.

For example, Behaviour Trees are perfect to handle reflex behaviours, they are predictable anyway so that's not a problem, and Behaviour Trees are usually quite fast to compute and easy to configure/maintain.
And if you need some more complex behaviours, then Utility AI seem to be more interesting (even if it may be quite hard to balance/maintain).
And probably that none of these algorithm can be used if you need some learning feature in some part of the game, except maybe if you use a neural network to generate some inputs for the Utility AI, which would make it even harder to balance, but may provide some interesting results.

 

Utility AI is interesting concept. There is quite to read about it, as well as any other AIs.
It can be true, that weighting may introduce some balance difficulties. I have not fully designed solution as of yet, but thinking of ensuring of smaller Utility AIs controlling other Utilit AI / brains, or even behavior trees for smaller / obvious tasks. However, Utility AI can be also acting as simple switch just like BT. So one tool may potentially do multiple solutions.

For additional unpredictability, fuzziness may be added if needed.

You can have any type of AI to drive machine learning and vice versa. Question is, weather is needed, or is worth it. Is even harder to maintain, since you need retrain, if anything related is changing. I love Neural Networks, and I got use of it in my main project. But will not be my main brain driver, even I though about it a lot before. Rather I will use for controllers.

 

Not always, sometimes you need the player to know exactly how the AI works.(not in technical terms, but what effects what).
In the game I'm working on right now you have an arena where you send you team of tank-bots to fight other teams, you get to setup the AI and you NEED to know what he will do with minimal trial & error, a good example for this with out writing a speech about my game is "Gratuitous Space Battles".

 

Very interesting article. Behavior trees are good for many fairly simple cases, but having to define the logical transitions between a lot of nodes makes it still very tedious to set up. And the real limitation is that you end up with rigid behavior that doesn't respond to new circumstances unless you explicitly add it to the tree.

The way I look at utility AI, it is like you are creating an electronic circuit with analog signals rather than digital ones. In behavior trees, everything has to be essentially converted to a digital (Yes/No) signal before you can take another step down the tree - and the fact that these are linked together in a hierarchy means that a lot of information is destroyed at the top without evaluating the effect that this might have further down the tree. Whereas with utility AI, the digital signal is only created locally right at the point of each decision, without changing the resolution of the information for some other decision.

I can see that utility AI might be a little difficult to control, because you cannot easily see how a particular addition will be evaluated by a combination of scorers. But even in games where the gameplay needs to be predictable, especially in terms of creating atmosphere - that is, controlling behavior that is visible but not essential to gameplay itself - I think it would do a great job of creating variety and spontaneity.

 

1. Create an editor to manage the connections with mouse + keyboard.
2. Explore Fuzzy Logic for that yes/no binary behavior.

 

The fundamental nature of behaviour trees doesn't have much at all to do with how potential options are evaluated at each node. Its nature comes from the hierarchy structure itself.

I suppose it's not quite correct, however, for me to say that information is lost at each node in a behaviour tree - it's just that to use the information again, it has to be re-introduced at a high complexity cost (via another connection). The strength of a rigid hierarchy is that at each point you are discarding information that came before, so as to arrive at a single decision, so adding connections everywhere, while possible, is not a benefit.

The great thing about utility AI is that there is no hierarchy - each of the decisions competes on its own merits. This means that a decision is never off the table because of a logical mistake or poorly designed connection in a hierarchical structure (and some kinds of connections are very difficult to design well). So much more variety and flexibility is available.

It does mean that sometimes a sub-optimal decision is made, but if it managed to out-score the other decisions it's probably going to be one that makes a lot of sense from a particular point of view.

 

Just thinking about this, I wonder if an AI software would not benefit from having both utility functions and behaviour trees (or even finite state machines) together.

The utility functions would represent higher order thinking/learning, and the finite state machines represent instincts. The more that an AI finds itself doing a particular thing, it creates a finite state machine from the utility functions and relies on that more and more.

This would result in more predictability without totally losing flexibility - but of course the cost is in the time taken learning an instinct.

 

Utility ai is nice because it doesn't dictate the larger design. IMO where most go wrong when first creating ai systems is to try and use rigid design patterns. Spend your time on creating good abstractions for all the underlying systems first. Then think through what data will drive the ai, map it out at a high level devoid of specific design patterns.

Most bad ai makes the same core mistake. It doesn't reduce. It's not working with good abstractions. Which makes it far more complex then it should be.

For example a good combat system is going to be built around a small set of effects. Reduced down to basic elements like direct damage, stun, root, speed increase, heal over time, etc.. You might have 300 skills but they are all just combinations/variants of those core things.

So then your ai deals with those core things. Instead of a behavior tree dealing with all 300 skills, it's relatively straight forward custom logic with some utility ai through in.

Behavior trees and state machines are good at complex logic. Maybe you do end up needing them for some things. But the main goal is really to reduce the complexity. At the very least start with puttting in a simple version of the ai covering the entire breadth just using simple custom logic. And then move to more rigid designs if you actually need them.

It's rare that rigid patterns work everywhere. Different ai sub systems often have completely different flows.


That's just my advice having iterated on how to do ai well over the last decade. I spent more time then I care to admit trying to force square pegs into round holes.

 

Maybe I have missed out, from further conversation, however, as we know, none solution is perfect fit for all. But we can make hybrid AI system, by combining both BT and Utility and other, as @Billy4184 mentioned.

Good thing about Utility AI is, having comparison mechanics. Just as Sims game urge bars example. Or having shooter game, checking distances, vs altitude, vs ammo, vs something else. (see my post #7). BT may not always be good in such cases. Or could become quickly messy otherwise.

 

We are using utility AI for our sim MMO game SEED (https://seed-project.io/) and its a really nice fit for us.

One pitfall we ran into was using ranking too much (basically priority grouping of actions) instead of the "Infinite Axis" model, where each action can have a variable number of scoring factors. If you have dynamic ranking it can often become hard to figure out what factors are changing the rank.

I really recommend digging into Dave Mark's work, including his book and lectures most of which are listed here:
http://www.intrinsicalgorithm.com/works.php

 

I allow myself link the ECS / DOTS forum thread, as is relevant and informative. +is cross reference.
AI in ECS. What approaches do we have?

Btw. @siggigg, seed-project, looks really nice, and appears to be solid made.
Looks like you got a lot of work done there.
Just out of interest, how far you are with Utility AI implementation?
Why did you decide choose Utility AI, over other methods.
Or do you mix different approaches?

I mean, I could most likely answer these questions, but I would love to hear response, from your perspective, if don't mind?

And thx for sharing reference to


http://www.intrinsicalgorithm.com/works.php

 

Quite a lot of work done, a ton left to do

The current Utility AI system in the game is non-ECS and originally done with a few assumptions we now need to expand on. I'm just now starting to evaluate doing a new implementation in ECS based on what we've learned already. The main reason I'm looking at ECS for this is purely for performance reasons.

Utility AI fits our needs really well because of the number of potential tasks to do in the world.. I can't imagine how it would be to write our AI as behaviour trees. There was a time early in the project where we had a mix of utility selection and behaviour trees, but that was too problematic.

 

Thank you for your brief insight. That is interesting practical view on the topic.

 

Hi guys. After a quick google of Utility AI editors I stumbled upon this github page.
https://github.com/apoch/curvature

Interesting... Wonder if it's good to use, seems like it's definitely worth a try.
Has anyone found any other editors of interest?

 

Very cool find! We've done our own editor we aren't super happy about, I'm definitely going to take a look at this.

 

Really nice finding. Thumb up.

To be honest, I have't looked for editors, since I use direct equations.
But proposed editor looks like provide whole bunch of functions, used in game design.

I just copy description from git here.

Spoiler

Curvature is a full-featured Utility-based AI editor and sandbox tool.

The project provides a complete playground for creating, editing, and testing decision-making AI. Under the hood, Curvature uses Utility Theory to model the appeal of various behaviors. Specifically, Curvature is based on the Infinite Axis Utility System by Dave Mark. Curvature builds on the IAUS approach and includes enhancements and refinements developed during work on Guild Wars 2: Heart of Thorns as well as Guild Wars 2: Path of Fire.

Curvature is fully data-driven and supports the creation of a complete AI pipeline, from the core knowledge-base accessed by agents, to the specific considerations that drive the scoring of individual behaviors. The result is an end-to-end solution for modeling and testing AI, including a simple world representation that allows designers or AI programmers to place agents in a virtual space and see how they would choose to behave.

Personally I just plot desired graph in spreadsheet and tweak it there.
But if I don't use it, I am sure someone will find is useful.

Editor seams is not Unity based, but is C#. Wonder how complex would be, to implement it into Unity.

 

Are you guys leaning towards the pre-defined curve models (like the Infinite Axis model preaches) or somehow serializing an animation curve into blob data (or saving keyframes) and evaluating that?

 

At the current, I am using equations.
My goal is to accept any input, just like here for example.
http://www.mathsisfun.com/data/grapher-equation.html?func1=cos(x^2)=y&func2=2x^2-3y=1&xmin=-5.000&xmax=5.000&ymin=-3.750&ymax=3.750


I use sql to store my game data.
So I can type there anything much.

 

I will be aiming for equations also. It seems elegant and is just a bit of maths. I figure if you need a very complex curve, then time to rethink what the AI is doing? We'll see though heh.

I think I prefer an external tool so I can use it potentially even with a deployed game. Just need to export some data and consume it in the game. Alternatively, read directly from the tool's XML save file.

I'm also considering building an excel workbook to do essentially the same thing. There is such an elegance to excel's simplicity heh.

 

Complex curves can be hard to tune. Specially if they are polynomials, and you need take into consideration other curves too. I aim to keep them relatively simple. But is still long journey for me here, as I focus on different feature atm.

While external tool as this editor ap is nice and I recognize benefits, problem of using it, is with different OS. You need build for compatibility.
And mobile devices (if needed) may be out of reach. Or at least will require going extra mile, to make work for them.

That is why personally, I would prefer in game feature.
I think, this way is easier to keep up to date as well.

I like it for simplicity. I often use it, to calculate and test even more complex equations, before even coding into Unity.
Good thing about spreadsheet, it very portable. And can be used as well with google doc.to share +

 

I would tend to agree with this. We currently have a curve editor, but in all cases they are curves that could be expressed easily as equations. I think just having presets for game designers to choose from is all they need

 

Are you planning on letting your players edit AI behaviours?

 

Yes. That is why I want to store it in SQL file.
I want to support modding functionality, to certain extent.
I do store many other data in local SQL already.

Spoiler

Including JS like scripts, which are parsed into ECS representation and can do own stuff in burst.

Spoiler

So adding there math function wont be an issue for me.

But you can do reading curves data on many ways.

 

Just be careful with security implications, scripts in database can be a slippery slope!

 

Thx. It is valid point.
I was working with SQL / PHP DB in past.
These are atm local files in StreamingAssets, not on the server. So any players will have access to them anyway.
But if anything, I will put escape character, when time come, to send to / red from server instead.

 

Been reading this thread... the new Humble Bundle book deal is about AI, so thought I'd mention it here. I have not read any of these books yet, so I cannot vouch for quality. One of the $1 books is Unity specific.

https://www.humblebundle.com/books/artificial-intelligence-deep-learning-books

 

There is 13 days left for offer. But I see for 1, 8 or even $15, there is whole lot of books based in AI topic. Mostly seams python based and many on tensorflow. But I would suspect, whatever quality they are, for such price anyone can get whole bunch of content. Just need time to read

 

Hi Antypodish, if you are still interested by an UtilityAI implementation you can use mine which is based on xNode framework : https://github.com/FBast/xNodeUtilityAI

It is mainly used by my students but maybe you can found something to help you.

 

Hi, highly appreciated.
I will definitely look into it at some point.
However, not sure if I can make any good use of it in my current project, as I use ECS based Utility AI. Yet, others may find it helpful.

 

I think its kinda weird you guys are so focused on architecture.

Utility AI is just a score/sort function.

You really just want to sort, but in order to sort it you need to score it. The functionality of the score/sort really depends most on how you calculate the scoring.

This really doesn't need much architecture at all, the magic here is really in understanding the scoring.

Here's a great video on different ways to set up curves and combine them:
https://www.gdcvault.com/play/1012410/Improving-AI-Decision-Modeling-Through

Chances are pretty good that in most games, your ai processing in total should probably be less than a few hundred lines of logic IMO. Calculating the score itself can become complex, but shoving the data into a comparable form, scoring it, then sorting it really shouldn't be a major consideration. All you really need to do is pair a score with an action and dump those pairs in a list.

How you represent the action in code will vary from game to game and should probably just be whatever is easiest at the time of writing.

 

It is normal to investigate different approaches. It is way to learn. Some solutions may be overkill for what we need. Other are simplistic and sufficient. For example @dibdab solution in earlier post, shows minimal and functional Utility AI.

I look into anything you guys post, so I can adapt best fitting solution. And of course, others seams finding it useful as well.

Thx.

 

What I'm saying is not so much that you shouldn't investigate, but that it seems like the focus here is on architecture not the real meat (scoring).

In essence, when you boil everything down, Utility AI is just score and sort.

Code (CSharp):

1. var list = GetListOfOptions();
2. foreach( var o in list ) o.CalculateScore();
3. list.Sort();
4. var best = list.Pop();

At core, this is what Utility AI is. More useful investigation of the subject is digging deeper and deeper into

CalculateScore()

or how to realistically break down your options

GetListOfOptions()

, not what data types to use or how to rejigger this process.

 

Since I got things already figure out, I may miss something obvious to me in this discussion, which you try to indicate. Probably just matter of interpretation.

On your proposed video, around min 25, there is example of calculating cover score.
In min 49, there is talk about using hysteresis and random noise.
Then there is also time based score calculation, etc.
Of course, I just skimmed vid (2009) through, since it is 1 hr talk and I read and seen many similar of such. It has good content however.

These are nothing new to me personally, but may be interesting / relevant to others.
But is that what you are referring to, by calculating score?

 

All Utility AI does, is convert game state to numeric score and sort. If that score is based on literal values, curves, or far more complex data depends on the needs of the game. The challenge in building good utility AI is figuring out how to transform game state into score in order to produce the kinds of results you're looking to produce.

Having a curve represent the potential value of 'cover' for example, is all nice and good - but the hard part isn't figuring out what type of curve to apply its figuring out how to score cover in the first place.

The 'cover' score should be another layer of score and sort, where each of the cover locations in a region are identified, scored, and the results are sorted for selection. That's the real meat in the system. Not choosing between cover and reload, but figuring out what cover is available in the first place, and converting those cover points to some kind of score.

Some games that have hardcoded "cover" points will have an easier time. Tile based games where options are limited make this easier yet.

The other hard (sometimes nightmarishly hard) part is testing, debugging and re-evaluating your choices and your weighting. "Did my scoring routine produce the actual game behavior that I wanted?" and dealing with situations where it doesn't produce desirable results requires some really clear process.

 

This is something project specific. Or I would say character (agent) specific. There need to be some factor, which determines tendency of taking cover, by being aggressive, or defensive. Because these are most likely time dependent, it should be introduced into design and further tweaked, as needed. Same as for BT. Only that U-AI provides more fluid behavior. Hence I don't see really point, discussing details, based on how to calculate cover action for example. But feel free to correct me, if I am mistaken.

Finding cover nearest, most suitable cover, is just additional mechanics, on top.

This is something I touched upon in January. Also mentioned in your vid.

Each leaf node, can have some value factor, which multiplies by result of child node. And some curve of course. What kind of value, again, depending on the design.

This way is possible to test each node leaf, by forcing desired value.
However, difficulty mentioned,

we also have mentioned before.

So yes, there is potential risk involved indeed.

But in some cases, fun behavior may be more important.

 

Yes, these are all deeply project specific. It's also often where most of the actual work is (the stuff that will eat most of the time).

I do not think that most of the architectural decisions (especially generalized decisions) will have much meaningful impact on the vast majority of game ai.

The project specific details are where the meat is, and to discuss the subject while trying to skim past those details isn't particularly useful IMO.

For example, even when sampling the environment, the pathfinding systems you use and the environmental system will tend to have dramatic consequences on how you even begin to approach AI.

Another example for sims like games, the majority of the AI work is actually being done in the item design not the agent logic (at least with the original, i have no idea how the modern sims titles work).

And in many other genres the same is true. The bulk of AI work is often baked into the level design, environmental design, etc. Specifically designed cover points like in Gears of War are a good example.

 

Yep, I did sims modding in past
However, some source would be nice. But here it is.
https://team.inria.fr/imagine/files/2014/10/sims-slides.pdf

Smart Object paradigm

Spoiler

Object script

Spoiler

The Happyscape - Smart Terrain

Spoiler

So based on above, this is already architectural choice, of splitting AI based on sim and object driven AI. Is part of AI architecture, of how it communicate between agents (sims, objects, environment, etc.). That can influence, weather I want simple switch statement, U-AI, BT, ML, or other.

Sims (2) objects logic for example, had simply IF conditions. If is selected, do if A > B then do C, or do D, etc.
Like for example come here, if not occupied and can interact. Added to queue. Priority AI agent, decide on orders of task. Some my take higher urgency, like toilet, or sleep. Path finding Agent do evaluation, if action is reachable and possible. Then execute, or cancel. Once object is reached, do logic, i.e. play animation, or / and change some values.

But yes, it is nice approach, is scale-able and mod-able

Edit:
Just extra, from GDC talk, split into sub objects (U-AI) example.

Spoiler

Edit2:
The Sims Design Docs
https://www.gamedev.net/articles/game-design/game-design-and-theory/the-sims-design-docs-r4727/

 

I'm not sure what exactly you're responding to or why. It seems that you're basically reasserting your knowledge base.

"Yes I know this" more or less sums up your response which is really great... but is also ultimately kind of irrelevant.

 

Well, to few of your paragraph at the same time.
Including part, that some decision making is located on objects.

 

TBH, I didn't know anything about the internals of the sim games, from the raw gameplay you can tell that the bulk of the work was in the objects. That they chose a design that was centered around the objects is good design, because it fits where the majority of the work was.

They could have chosen a different architecture and still, at the end of the day the majority of the work would still be in the objects, even if their architecture was less object centric. If that makes sense. Thats just how the game itself was designed (regardless of the architecture of the internals).