Jump to content

  • Log In with Google      Sign In   
  • Create Account


Waterlimon

Member Since 28 May 2011
Offline Last Active Today, 10:24 AM
-----

Topics I've Started

A game (engine) that works like dreaming?

19 May 2014 - 10:40 AM

How about a game/game engine that worked like your brain when you are dreaming.

 

Essentially, the system would have the 'present state'. It would then use this 'present state' to discover 'expectations' of what should happen using some database of stuff and some code (such as if in the present state there exists a nuclear explosion, there definitely should also be zombies, military barricades and people running around). These expectations can be created through teaching (eg creating scenes by hand, letting players modify their environment to somethign they deem 'normal'...)

 

Lets call the component that finds these expectations about the future based on the present state the 'predictor'.

 

The present state does not only include objects and their locations or such. It is everything you can perceive about the environment. It includes patterns and events, not only concrete perceivable objects which form those patterns or events. You need to see the forest from the trees.

 

So we have:

-Present state

-Predictor

 

The present state will not be exact nor it will be permanent. Information in the present state has some information that is used to determine its importance:

-Predictability

*If its presence can be deduced from the surroundings, it is implicitly stored. It does not need to be kept in memory explicitly.

*A blade of grass under a tree can be forgotten

-Significance

*A blade of grass under a tree is not significant. A single blade of grass growing from some random brick of some building definitely is.

*If you perceive something, it is significant. The more you perceive it, the more significant it is. Whether you perceive it directly or indirectly.

*Essentially, if you dont care about something, it can be thrown away and replaced with something else when you come back.

 

Entities (objects, patterns, events, whatever) are more significant if they are deeply rooted in the world. To perceive something you dont need to see it, its enough so see its effects. Effects should be tracked to some extent.

 

This is largely a form of procedural generation. Just a lot more fuzzier.

 

Since nothing will be exactly defined, the graphical and physical side need to account for this and just throw stuff around so it looks somewhat correct. If implemented in single player, and the generation is done from the local PoV, it might be that the paths the player walks will not make sense if mapped from a global perspective. It might be more interesting that way. Positions should always be relative to other objects, there should be no global positions. Objects could have the same position in the mathematical sense but still be far away from each other since it requires a global perspective to be able to deduce that the objects have the same location if they are accessed through very different paths.

 

Example:

Lets say your world has a street. The predictor says there are buildings next to it, so the engine slaps on some random buildings next to it. You walk close to one and look down at the line where the street and the building meet, so the engine figures the road should actually be of the same material as the path to the door and quickly fixes that. With some blur and random plants to make it not ugly. Maybe some ants too, theres ants in them cracks. So you get to the door, which the engine just moved to line up with the pathway because perfection. Then you get in and because the dev wanted a space game the engine decides its a space ship because theres some slight artistic bias in the database of expected stuff. Of course the shape of the spaceship is not defined so you see some random hallway with random scientific doors and stuff, and walk to the first door and it happens to be the cockpit because nobody felt like describing any other type of room. Out of the window you see some ugly space texture that was actually space as seen from the ground even through you are now in space but close enough. Then suddenly theres a hole and you get sucked into space because thats what happens in spaceships. Then you die and respawn to the beginner area.

 

I emphasize that the world is not meant to be perfectly consistent. This is an optimization. It should only be locally consistent.

 

Someone implement plz

 

I suggest starting by making a functioning artificial intelligence. This should be trivial because a consciousness module is probably not needed.


"Vector" of types? (compile time template)

23 March 2014 - 12:40 PM

I was wondering, is it possible to make a list of types using template programming, with methods to iterate over them etc.?

 

Essentially im looking for an equivalent of a simple std container except for arbitrary types and defined at compile time.

 

I want to do compile time polymorphism.

 

Something like:

GameObjectContainer<Contained<Player, MAP>, Contained<Tree, VECTOR>> objects;
*For each type of game object i can define what kind of data structure is most suitable in a compact form. The non template alternative is manually defining these things within the game object container, as well as manually updating the objects.update() etc. to account for new containers to go through.

int index1=objects.add<Player>();
*Adds to MAP<Player>

int index2=objects.add<Tree>();
*Adds to VECTOR<Tree>

Player p=objects.get<Player>(index1);
*Accesses map


Tree t=object.get<Tree>(index2);
*Accesses vector


objects.update();
*Goes through both map and vector automatically, i never need to update how this method works.

As you can see this would be only to reduce the amount of code in well defined situations. How would i implements something like this in the cleanest way?

 

Is there a C++ object that can contain a list of types and has a for_each method that runs a lambda for each element (with each element being of different type, im not sure if lambdas work for this?)

 
 
 

Does this approach to pass frequent method parameters implicitly seem evil?

29 November 2013 - 03:37 PM

(excuse any mistakes in the code - i have not actually tried this yet and because globals are evil, im probably unaware of how to use them correctly. Will try to fix any problems.)

Imagine the following case:

We have a pile of game entities, each having logic, and each often needing access to the scene object so they can interact with the surroundings.

We then have code to update all these different entities as in:

void Scene::update()
{
    runMachines(*this); //Lots of moving parts - may affect surroundings
    growGrass(*this); //Need to check other objects - grass may impale those who stand on it while its 
    growing
    glowLight(*this); //Heat the neighbors
    for each object do
    {
        for each otherobject do
        {
            checkCollisions(*this)
            doGravity(*this)
            sayHi(*this)
        }
    }
    etc.
}

As you can see, quite a lot of Scene in there. I realize that this is not much. But if we take the hypothetical situation where the number of such objects is 4 (since we dont want to combine everything into a single scene object for example) and the logic is a lot more complicated, this gets quite redundant. In most practical situations, scene could be considered a global. We dont do that, because two scenes should be able to exist, and making it a global would remove ALL passing of Scene around.

 

So, what if there was a compromise such that:

-Scene is still passed around as a parameter where it does not feel like mindless repetition of a fact the code should understand (im basically looking for a statement like "using Scene" here)

-It is still obvious where scene might be passed. If its a global, we have no control over where scene can be accessed.

-It does not limit the amount of scenes to 1.

 

So, i was thinking of a class that sets a scope-limited global, which can be set in a scope, and then accessed from whatever methods you call from that scope as it were a global.

 

Implementation:

template<typename T, int identifier=0>
class Using
{
public:
    Using(T* ptr) : prevImplicit(implicit), implicit(ptr)
    {
    }

    ~Using()
    {
        implicit=prevImplicit;
    }

    static T* get()
    {
        assert(implicit!=nullptr);
        return implicit;
    }

private:
    static T* implicit=nullptr;
    T* prevImplicit;
}

Usage:

 

Using the example, instead of passing Scene to each method, we set a temporary scope limited global:

    Using<Scene> scene(*this);

And within the methods needing access to the scene we do:

    Scene* scene = Using<Scene>::get();

and then use it to apply whatever logic needed. The scene thus does not have to be passed in as a parameter, it is now a less evil global! :DD

 

Now, to explain some details.

We might have a scope using Using to apply a scope limited global. But what if a method is called from this scope, which also uses Using to also set a global of type Scene?

We have two mechanisms to handle this case:

1) We store the previously set value in the temporary Using class. When we return back to the first scope from the subscope, the value of the global will be reset to what it was before. Please do note that there might be some corner cases related to threads and lambdas and those might need special approaches.

2) We have a second template parameter, identifier, which allows us to have more than one such "implicit parameter". This is more for cases where you want to use implicit parameters, but have two or more of the same type. If you are handling eg. an array of them, it does no longer make sense to try to pass them as implicit parameters. Enums can be created to have eg PRIMARY_SCENE and SECONDARY_SCENE. I cant come up with any better examples of when youd need this, but the important thing is that it is trivial to pass in multiple objects of the same type.

 

So, the example update method would look as follows:


void Scene::update()
{
    Using<Scene> scene(this);
    runMachines(); //Lots of moving parts - may affect surroundings
    growGrass(); //Need to check other objects - grass may impale those who stand on it while its
growing
    glowLight(); //Heat the neighbors
    for each object do
    {
        for each otherobject do
        {
            checkCollisions()
            doGravity()
            sayHi()
        }
    }
    etc.
}

 

Is there anything wrong with this approach? Please do remember that i wanted to try and find a compromise between being explicit about dependencies, while at the same time allowing this kind of gameplay code to be less strict, since it is likely to change more rapidly and such (which is why we use scripting languages for that kind of code - it does not need to be so strict)

 

In most cases this does not really help much, but im sure there are cases where such a construct might be useful. 


Yiddish indentation

01 October 2013 - 06:40 AM

                int foo(float durr)
                {
            if (durr < 1.0f)
            {
        int resolt=0;
    for (int i=0; i<10; ++i)
    {
resolt += durr;
    }
            }
            return resolt;
                }

This is the best thing since hungarian notation!

 

As you can see it highlights the algorithms and hides the completely useless structural code.

 

No nobody has probably ever used this and i just made it up.


Entities as nondata classes?

13 July 2013 - 07:43 AM

Originally i had an Entity which had components inside it (actually references to components)

 

The entity had 3 jobs:

-Act as the glue between the components to form an entity (act as the communication layer)

-Contain the entity specific data and logic (eg CharacterEntity had walkVelocity and logic needed to apply it)

-Define how the components are stored by holding references to them (or having them as members)

 

So i split it up so that i have (ill use Character entity as example)

 

CharacterEntity

*update(PhysicsSystem&, Character&, DynamicBody&...)

 

Character

DynamicBody

DynamicBodyView (=sprite)

 

CharacterEntityManager : private CharacterEntity

*getCharacter(EntityID) //getters for each component of the entity

*getDynamicBody(EntityID)

...

*addCharacterEntity(PhysicsSystem&)  //Build an entity (internally deal with creation of components)

...

*updatePhysics(EntityID, PhysicsSystem&) //exposes the CharacterEntity interface, plugs in the appropriate components of the entity for the user

*update(EntityID) //forwards to Characterentity::update, filling in all the components. The user as such doesnt have to know how the components are stored and accessed

 

 

This seems elegant to me. I dont need to touch the internals of any of the components, or modify the glue code, when i want to change how the components are stored.

 

Questions:

1. I store the glue code in the CharacterEntity class which i privately inherit in the manager (which adds the storage of components)

does this seem like the best way to do it? Is private inheritance the right choice?

 

2. What to call the CharacterEntityManager class, because the word "Manager" has this evil feel to it.

 

3. Anything you would change?

 

thanks


PARTNERS