In the following article, I will revivew the themes discussed in the previous meeting. The focus of such meeting was that to design the algorithm laying out the logic and the qualitas connections of the props added in a room

In order to completely understand the ideas inside this meeting, you need to have a grasp on heuristics and, in general, A*

I want to remind you that all of these are just **ideas, not design**.

First of all, it's official: **we are behind the schedule of this project**. Because of this, I thought it was mandatory to further restrict the alpha version of the game: **the first version should consist of only 1 room automatically populated**.

Remember the last stuffs we have asserted in the meeting: we have an algorithm that computes the list of props to add in the room. Furthermore, such list is ordered and the order is a "existence dependency" from the object at position i-th to the one at (i+1)-th: in other words, **we add the object B because we have added the object A**.

But how those object are related? And what are the qualitas of such objects? This meeting tried to solve these issues.

First of all, each prop has a different number of qualitas. The prop themselves are inside an *interface hierarchy*: for example the prop "Boss" implements "HPAble" (with HP) while "Boss" prop doesn't implement the interface "Openable". This interface graph can be exploit to **prune (remember what pruning is, right?)** which qualitas can be assigned to a particular prop: for example the qualitas "doOpen" can't be assign to something that is not "Openable" (for example it can't be assign to a "Boss" or "Enemy"). *Pruining tell us what can we safely excluded, but tell us nothing about what can be added*.

Now, Suppose you have 4 prop in the room: a fountain, a flamethrower, a boss and a treasure. You need add a qualitas, for example "OnKill". You scroll all the prop and remove the ones that doesn't implement the interface "HPable" (OnKill qualitas requires you to have a HPable). Let assume that we decided that flamethrowers don't have HP. So you have restrict the choice to who will receive this qualitas, aka either the fountain, the boss or the chest with the trasure.

In order to establish which prop should have the qualitas, we add for each prop class as many **double fields** as there are interfaces implemented: so if Boss implements "HPAble" and "Moveable", we will add the field "hasMeaningToHPAble" and "hasMeaningToMoveable": each of them is a propbability between 0.0 and 1.0. We choose which prop will receive the qualitas based on a **weighted random choice between the props left from the previous operation**: so if the fountain has hasMeaningToHPAble=0.01, the boss hasMeaningToHPAble=0.98 and the chest hasMeaningToHPAble= 0.5, we choose a random weight based on such values. For example, we choose the boss.

This is a simple algorithm to choose a qualitas to assign to a prop. The probabilities are hard coded.

Now you can model the qualitas of the props and the business logic link among them as a graph with as many layers as there are props. We need to find an algorithm that (at fuzziness = 0) will create "serious maze", aka mazes where the player can detect what the logic is inside the room. We need to create an algorithm that **creates serious algorithm, aka seriious connection of qualitas and assign qualitas to prop correctly**.

How can we do it? An idea would be to see this problem as a **search in the state space**: each state of the problem would be a qualitas graph, with variable nodes and variable edges. Each successor might have:

- a new node representing a qualitas;
- a qualitas removed from the graph;
- a new connection between 2 qualitas;

The issue now is to find a valid heuristic, aka something that tells A* (we will use as search algorithm A* itself) if the qualitas graph is meaningful or not. Now,

A qualitas graph is meaningful for a player if all the edges between the qualitas are meaningful for the player. Regarding that, we can model the function that, given an edge of the qualitas graph, determines the meaningfulness of the connection as:

\sigma : P x P x Q x Q --> R

In other words, such functions pick:

- a prop p1 (inside the set P);
- a qualitas q1 assigned to p1 (inside the set Q);
- a prop p2 (inside the set P);
- a qualitas q2 assigned to p2 (inside the set Q);

The function will evaluate this tuple and assign it a meaningful value in R (for example 0.5). Note that we might hardcode this function but for 4 props and 5 qualitas (hence a very small problem), we should hardcode 4*4*5*5 = 400 values. It's clearly too much.

So we need to think about a solution (if the local search solution is to be chosen) to compress this matrix. Note that after that, we need to get the meaning value of the whole graph, for example, given the semantic meaning of all 15 edges in the qualitas graph, what should be the semantic meaning of the graph? How can we aggregate the values? Possible solutions are:

- sum;
- product;
- max;
- average;

Finally note that "creating serious mazes" is **not a synonym** of "creating maze that lead to a reward to the player".

As per usual, if you have suggestions of complaints, please email me.

]]>The following summarizes the JAM2018 meeting of today. Please read it carefully!

In the last meetings we started designing how the maze should be modelled and how it should be generated. In today's meeting we have started to understand how to layout objects inside a single room.

The main idea is, just to simplify thinngs, to consider a rectangular-shaped room. The room is viewed from the ceiling to the floor. Furthermore, we divide the rectangular-shaped room into a matrix of virtua cells: this matrix will be the foundation that will help the room layout algorithm to work properly. The meeting then focused its attention on the layout of a simple but interesting object: the lava. This entity is, as observed by Lorenzo, a **special kind of prop**: this prop, in contrast to others (like fountains, enemies or buttons) dramatically alters the topology of the room; some prop can be placed only on laval (like platforms) while others can be placed only on normal terrain (like fountains). An algorithm laying out the room should position the lava first. Actually there might be several of this **lava-like** props: water, acid, ice; these **so called terrain props heavily depend on the biome of the sector of the maze**.

So we needed to layout the lava pits. We broke the problem into 4 separate algoithms:

- The one that decide how mich room floor is occupied by the lava;
- The one that decide which shape a single lava pit has;
- The one that decide how many lava pits are inside the room;
- The one that decide the concrete shape of a lava pit;

The third algorithm is just a random between 1 and 4 (inclusive). The second algorithm divides the lava into different shapes: random, moat-like (fossato), circular; however, we didn't talk about how the program should pick up the shape. The fourth algorithm heavily depends on the output of the second. We create the algorithm for the most difficult lava pit shape, the random one:

We start from a cell near a wall in the room. That cell will be marked as "lava filled". Then we expand the lava region to a neighbour of the lava cell. The process keeps going until an exit condition is satisfied (eg. size of the lava pit). Optionally the lava border can be randomied to make the border less polygonal.

The first algorithm has not been thought at all.

By the next thursday you should:

- think about how to implement the algorithms;

By the next next thursday you should:

- Learn about IA basics, search algorithm in particular
**A***; I suggest the following links:- https://www.youtube.com/watch?v=pKnV6ViDpAI;
- Difference between algorithm and heuristic (abstract): https://www.youtube.com/watch?v=o5lzVg5vGaM;
- A more game related A* with heuristic: https://www.youtube.com/watch?v=Jinh4957mpM;

]]>

JAM 2018 project aims to design and develop a game that will be showcased in Milan JAM 2018 @ Politecnico di Milano. The game will **simply be shown before the actual competition**. Project members will then individually decide wether or not join the actual JAM competition.

You can see the slides relative to this project here (slides are in english!)

The members (name alphateically ordered) of the project are:

The following are the general schedules activities:

- Unity 3D training;
- Game concept brainstorming;
- Game design brainstorming;
- Game software design engineering;
- Core game development;
- Core game testing;
- Incremental new game entities development;
- Showcase @ JAM 2018;
- Game finalization;

]]>