Event logic #744

Tomatower · 2017-02-18T01:32:35Z

The tube demo runs a simple curses based pong, that shall
demonstrate the functionality where and why a prediction interface is
built. 🤢

VelorumS · 2017-03-04T16:07:14Z

Maybe use std::chrono for time? And the linked list structure is just std::list (or can use a std::vector with binary_search/upper_bound/lower_bound). It's easier to explain the concept if there are less of home-made versions of trivial stuff.

Tomatower · 2017-03-21T06:28:00Z

You got a point there.
I have rebuild everything on top of std::list.

I have tried to condense the gamestate down into the most basic datatypes that need to be timely tracked.
Can we discuss, that I did not forget any important data structures?
I also have attached, where I would use which types to make it more clear what I am trying to say.

Container Types

Container types hold lists of items at any given time. They store a creation and a deletion timestamp for each item, and offer iteration logic to traverse the active elements in the container.

Map Container

The map container stores items based on an unique identifier mapped to an item. It keeps track of the existence of the item. No guaranteed order of items within this container is given (similar to std::unordered_map).
This container is useful for example for unit lists ...

https://github.com/SFTtech/openage/blob/master/libopenage/gamestate/player.h#L139
https://github.com/SFTtech/openage/blob/master/libopenage/gamestate/game_main.h#L92
https://github.com/SFTtech/openage/blob/master/libopenage/gamestate/player.h#L133
https://github.com/SFTtech/openage/blob/master/libopenage/gamestate/team.h#L56
https://github.com/SFTtech/openage/blob/master/libopenage/unit/attributes.h#L61
https://github.com/SFTtech/openage/blob/master/libopenage/unit/unit.h#L261

Set Container

The set container stores items, just as a normal array would. It keeps track of the existence of the items, but does not guarentee any particular ordering (similar to std::unordered_set).
This Container is useful for any non-indexed data structures, for example projectiles.

Queue Container

The queue container represents a random access queue while keeping the ordering of the queue.
It is usually used for pushing in the back and popping at the front (FIFO-Stlye) but offers random access insertion and deletion as well.
This container is useful for example for action queues and buildung queues.

https://github.com/SFTtech/openage/blob/master/libopenage/pathfinding/path.h#L189
https://github.com/SFTtech/openage/blob/master/libopenage/unit/unit.h#L267

Simple Types

Simple types only have one distinct value at a specific point in time.

Discrete Interpolation

"Step function" style values. These types adopt the new value exactly at the point in time changed.
They are useful for example for values like unit capacity, hitpoints, resource count, ...

https://github.com/SFTtech/openage/blob/master/libopenage/gamestate/population_tracker.h#L85
https://github.com/SFTtech/openage/blob/master/libopenage/unit/attribute.h#L215

Linear Interpolation

Linear connections between two points. These types have to overload the operators + and *, since these
are used to interpolate between t_n and t_n+1. These values change consistently over time, if t_n+1 exists.
These are useful for example for unit position, building progress, ...

https://github.com/SFTtech/openage/blob/master/libopenage/unit/unit.h#L68

Nyan Values

This container keeps track of nyan objects over time and their respective properties.

Usage of this will be there one day

MaanooAk · 2017-08-30T09:13:03Z

I will put my thoughts on curves here

They are really hard
At the moment you have a Curve from the start of time till the end of time (assertion check). I think that wrappers of Curves should be used. Examples:
- Array of curves: wraps a list of curves (one after the other)
- Repeating curve: a looping curve (which can be a Array of curves)

Example:
A villager mining:

Position of the villager:
Repeating curve { Array of curves { Path Curve, Const Curve, Path Curve } }
Resources of the villager:
Repeating curve { Array of curves { Const Curve, Linear Curve, Const Curve} }

Note: The wrappers would also implement the Curve interface

Reduce the events to minimal:
- Why: events disrupt the predictability (= more updates to the curves (= more traffic))
- How: use dummy curves to fill the duration of the delay

Example:
Instead of timer triggering an event, use a

Array of curves { Const Curve, Const Curve }

where the first const curve has the old value with a duration of the timer and the second curve the new value with infinite duration

Note: @TheJJ So the IntervalTimer would not become a event emitter but it would just be removed

Delete the no longer needed key frames from the memory (write to replay file if needed)
Hide everything: the use of curve should become as simple and pure:

Example:
from:

int hitpoints
hitpoints = 10
...
hitpoints += 2 * delta

to:

IntLinearCurve hitpoints = new IntLinearCurve()
hitpoints[now] = 10
...
hitpoints[now + (50 - hitpoint[now]) ] = 100

Side note to @TheJJ:
You have to select one of the big projects (nyan or tubes) and make branch in order to start, it will take months to implement either and it cant be incremental (I suggest first nyan because it has an impact of the actual game, curves will be hidden and they far away from using)

Tomatower · 2017-08-30T10:22:18Z

I agree on the thing, that curves are hard, but actually we have a working prototype.

The curves are very tightly entangled with the event execution pipeline. The events are basically the future part of the curves, executed to extend the validity of curves.

Curves are just another normal datatype, you can put some curves into a struct, and you can put structs into a curve.

// Curve in a Struct
struct thing {
    curve::Continuous<int> hitpoints;
    int id;
};

// Struct in a curve
// It is not possible to use a continuous curve here - would need + and * for interpolation.
struct parameters {
    int a;
    int b;
};
curve::Discrete<parameters> params;

It is only very confusing to use a curve in a curve, because every new keyframe would store a new curve for the inner curve, dropping the history of the contained curve.

Repeating curves can be implemented using callbacks at the end of a loop, reinserting values again.
I did not see the benefit for repeating curves compared to the overhead it would impose.

Your example would be in the current API:

auto hitpoints = std::make_shared<curve::Continuous<int>>(); // If a think wants to be targeted by an event it has to be a `std::shared_ptr`;                                                                  
hitpoints.set_drop(now, 10); // set as new last value, ignoring all previous history
...
time_until_damage = 30; // time between attacks of a unit (sword-strikes) in ms
damage = 1; // the damage the unit takes on the attack
hitpoints.set_drop(now + time_until_damage, hitpoints.get(now) - damage);

To make sure, that multiple units can damage another unit, it would be better to implement this damage by an event "target_hit" as a once-event, at time of hitting the unit.

This would lead to a little bit more code, which shall be part of the standard library:

// The Damage Event, that has to be set up in order to register an event.
class EventDamage : public curve::EventClass {
public:
    EventDamage() : curve::EventClass("openage.damage", EventClass::Type::ONCE) {}
   // The Damage Event does not depend (for re-prediction) on any other values
    void setup(const std::shared_ptr<Event> &evnt,
	           const std::shared_ptr<State> &state) override {
         // if it would depend, we have to add dependencies:
         //this->add_dependency(evnt, evnt->target);
    }
    // Whenever the event is up for execution do this. It is guaranteed, that all events up to this point
    // have been executed - but it is not guarenteed, that it will be executed only once!
    void call(curve::EventManager *mgr,
	          const std::shared_ptr<EventTarget> &target,
	          const std::shared_ptr<State> &state,
	          const curve::curve_time_t &now) override {
        // Do the actual logic here
        target->hitpoints->set_drop(target->hitpoints->get(now) - 1);
    }
};
...
// Add the event class to the pool of events - this is done during startup.
EventManager mgr;
mgr.add_class(std::make_shared<EventDamage>());

Now it can be used from the game logic.

// This connection between objects and events can be derived from defaults, abilities, or nyan
// Unit has to implement the EventTarget interface, or be a curve.
mgr.on("openage.damage", unit);

Currently I am still working on a nice interface to add additional parameters to the mgr.on call - in this case for example the amount of damage this event will do.

Still the question, what would be better - va_args, std::map<std::string, std::any>, void *, or template the shit out of it?

The tube demo runs a simple curses based pong, that shall demonstrate the functionality where and why a prediction interface is built.

TheJJ · 2017-12-03T22:34:24Z

doc/build_instructions/ubuntu_16.04.md

@@ -1,5 +1,5 @@
 # Prerequisite steps for Ubuntu users (Ubuntu 16.04)

 - `sudo apt-get update`
- - `sudo apt-get install cmake libfreetype6-dev python3-dev python3-pip libepoxy-dev libsdl2-dev libsdl2-image-dev libopusfile-dev libfontconfig1-dev libharfbuzz-dev libpng-dev opus-tools python3-pil python3-numpy python3-pygments qtdeclarative5-dev qml-module-qtquick-controls`
+ - `sudo apt-get install cmake libfreetype6-dev python3-dev python3-pip libepoxy-dev libsdl2-dev libsdl2-image-dev libopusfile-dev libfontconfig1-dev libharfbuzz-dev libncurses5-dev opus-tools python3-pil python3-numpy python3-pygments qtdeclarative5-dev qml-module-qtquick-controls`


libpng is still needed. and the other distros need the ncurses package as well.

libncurses should be an optional dependency, like it is done for inotify.

TheJJ · 2017-12-04T15:25:30Z

libopenage/curve/continuous.h

+	double offset = time - e->time;
+	// If we do not have a next (buffer underrun!!) we assign values
+	if (nxt == this->container.end()) {
+	// log::log(WARN << "Continuous buffer underrun. This might be bad! Assuming constant.");


leftover, what do? probably crash :)

TheJJ · 2017-12-08T13:18:00Z

libopenage/curve/datatypes.md

@@ -0,0 +1,120 @@
+TUBE DATATYPES
+=================


pls move this file to $root/doc/code/

TheJJ · 2017-12-08T13:18:49Z

libopenage/curve/datatypes.md

+| if (flag & time) time1                                    | # In the second quadruple the usage of the data is stored
+| if (flag & time2) time2                                   | # | time | time2 | data | UNUSED | delete | add | del_after | UNUSED |
+| if (flag & data) keyframe: size(16) | data                |
+-----------------------------------------------------------+


this is broken. shall it be a table or a <pre>?

TheJJ · 2017-12-08T13:29:41Z

libopenage/curve/datatypes.md

+Meaning of Flags
+----------------
+
+== DELETE ==


Those headlines just show up as == DELETE ==, maybe you meant ## DELETE ##? otherwise, maybe ``?

TheJJ · 2017-12-10T18:58:39Z

libopenage/curve/demo/physics.cpp

+	mgr->on("demo.ball.reflect_panel", state->ball->position, state, now);
+	// FIXME once "reset": deregister
+
+//	reset(state, mgr, now);


TheJJ · 2017-12-10T18:59:32Z

libopenage/curve/demo/physics.cpp

+				//	state->ball.position->set_drop(now, state.resolution * 0.5);
+				//}
+				//update_ball(state, now, init_recursion_limit);
+				//break;


many leftovers

TheJJ · 2017-12-10T21:25:00Z

libopenage/curve/eventqueue.md

+Event Queue Magic
+=====================
+
+The Event Queue consists of Events and their Context:


also move to doc/code/ pls

TheJJ · 2017-12-10T21:25:35Z

libopenage/curve/eventqueue.md

+
+The Event Queue consists of Events and their Context:
+
+```


to enhance the highlighting, c++ could improve it

TheJJ · 2017-12-26T00:21:31Z

libopenage/curve/eventqueue.md

+
+Internas
+=========
+


either leave out of fill with content :)

zuntrax · 2018-02-11T10:12:53Z

libopenage/curve/continuous.h

+ * cppclass Continuous(ValueContainer):
+ *     _T get(const curve_time_t&) except +
+ */
+template<typename _T>


We should agree on a project wide style for naming template parameters. _T is new to me, maybe we could do that everywhere. Needs discussion.

TheJJ · 2018-01-09T10:17:23Z

libopenage/curve/demo/gui.cpp

+namespace openage {
+namespace curvepong {
+
+std::vector<event> &Gui::getInputs(const std::shared_ptr<PongPlayer> &player) {


camelcase getInputs -> get_inputs

TheJJ · 2018-01-09T10:18:11Z

libopenage/curve/demo/gui.cpp

+	COLOR_2 = 7,
+	COLOR_3 = 8,
+	COLOR_4 = 9,
+};


not important, but could be a enum class and you then access with color::player1 etc.

TheJJ · 2018-03-03T18:57:40Z

libopenage/curve/demo/main.cpp

+	curvepong::Gui gui;
+#endif
+bool running = true;
+	srand(time(NULL));


we have our util/random system that should be used instead

TheJJ · 2018-03-10T17:26:17Z

libopenage/curve/demo/main.cpp

+#elif REALTIME == 2
+			now += 4;
+#else
+			#error no REALTIME plan set


TheJJ · 2018-03-10T17:31:48Z

libopenage/curve/demo/physics.cpp

+		auto positioncurve = std::dynamic_pointer_cast<Continuous<util::Vector<2>>>(target);
+		auto speedcurve = state->ball->speed;
+
+		// All the magic in the next lines


pls explain the magic

TheJJ · 2018-03-16T11:41:10Z

libopenage/curve/events/eventtarget.h

+ * Every Object in the gameworld that wants to be targeted by events or as
+ * dependency for events, has to implement this class.
+ */
+class EventTarget {


would Entity be a better name? Or would Entity be the "main" class that inherits from EventTarget?

This is only used to interface with the event system. I would have a core Game Entity, that inherits this event interface

TheJJ · 2018-03-16T11:42:14Z

libopenage/curve/internal/CMakeLists.txt

+add_sources(libopenage
+	keyframe_container.cpp
+	value_container.cpp
+)


maybe we can rename the internal folder to data_container because that's what's in the folder?

TheJJ · 2018-03-16T11:42:56Z

libopenage/curve/internal/keyframe_container.h

+public:
+	/**
+     * A element of the curvecontainer. This is especially used to keep track of
+     * the value-timing.


TheJJ · 2018-03-16T14:53:38Z

libopenage/curve/internal/value_container.h

+
+	// We want to remove a possible equal timed element from the container
+    // to do fabs(x-y) < min is only necessary when curve_time_t is floating point!
+    //if (std::abs(hint->time - at) < std::numeric_limits<curve_time_t>::min()) {


indent and leftover

TheJJ · 2018-03-16T15:25:51Z

libopenage/gamestate/gamestate.h

@@ -0,0 +1,111 @@
+// Copyright 2017-2017 the openage authors. See copying.md for legal info.
+
+#pragma once


we added this file as a prototype but we should remove this from the pull request to then work on its creation in #964

TheJJ · 2018-06-03T22:02:00Z

#1008 obsoletes this one.

Tomatower force-pushed the tubes branch from 5f0fad2 to 4cfb318 Compare February 18, 2017 03:33

TheJJ added lang: c++ Done in C++ code nice new thing ☺ A new feature that was not there before labels Feb 18, 2017

TheJJ mentioned this pull request Apr 5, 2017

History and interpolation #642

Closed

7 tasks

Tomatower changed the title ~~Tubes: tubes logic and epic tubepong~~ [WIP] Tubes: tubes logic and epic tubepong Apr 14, 2017

Tomatower changed the title ~~[WIP] Tubes: tubes logic and epic tubepong~~ [WIP] Tubes logic Apr 14, 2017

Tomatower force-pushed the tubes branch 8 times, most recently from 2d8891b to f2bd2ab Compare April 17, 2017 21:31

Tomatower force-pushed the tubes branch from 449ddd0 to 8b3e6bf Compare June 13, 2017 15:18

Tomatower force-pushed the tubes branch from 6332704 to 3cf41b1 Compare July 3, 2017 22:22

Tomatower force-pushed the tubes branch from 22d5aec to d29a62b Compare August 22, 2017 20:37

MaanooAk mentioned this pull request Aug 30, 2017

Research (aka Technologies) #845

Merged

TheJJ changed the title ~~[WIP] Tubes logic~~ [WIP] Event logic Aug 31, 2017

Tomatower force-pushed the tubes branch 2 times, most recently from 1e86a47 to e3cde6b Compare September 2, 2017 18:43

Tomatower force-pushed the tubes branch from e3cde6b to 15528de Compare October 18, 2017 22:53

TheJJ added this to the Event-driven game logic milestone Dec 3, 2017

Tomatower added 3 commits December 3, 2017 21:52

Added tubes logic and epic tubepong

c3a0b6c

The tube demo runs a simple curses based pong, that shall demonstrate the functionality where and why a prediction interface is built.

Fixed includes and some whitespaces

41b2f93

Added ncurses to ubuntu installation

cfe6580

Tomatower added 15 commits December 3, 2017 21:58

Added ncurses to ubuntu installation

6f52e4f

Tubes: Refactoring, Map and Types

4598ff6

Tube: Added queue, fixed some ugly pylint stuff

0e43190

Tubes: Fixed tests for queue

1f63378

Tubes: added tube_iterator, documentationw

841b7f9

Tubes: refactoring and documentation

3991df5

Whitespace and cleanup

a1a1c63

tubes: added a few more accessors

e2a1ebe

curves: renamed tubes to curves

a21e99a

added event list

6fe426b

curve: getting the demo up and fancy

7422c63

curves: event concept running

81ede4a

curve trigger concept running

b4b257a

Overhaul the event system. Again. And Again.

1681601

initial gamestate draft

2647a1b

Tomatower force-pushed the tubes branch from 15528de to f08e352 Compare December 3, 2017 21:18

cleanup

22e4703

Tomatower force-pushed the tubes branch from f08e352 to 22e4703 Compare December 3, 2017 21:20

TheJJ changed the title ~~[WIP] Event logic~~ Event logic Dec 10, 2017

TheJJ reviewed Dec 27, 2017

View reviewed changes

TheJJ self-assigned this Jan 9, 2018

zuntrax added the big stuff High-impact changes, mainly foundation work label Jan 21, 2018

zuntrax reviewed Feb 11, 2018

View reviewed changes

TheJJ mentioned this pull request Mar 16, 2018

Event based future prediction engine #740

Closed

TheJJ requested changes Mar 16, 2018

View reviewed changes

TheJJ mentioned this pull request May 2, 2018

events: initial implementation of core simulation components #1008

Merged

4 tasks

TheJJ closed this Jun 3, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Event logic #744

Event logic #744

Tomatower commented Feb 18, 2017 •

edited

Loading

VelorumS commented Mar 4, 2017

Tomatower commented Mar 21, 2017

MaanooAk commented Aug 30, 2017 •

edited

Loading

Tomatower commented Aug 30, 2017

TheJJ Dec 3, 2017

mic-e Feb 3, 2018

TheJJ Dec 4, 2017

TheJJ Dec 8, 2017

TheJJ Dec 8, 2017

TheJJ Dec 8, 2017

TheJJ Dec 10, 2017

TheJJ Dec 10, 2017

TheJJ Dec 10, 2017

TheJJ Dec 10, 2017

TheJJ Dec 26, 2017

zuntrax Feb 11, 2018

TheJJ Jan 9, 2018 •

edited

Loading

TheJJ Jan 9, 2018

TheJJ Mar 3, 2018

TheJJ Mar 10, 2018

TheJJ Mar 10, 2018

TheJJ Mar 16, 2018

Tomatower Mar 16, 2018

TheJJ Mar 16, 2018

TheJJ Mar 16, 2018

TheJJ Mar 16, 2018

TheJJ Mar 16, 2018

TheJJ commented Jun 3, 2018

		@@ -0,0 +1,111 @@
		// Copyright 2017-2017 the openage authors. See copying.md for legal info.

		#pragma once


		Internas
		=========

Event logic #744

Event logic #744

Conversation

Tomatower commented Feb 18, 2017 • edited Loading

VelorumS commented Mar 4, 2017

Tomatower commented Mar 21, 2017

Container Types

Map Container

Set Container

Queue Container

Simple Types

Discrete Interpolation

Linear Interpolation

Nyan Values

MaanooAk commented Aug 30, 2017 • edited Loading

Tomatower commented Aug 30, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheJJ Jan 9, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheJJ commented Jun 3, 2018

Tomatower commented Feb 18, 2017 •

edited

Loading

MaanooAk commented Aug 30, 2017 •

edited

Loading

TheJJ Jan 9, 2018 •

edited

Loading