Esoteric Update #130 - Why The Goal-Base AI Is Important

From talking with a few people, I get the impression that largely what I'm doing with the game right now isn't particularly well understood. Let me try to fix that. This might get a bit lengthy, and as such, you can feel free just not to read this. If you are interested in what I'm doing on a deeper level, though, I invite you to read. We'll start with a bit of background information to explain some of the issues I'm fighting with, then get to the AI and its place in the game.

1) Ill-defined problem

There's a pair of two commonly used terms in AI - the well-defined problem and the ill-defined problem. First, it's the case where we have a clear input, output, and either a clear method for bridging those two states or at least enough information to employ tried and tested solutions to do so. This is a typical case for video game development since the reality of it is that video games rarely used untested technology. Only a minority of video games will implement groundbreaking code or develop custom solutions to previously solved problems. Often, they lead the next generation to adopt those solutions as well. I'll stop here for a moment to say that it's in no way my intention to do this. I just want to put the problem into the perspective of video game development.

Ill-defined problems are those problems that are not well-defined. Three-dimensional graphics were once impossible to tackle for video game developers. Until someone did, and that changed. Until that moment, though, the problem remained ill-defined, without a clear solution that a programmer could implement.

Sometimes we can be unsure as to what the input or output is even supposed to be. Sometimes we can, but the path to connecting the two doesn't present itself easily, or perhaps it does, but the computational power needed to accomplish it without heuristic simplifications places it outside the realm of feasibility.

The problems I deal with in my design are primarily ill-defined. The ones that are not I can quickly solve on the spot. After all, I have the combined knowledge of the Internet backing me. If I can pinpoint something as representing a known problem, I can find the solution. I've done that with many things. Having full access to HTML/CSS/JS inside the engine, using a base Eliza implementation, or even having the capacity to read JSON data results from this. Standardised solutions for well-known issues. Sometimes it's a bit less explicit. The algorithms implemented in the 0th order reasoning engine (that's the KB module inside the game) are well defined, in theory, but required my own implementations to work the way I needed them to and operate inside the engine without hardcoding.

Then there are problems where tracking down an existing solution is impossible, or all the research I perform only turns up partial solutions that don't meet my expectations. Those tend to coincide with ill-defined problems. And when they happen, well, there's always a chance to be wrong or make a misstep. Those are fine as long as I can remain adaptive enough to adjust the course towards better solutions. In the process, I've created many of my own solutions to problems. The ones I'm the proudest of turn out to solve a more significant number of problems than what called for their implementation.

Again, to stop for a moment, I want to be clear that this is not the reason why the development of the game is taking as long as it is. The reason for that is simple, the time I dedicate to the game is the time I can, there's not much of it, and the few people who support me are only capable of helping with so much (even if Dolly's been an excellent help recently). There are just some things only I can do, and finding someone else to do them with me has so far been very, very tiresome and unsuccessful.

Anyway, let's get back on track. Sometimes when a solution turns out to be very powerful, very useful to achieving my goals, I might not initially see that potential. Call it tunnel vision if you want, but I prefer to call it emergent complexity. What I work with is complex enough almost to live its own life; things not meant to interact turn out to be perfect fits.

This time, it's different.

I can already see how many different problems can be solved with this. It's easy to focus on how I seem to be working on something related to sex-scenes, but it's just one aspect of a much larger system. Not only is does this present itself as a solution to an ill-defined problem far more potent than anything I've thrown at it before, but it also affects the whole structure of the game. And while going back on earlier development (for example, deprecating much of the sex scene code) doesn't feel good, what I see for the future of the game with this solution brings me to a conclusion that...

I have to go on with it.

2) Modal vs amodal design

There are two opposing ways of developing interfaces for games, the modal and the amodal approach. While the whole concept is related to amodal perception, I'm not going to go there, and we'll just talk here about the practical implications.

In essence, a modal interface has different contexts in which different functionality is exposed. It's, to be fair, the generally encountered kind of interface. You have a view with specific options; you go to a different view to get to other ones. This is the main gameplay interface; this is your inventory; that's the map. In short, that's modal design. It's fine; there's nothing wrong with it.

The opposite is to have a single context. You get a single view with all of the different options. For you to use, at any time, in any way you want. Not all of them will work all of the time. It's up to your judgement to figure out when and how to employ them. That's part of the gameplay. There's a much smaller subset of games that uses this approach. Actual rogue-like games and interpreter driven adventure games will commonly fall into this category. Even mostly amodal games can contain a bit of modality too, sticking to one or the other isn't the point. It's more something that naturally comes from decisions made by the developer.

Most of my game is modal, and that's not necessarily a good thing. The driving force behind it is a recurrent state machine. The nodes and the individual machines create their own contexts from which different options are accessed through custom-designed interactions. In many places, this makes perfect sense; the locations, the menus, the books, the Internet, a lot of it is well served by this approach.

But then there's stuff that just isn't. As a returning theme, the sex scenes are among those. While I had a good shot at building sex scenes through recursion, it made the flow too awkward. The current implementation lacks flexibility, both in narrative terms and in terms of dynamically building interactions. It's all very compartmentalised into specific states with specific options. There's an oral sex context, but that context, by design, allows for oral sex-related options to exist there for the player to use with the NPC.

It's a solution that works, but in the end, I wouldn't say I like how it works.

This is why I started working on this new AI. It moves the sex scenes from the realm of modal design towards an amodal approach that allows for scenes to more naturally transition between sex and everything else. In the current (modal) method, the characters are either having sex and doing things related to sex... or not having sex and doing everything else. Why not give the game the capability to mix these things too?

That's just a side effect though, the intent stood, initially at least, behind building a framework where elements of a sex scene can be selected not based on an arbitrary context, but on what is logically feasibly for the characters to do. Thus, allowing the game to make proper use of things like the clothing system and preparing the ground elements of the game that have yet to be implemented, like bondage.

3) Goal-based reasoning

But goal-based reasoning is a pretty broad concept. While I initially envisioned this as a way of sorting out the sex scenes, I've put a fair deal of thought into other places where it fits in.

In the end, what do we do all day if not set goals for ourselves and see them through? Then for each goal, we decompose it as a series of smaller tasks, up until the point we can grasp to completion each of our objectives. In a way, it does a lot to simulate how people act, and as such, I have an inkling of hope that it can also be used to make video game characters act more like people.

I'm saying that this approach can be used to govern the daily lives of characters, their schedules, interests, the decisions they make, and how they make it in a way that distinguishes between different NPCs. And this is another place where it helps me solve a problem where previously, my approach's modality cut me off from implementing flexible solutions for this.

The extent of this became apparent as soon as I did the test implementation. It isn't anything special. Just a specific configuration of this AI that carries a simple task - plays a game of RPS while keeping a tally of the points. It's not even particularly good at it. After all, writing a good RPS AI is a well-defined problem; trying to reinvent the wheel wasn't my goal here. It was purely just to test how it feels to work with the AI's framework. It was a surprisingly positive experience. One that made me realise that, indeed, this AI still retained access and far more flexible access to every tool I wrote for the game so far. It was capable of using any of the other AIs to solve subproblems in particular.

This was another problem in the previous, modal approach, the need to set each of the tools and solutions within the context of the current perspective. It wasn't hard, but it was tedious and provoked anxiety about premature implementations. That thing that, due to rushing development in the wrong direction, caused so many problems over time.

But, to get back on track, let me summarise and simplify what I want to convey here. By all accounts, due to the tests I've done so far, the AI I'm currently working on (or rather already wrote, it's not the AI that's the problem; it's the data it needs to function) is capable of becoming the uniform backbone of most, if not all, decision making in the game. Additionally, it can also still utilise most of the code I've written so far and only deprecates code that I want to replace with it, to begin with.

But there's an issue, as there tend to be. Growing pains, basically. The initial data needed for this whole system to take off. And that data is somewhat daunting to work on, but so far, it's not going badly.

I've made quite some progress in mapping out how characters can physically interact with each other, the basis by which I can impart a sense of kinaesthesia upon the characters. So to say. Or a skeleton to which I can pin further interactions, especially since there are ones, right now, that do require some degree of body position awareness. Hugging, kissing, and then transitioning towards sex or a friendly/loving conversation on the sofa. It acts as a significant limiting factor, in addition to character relationships (which are implemented b.t.w.) dictating what the NPCs might be comfortable with.

But with the graph's visual nature, it's easy to assume it's the focal point of the whole operation. It's not. It's just a foundation. And I need a solid foundation for what's to come after.

Well, that's all I have to say. I hope it explains things!