OSDev.org

• "freeze everywhere in the world except where the player is"- platformers controlling exact enemy placement when the character arrives
• "max. limits on the number of entities"- RTS resource and unit type limits
• "suddenly become mature in an instant or never age at all"/"flame-throwers being used in book shops where nothing catches fire"- carefully planned but mostly-indestructible level design can be more fun and immersive than "oh lol we can make everything destructible" level design, unless "destroy everything" is the point of the game
• "medical miracles"- fast-action FPS tactics, RPG spell and item tactics
• "limited to the size of a small town"- storytelling in games like Portal, or even smaller areas like in Gone Home, or even smaller areas like Tetris

Rusky wrote:There is certainly an element of "same tired old crud" in the games industry, but trying to cramming every game into the box of a fully simulated world with unlimited attention to realism is the whole reason for that problem in the first place. Many of the best games of all time succeed not in spite of these "problems" but because of them. For example:

• "freeze everywhere in the world except where the player is"- platformers controlling exact enemy placement when the character arrives

Rusky wrote:

• "max. limits on the number of entities"- RTS resource and unit type limits

Rusky wrote:

• "suddenly become mature in an instant or never age at all"/"flame-throwers being used in book shops where nothing catches fire"- carefully planned but mostly-indestructible level design can be more fun and immersive than "oh lol we can make everything destructible" level design, unless "destroy everything" is the point of the game

Rusky wrote:

• "medical miracles"- fast-action FPS tactics, RPG spell and item tactics
• "limited to the size of a small town"- storytelling in games like Portal, or even smaller areas like in Gone Home, or even smaller areas like Tetris

[/list]

Rusky wrote:Like I said before, making it possible to remove these limits is good, but forcing their removal is not. Competent game designers will just add the limits back, until they want to create a specific game mechanic. There's the obvious "ooh open, living world" one, but that's not for every game. There are other reasons- gradual growth, persistent wounds, realistic space navigation, and destructible terrain have all been the basis of great games that break all the other rules of "realism."

Brendan wrote:rather than saying "Supporting books that burn and babies that grow is going to cost too much developer time" developers can say "We can use existing assets for books that burn and babies that grow and reduce the developer time".

Rusky wrote:

Brendan wrote:rather than saying "Supporting books that burn and babies that grow is going to cost too much developer time" developers can say "We can use existing assets for books that burn and babies that grow and reduce the developer time".

Back to my earlier point, no competent game developer is ever going to just pull in a common chicken asset, or a common burning book asset, or a common growing baby asset. They might leverage distributed computing to get the capability, but I guarantee they would handle the actual asset themselves.

Rusky wrote:At best your plan will create a kind of sandbox world with a community that creates the equivalent of in-depth mods for it. It will not affect how other games are made.

Brendan wrote:they don't need to create models for cars, or create buildings, or do animation, or handle AI, or figure out physics, or write a quest system, and only need to do story writing and "glue".

Rusky wrote:

Brendan wrote:they don't need to create models for cars, or create buildings, or do animation, or handle AI, or figure out physics, or write a quest system, and only need to do story writing and "glue".

This is exactly how you get "just the same tired old crud from 10 years ago (just with slightly better graphics than last time)," only the tired old crud will also be derivative and generic like 90% of the games written by "high school kids slapping it together in their spare time over 6 months," using all the pre-existing models and physics and quest systems that already exist.

Rusky wrote:If you look at the easiest-to-reuse engines, like Unity or GameMaker, there is an overwhelming tide of terrible, unoriginal "me too" games.

embryo2 wrote:

Rusky wrote:If you look at the easiest-to-reuse engines, like Unity or GameMaker, there is an overwhelming tide of terrible, unoriginal "me too" games.

As I see it, Brendan wishes to limit the "overwhelming tide of terrible...". But employs an approach "I will control everything". Such approach won't work (and Brendan sees it), so he adds some committees and other processes that help to elaborate the system. But the public work (all those committees) is not the area where Brendan excels. So, the only way is still "I will control everything".

The "overwhelming tide of terrible..." is the society problem, but it is seem to me that Brendan wants to fight it with his developer skills only. Also the "really good OS" or "really good game" is the society thing. But some technical solutions can help the society to minimize it's problems, so, may be Brendan can create such a tool set and finally really help to decrease the "overwhelming tide of terrible...".

Rusky wrote:If you take a look at the most interesting games, there's not much correlation between how much they reused existing tech. On one side, you have all the story-heavy games from places like BioWare, which just reuse existing engines. On the other side, you have a lot of indie games like Minecraft or Braid that were built from scratch.

• a generic renderer (capable of supporting "grids of blocks", as discussed previously)
• a generic inventory management system for player inventories, chests, etc
• a generic recipe system to determine which items/ingredients get converted to what using which method of conversion (heat, redstone level changes, crafting)
• a generic 3D sound system
• a generic "entity stats" system (for tracking health, hunger, XP points, current potion effects, etc)
• generic timer support (provided by kernel)
• a generic deterministic random number generator (too small, cut & paste that)
• either a generic electronics simulator (better) or something custom designed to match how crappy/quirky redstone is in the real Minecraft
• either a generic NPC AI system (better) or something custom designed to match how crappy mob AI is in the real Minecraft
• either a generic combat and player control system (better) or something custom designed to match how crappy combat is in the real Minecraft
• either a generic physics system (better) or something custom designed to match how crappy physics is in the real Minecraft
• either a generic weather and day/night system (better) or something custom designed to match how crappy it is in the real Minecraft
• custom "glue" to handle updating/deleting blocks based on the other systems, making saplings instantly become trees, etc
• custom code to generate new chunks from the world seed
• custom code to handle saving/loading data
• custom code for the pre-game user interface and in-game user interface
• custom meshes and textures for mobs, player, blocks (and sky if you want it to look the same)

Rusky wrote:If you look at the easiest-to-reuse engines, like Unity or GameMaker, there is an overwhelming tide of terrible, unoriginal "me too" games. This says to me that your hypothesis, while it makes intuitive sense, is not true. A rising tide of easy reuse raises all games, and pulls more crappy ones above the threshold where they can exist.

This isn't to say easy reuse is a bad thing, just that your style of reuse isn't going to help games. Your style of reuse makes mod-style games easier, but more powerful tools and engine reuse are what make good games easier to make, because good games won't be able to reuse your chicken AI.

MessiahAndrw wrote:Your "process per object" is very much Agent-oriented programming. I thought I came up with the idea back in university until my professor told me that it has already been done.

MessiahAndrw wrote:The main problem with this approach is that it's not the most efficient way to handle process-intensive agents. For example, your physics agent tries to created a thread per core, rendering agent tries to create a thread per core, etc. But suddenly, because your have more than one worker thread per core, the OS might end up assigning most of your worker theads from the same agent to theat same core, losing the parallelism advantages.

MessiahAndrw wrote:The other disadvantage is that game developers like to keep things in lockstep (which is especially important in network games - think Age Of Empires - instead of broadcasting what thousands of little simulated people are doing, it just sends the high level user actions across the network, with every client running a deterministic simulation in lockstep.)

MessiahAndrw wrote:The mainstream approach to scalable parallellism in high end game engines today is the thread pool pattern. If the game is running on a 6-core computer, then 6 worker threads are created. There is a pool of tasks, and if a thread isn't processing a worker thread grabs the next task to be done.

Simple example: You have 100 objects in your game with their own update routine, so at the start of the update loop you add your 100 update calls to the task pool, and let the worker threads go crazy.

MessiahAndrw wrote:Also, about the idea of having a library of objects is the motivation behind Unity's Asset Store. You can import high quality trees and road pieces to build a track, import a high quality car model with physics and controls already programmed in, import a Car AI library, slap on a nice menu, and you have a realistic car racing game in under a day.

Brendan wrote:First; you're assuming that all threads consume as much CPU time as they can. For most threads this isn't the case - they'll sit idle most of the time waiting for a request/message to arrive, then handle that request and send a reply, then go back to being idle. If 1 thread handling 100 requests per second uses 10% of one CPU, then 100 threads each handling 1 request per second uses 10% of one CPU.

Brendan wrote:

MessiahAndrw wrote:The mainstream approach to scalable parallellism in high end game engines today is the thread pool pattern. If the game is running on a 6-core computer, then 6 worker threads are created. There is a pool of tasks, and if a thread isn't processing a worker thread grabs the next task to be done.

Simple example: You have 100 objects in your game with their own update routine, so at the start of the update loop you add your 100 update calls to the task pool, and let the worker threads go crazy.

Yes; this doesn't scale to 2 or more computers and only does a crude/broken approximation of continuous time.

// When Chicken object was created:
Timer.createRepeatingEvent(30, myChicken.think);

function Chicken::think() {
   // runs 30 times per second, Chicken's update logic goes in here
}

// inline handling
myChicken.onMessage("hit with arrow", function(string person_who_hit_me) {
    SpeechBubble.above(myChicken, "Ow, don't hit me " + person_who_hit_me + "!");
});

//////////////////////////////////////////
// from some other process that has a reference to our Chicken
//////////////////////////////////////////
// send a Chicken a "hit with arrow" message from "Andrew"
someChicken.sendMessage("hit with arrow", ("Andrew"));

// maybe our Chicken interface can expose some events we can listen to:
someChicken.onDeath(function() {
   // oh no! our chicken died!
});

MessiahAndrw wrote:

Brendan wrote:Yes; this doesn't scale to 2 or more computers and only does a crude/broken approximation of continuous time.

You're right that it doesn't, at least not alone. I like the actor model for OOP and messaging, but what if the actors use tasks, rather than threads, to handle messages and do processing? There should be no 'wait for message', a task will be created when a message is received to process that message. There should be no 'sleep for x seconds', you'd just tell the timer to send you back a message after x seconds, and that'll create a task to process that message. I'm thinking this task/messaging system could be very light weight, with little more overhead than a function call. Sending a message is as lightweight as adding a task to the task queue, except that task may be in a different process.

In pseudo code:

Code: Select all

// When Chicken object was created:
Timer.createRepeatingEvent(30, myChicken.think);

function Chicken::think() {
   // runs 30 times per second, Chicken's update logic goes in here
}

// inline handling
myChicken.onMessage("hit with arrow", function(string person_who_hit_me) {
    SpeechBubble.above(myChicken, "Ow, don't hit me " + person_who_hit_me + "!");
});

//////////////////////////////////////////
// from some other process that has a reference to our Chicken
//////////////////////////////////////////
// send a Chicken a "hit with arrow" message from "Andrew"
someChicken.sendMessage("hit with arrow", ("Andrew"));

// maybe our Chicken interface can expose some events we can listen to:
someChicken.onDeath(function() {
   // oh no! our chicken died!
});

If you have a reference to a process/service/actor, this model will work whether it's on the same machine or across a network. A task will be created and added to the task queue on the machine the actor is running. This system should scale across cores and networks. This Chicken application can be in our process, another process, or another machine. It also makes it easy to program parallel algorithms within the same actor (a raytracer can divide the screen into tiles and call a task per tile), and all these tasks would be mixed together with all the cores trying to churn through as many tasks as possible.

Some technical problems with implementing this model:

1. What if the actor disappears? The process quits, the network connection is cut? Potential solution: In an asynchronous API, your function call to send a message could simply return 'false' (as actors would communicate back by sending a new message, rather than return a value through the function call) or throw an exception.

2. What about the overhead of constantly context switching between processes as you rapidly switch between tasks? Still thinking about this one, but I'm hoping to make it relatively light weight by relying on software isolation rather than hardware isolation. But would you not also be rapidly context switching in any event-based system that sends messages then sleeps? Maybe we can set some kind of 'processor affinity' with a task queue per core, and only if a processor core doesn't have any tasks in its own queue it steals tasks from another core's queue. In this approach, if you have two heavy weights (like a physics engine and a rendering engine) that are always processing away their tasks would gravitate towards their own processor core.

3. What if a task gets stuck in a loop or is taking a very long time to process? Could it freeze the operating system by preventing other tasks from running? Since most tasks are light weight and fine grained (event handlers that do one thing, or a single step in a recursive algorithm), I don't this won't be an issue for most cases. However, there will be times that a buggy task gets stuck in an infinite loop or you have a long running algorithm. I think the OS should easily be able to detect this (e.g. it sees a task is running for more than one time slice), and can turn that task into a traditional preemptive thread. This could happen transparently, and the programmer only needs to think in the abstraction of parallel tasks.

4. What about something that maliciously spawns lots of tasks and fills the task queue up? I haven't solved this problem, but it's the same as an application sending lots of messages or spawning lots of threads in another other system. I'll have to think about this.

What do you think, Brendan?

    do {
        if( check_for_message_without_blocking() == GOT_MESSAGE) {
            handle_message();
        }
        finished = do_some_more_work();
    } while( !finished );

    while( true ) { 
        get_for_message_with_blocking();
        handle_message();             // Adds request to an internal queue according to request's priority

        while( (next_request = get_highest_priority_pending_request()) != NULL) {
            do_request(next_request);
            while( check_for_message_without_blocking() == GOT_MESSAGE) {
                handle_message();     // Adds request to an internal queue according to request's priority
            }
        }
    }

Brendan wrote:And yet if you actually think about breaking it up into pieces, Minecraft becomes:
...
I'd estimate (depending on how you split it up and whether you want "better" or "clone", and whether you want to split it into more processes to give to OS more flexibility distributing load) about half the code doesn't need rewriting.

Brendan wrote:For Braid, I don't know (I've never seen it); but the Wikipedia page makes it sound like a generic platform game and a generic "jigsaw puzzle" part; except the "glue" records where things are while you're playing and allows that data to be replayed.

Brendan wrote:Basically; I want a massive simulated universe of many worlds acting as a (multi-player) sandbox game; where each player chooses which role they want to play within that universe (from small things like being rat catcher in a specific city on a specific planet, to massive things like trying to achieve universal domination by conquering worlds) and where any player can switch between roles whenever they like; and where anything a player isn't doing is taken over by AI.