Pathfinding, and Unit Movement

2020-04-05 00:00:00 +0000

A core theme in game making is how a player moves from one position to another. Because we have designed our game using a hexagonal tile based system where, for each turn the player unit moves from one tile to any connecting tile. We chose to create a path queue, so that when a tile has been clicked; the shortest path is found using Dijkstras algorithm from the Players units current tile, to the destination tile.

Dijkstras Algorithm, and Hex Nodes and Edged

Dijkstra’s algorithm uses graph theory to solve the shortest path from one initial node to one final node. By implementing this algorithm, we were able to take into acccount the weighted nature of each tile; enabling the shortest path to be found around elements such as a black holes, which might need to be avoided.

The following code was taken from Introduction to Algorithms, pp 658-662

DIJKSTRA (G,w,s)
  INITIALIZE-SINGLE-SOURCE.G;
  s = 0
  Q = G .V
  while Q != 0:
    u = EXTRACT-MIN(Q)
    S = S ∪ {u}
    for each ν ∈ G.Adj[u]
      RELAX(u,ν,w)

Movement Queue

In Unity 3D, each game objects class has an Start() and Update() function. They are used to initialise data and variables at the beginning of the object instantiation in the game world, and then a hook in order to run certain functionality each time the frame is rendered; often called a running loop. The function Update() is called once per frame render, and is used to automate certain functionality. We used the Update() function to implement a movement or destination queue, where the selectedUnit has a

  • currentPath: A List of Nodes from the selectedUnit’s current position to a final destination node
  • currentPathV3List: A List of Vector3 to create a visual of the destination path.
  • destinationList: A List of Nodes which the update function will automatically iterate over, taking the first item, converting it to a vector, and setting it to destination.
  • destination: A Vector3 which the current Node is moving towards.

Queue iteration

  1. When a Hex tile has been clicked, the function GeneratePath will create the shortest path, and pass it to the selectedUnit, and run selectedUnit.RenderPath; which willl create a line showing the current path.
  2. When selectedUnit recieves the path, a UI button is loaded (to do; currently we have hard coded to button to always be present, but will work on it only appeaaring when a path has been registerd).
  3. When the UI move button is pressed, this tells the map to tell the selectedUnit to add the next item from currentPath to destinationList, and remove that same item from currentPath. Then the currentPath is regenerated.
  4. selectedUnit Update hook noticies that there has been a new destination Vector3, and begins moving towards it. At this time, when the selectedUnit is between hex tiles, the user can add the next nodes to the queue by clicking the move button, and it will iterate through the destinationList rather than moving directly to the final destination.
  5. Each time a destination has been arrived at, the selectedUnit tile position (Q and R) are updated, so that a new path can be generated from that position, rather than the initial starting position.

Bibliography

  1. Cormen, T. H..   2009  "Introduction to algorithms"  MIT Press 

Introduction to the game

2020-02-25 00:00:00 +0000

Game play graph

An Introduction To Our Game

Why Make an Educational Videogame?

Videogames are often an overlooked educational medium. No movie or book can give the consumer the same level of interaction and control over a narrative and thus their learning. This control leads to a higher level of engagement from the player because the more they play, the more they shape their story within the game. We hope that this desire to complete a narrative (and overcome challenges) will overshadow the player’s possible complete disinterest in learning.

Initial Ideas:

Ideally this game would be based in the 4x games genre; a type of strategy game that requires the player to grow their empire through exploration, expansion, exploitation and extermination (hence 4x). However, these tend to be very complex games and is therefore not a reasonable goal given the extremely limited time-frame that we are faced with and the lack of game development experience of most of the team. Thus we have made the decision to compromise on many features with a goal of providing proof of concept that a game that incorporates learning about physical principles can be made enjoyable.

Game Outline:

At present our objective is to create the most skeletal form of a civilisation game set in space using unity. Consisting of a static hex-tile map including various planet types (populated/unpopulated) and other celestial objects (e.g. black holes, asteroid belts, stars) which present different challenges for the player that relate to physical concepts and provide avenues through which we can educate and thus prove the concept we have been tasked with.

The focus is mainly on the exploration aspect of the game to give the player the ability to have some control over the narrative and therefore engage as much as possible. To adequately demonstrate most of the game mechanics, such as movement of different unit types (ships), resource gathering, progression through the tech tree and the actual answering of questions that relate to their current situation as they travel through space upgrading their civilisation we feel that only a section of static map should be created associated with a relatively small section of the tech tree. This would then act as the foundation to allow further development.

We’re scrapping any form of democracy (and for our initial version most interaction from enemies), multiple resources and large scale unit diversity to instead focus on how to use the pacing of these games to make players interact with education. One of the main focuses is the technology tree, where we can talk about real technological improvements (both that have occurred so far and ones that humans will eventually achieve) and provide more in depth background to physical processes going on in the discoveries. We also plan to create encounters where players are presented physics questions which they are rewarded for if they answer successfully. While the hex-tile board prevents us from accurately representing physical phenomena, the player will still see a reflection of their actions in gameplay mechanics (e.g. new fuel source -> better movement, discovery of better material -> higher hp).

Meet the team

2020-02-15 00:00:00 +0000

Meet The Team

From Left to right:
Ben Smith, Abbie Mace, Federico Giovanni, Safiya Merali, Kresda Rattanasudsai and Samuel Overington