Meeting 28/09/2017

2017 Settembre, 29 Venerdì 10:28

In this meeting we have define all the remainder algorithms the videogame will use to create the logic. Read carefully!


Time is running out. We have only 3 months before the competition starts. Since our developers need to study for the standard university courses, we need to act and code fast. But, before that, we still need to solve the same issue we had in the previous meeting: aka how to estimate the \sigma function.

Lorenzo and Federico Task review

As per Lorenzo and Federico instruction, it seems impossible to classify the qualitas, since they are too much different among ourselves. As for the props, they declared 4 classes:

  • Environment;
  • Activator;
  • Trap;
  • Reward;

We assume every prop inside a class is automatically compatible with all the others props within the same class. Furthermore, as shown in the figure below, the 4 different classes has edges placed among themselves: an edge X -> Y between 2 prop classes means that a connection in the qualitas graph of a prop with class X to the prop with class Y is meaningful.


Unluckly, this model is too restrict: it works well with rooms like:

  1. press a lever;
  2. A boss appears;
  3. After you kill the boss a reward appear;

But in all other scenarios, it doesn't work well: for example

  1. you press a button;
  2. a boss appear;
  3. after you kill the boss a lever and a treasure appear;
  4. the lever opens a door;

A simple scenario like this is not modelled at all.

A naive way of solve the issue

After discussing the problem with Phd student in artificial intelligence Francesco Percassi, we came out with a naive way to solve this.

The methods involves the construction of a Knowledge Base where each formula inside it is written in first order logic, in particular using datalog format. This knowledge base (KB) will contain several propositions containing facts and inferences rules whose objective will be to deduce whether the connection between P1 -> P2 with qualitas Q1 and Q2 is semantically meaningful or not.

Ok, probably lots of you are not accustomed to the terms I've written  here, so allow me to briefly review what we're talking about (After this brief discussion I will post some resources in order to help you familiarize with such concepts). 

First of all, first order logic are all the propositions shown in the courses of Algebra and Analysis. Writing you some examples: 


∀x {film(x)} → {∃y [protagonista(x,y) ∧ (∀z (z≠y → ¬protagonista(x,z)))]}

∀x,y,z {[film(x) ∧ film(y) ∧ x≠y ∧ protagonista(x,z)] → [¬protagonista(y,z)]}

The 2 formulas above can be interpreted in english as:

  1.  for every x such that x is film in the KB, there is always a protagonist y of the film (inside the KB) and every other protagonist in the KB is not the protagonist of the film x: in other terms, the KB contains protagonists of at most one film (Leonardo di Caprio can be the protagonist of up to one film) [Note that we never specified what a "protagonista" really is, so in the "z" term the logic of first can be associated to a film!]
  2. For every pair of different films where z is a protagonist of the first film, then z can't be the protagonist of the second film.

The computer does not require to know what is the semantics of "film" and "protagonista": if not expliticly said, a protagonista can be a film and viceversa. If you want to make the distinction clear you need to do (for example in the first sentece):


∀x {film(x)} → {∃y [¬film(y) ∧ protagonista(x,y) ∧ (∀z ((z≠y ∧ ¬film(z))  → ¬protagonista(x,z)))]}

Or, even better, defines an "actor":


∀x {film(x)} → {∃y [attore(y) ∧ protagonista(x,y) ∧ (∀z ((attor(z) ∧ z≠y) → ¬protagonista(x,z)))]}


In our case, the KB should resemble to something like this:








∀p1,p2 {[aesthetic(p1) ∧ aesthetic(p2) ∧ p1≠p2] → [∀q1,q2  (q1≠q2) → (¬meaningful(p1, p2, q1, q2))]} 


 The last sentence means: connecting to aesthetic is always semantically meaningless.

Our hope is to populate a KB with all the rules to detemrine wether a connection is or is not semantically useful. Implementationwise, we will code the KB with prolog. After populating the entire KB we will create a program that will query prolog all the connections available (so, we will do every PxPxQxQ combinations): for each them, we will store the query results in a file (or DB). The game will then simply load at start up such file. In this way:

  1. We do not need to call prolog directly inside Unity in runtime;
  2. We can compute the \sigma function separately and cache the results;
  3. It should be easier to code;


Algorithm to decide where to put the props

The last thing to decide is where to put the props inside a room. Since we're in a hurry, the idea was to use simple algorithm. If we will have time left and the results won't be satisfying, we can design a more careful algorithm. Michele Dusi proposed an idea: We use a underlying graph where each node is a prop.


The graph is located in a square space: no nodes can be put outside of such space. Each node is then randomly connected (via an undirect edge) to some other node. Furthermore, each node has a mass (that can maybe be computed with the dimensions of the prop instance or randomly. Then we model this graph as some physics objects with a certain mass: each object has an attrictive gravitational force if they have an edge between them and a repulsive one if they don't have it. After running the object will attract and repulse eachother until a condition of stability is reached (for example there is no object whose speed is greater than a threshold value).

We then save the layout of the graph inside the square. Each node position is then mapped inside the actual room we want to populate. For example if the room is rectangulare we will have to scale the square with some coefficient to match the dimensions of the rectangular room:

square= 1000x1000

rectangular room = 500 x 2000

the node A in the square is in the  position 342* 76. So it will be positioned in the room @ (342 * 1/2; 76*2). If such position is occupied by some other object we search the first non occupied cell of the room which near the input position.


I think every issue has been dealt in (some of them maybe in a naive way but whatever). 

In these days check the issue tab in the github repo (available in ). Furthermore, please look at the README in the gitrepo as well (I will do it shortly) because there I will put code styl guidelines and git organization.

After that, it will be coding time!


As per usual, if you have any comments or complaints, please email me