For our hackathon project, we designed a game where players navigate a city-based maze, avoiding zombies and collecting power-ups. Here’s a peek at the technical challenges and creative solutions we tackled to bring this game to life!

We decided to go with a maze game mainly because it seemed straightforward, and the judging criteria suited it well. In our heads, it was a simple idea we could whip up easily (spoiler: it turned out to be a lot harder than expected! 😂)

Here’s what we learned (and struggled with) along the way:

1. Building the Maze Layout: Initial Experiments and Challenges

We started off building a simple maze with a binary multidimensional array, where walls were “1” and paths were “0”. This gave us a nice structured maze, but it felt too plain and predictable.

Even though the result looked like a maze, it just didn’t feel fun or creative enough:

2. Trying AI for City-Based Mazes: A Temporary Detour

We thought, "What if we could use AI to turn screenshots of city maps into mazes?" This idea was cool but turned out way more complex than expected. None of us had experience training custom AI models to transform city maps into maze layouts within our timeframe.

So, we took a one-day detour and tried a body pong game (similar to ping pong but controlled by body movement) using ML5.js. Here’s a demo of that experiment, presented by one of our teammates:

3. Eureka Moment: Using Map Data for a Real-World Maze

Our breakthrough came when we realized we could use a maps API to pull in street data, transforming it directly into a navigable maze. With this, we shifted gears and moved to our next big technical challenge: “Integrating Real-World Map Data for Maze Generation.”

4. Integrating Real-World Map Data for Maze Generation

Using real-world city maps, we designed a layout that felt like an actual city. We imported OpenStreetMap (OSM) data and transformed it into nodes and edges representing streets and intersections, creating a maze-like experience.

The Challenge

Turning real-world map data into a playable maze was tricky! We needed to handle interconnected streets, dead-ends, and map structure in a way that felt natural yet challenging for players.

The Solution

Using the OpenStreetMap API, we fetched city data, then processed it into a grid of paths, simplifying each section for gameplay. Here’s the code that made it happen:

// Fetch street data from OpenStreetMap
function fetchStreetData(bbox, callback) {
  const query = `
    [out:json][timeout:25];
    (
      way["highway"](${bbox.join(',')});
      >;
    );
    out body;
  `;

  fetch('https://overpass-api.de/api/interpreter', {
    method: 'POST',
    body: query,
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    },
  })
  .then(response => response.json())
  .then(data => callback(data))
  .catch(error => {
    console.error('Error fetching OSM data:', error);
    document.getElementById('status').textContent = 'Error fetching map data.';
  });
}

// Process OSM data into nodes and edges
function processStreetData(osmData) {
  osmData.elements.forEach(element => {
    if (element.type === 'node') {
      nodes[element.id] = { id: element.id, lat: element.lat, lon: element.lon, neighbors: [] };
    } else if (element.type === 'way') {
      const nodeRefs = element.nodes;
      for (let i = 0; i < nodeRefs.length - 1; i++) {
        const from = nodeRefs[i];
        const to = nodeRefs[i + 1];

        if (!edges[from]) edges[from] = [];
        if (!edges[to]) edges[to] = [];
        edges[from].push(to);
        edges[to].push(from);
      }
    }
  });
}

The fetchStreetData and processStreetData functions create a maze from city data, giving players the fun experience of navigating real-world streets.

5. Adding Random Elements for Unpredictability

To make each session unique, we introduced randomness to the placement of key elements: safe zones, collectibles, and opponents.

Safe Zones offer temporary protection, while collectibles give players special powers like speed boosts, health recovery, and invisibility. Each item is placed randomly, making the game feel different each time you play.

Here’s a glimpse of how it works:

// Function to create safe zones
function createSafeZones() {
  const numSafeZones = 3;
  const nodeIds = Object.keys(nodes);
  for (let i = 0; i < numSafeZones; i++) {
    const randomNodeId = nodeIds[Math.floor(Math.random() * nodeIds.length)];
    const safeZone = {
      lat: nodes[randomNodeId].lat,
      lon: nodes[randomNodeId].lon,
      marker: L.marker([nodes[randomNodeId].lat, nodes[randomNodeId].lon], {
        icon: L.icon({ iconUrl: 'images/safe-zone.webp', iconSize: [32, 32] })
      }).addTo(map)
    };
    safeZones.push(safeZone);
  }
}

6. Making Zombie AI Feel Real

Our zombies use basic pathfinding to follow the player, creating a real sense of pursuit. We used a mix of A* pathfinding for nearby zombies and straight-line movement for distant ones to keep CPU usage low.

// Function to move opponents towards the player
function moveOpponents() {
  opponents.forEach(opponent => {
    if (!opponent.currentNodeId || !nodes[opponent.currentNodeId]) return;

    const playerLat = nodes[currentNodeId].lat;
    const playerLon = nodes[currentNodeId].lon;
    const neighbors = nodes[opponent.currentNodeId].neighbors;

    // Move to the closest neighbor
    let nextNodeId = neighbors.reduce((closest, neighborId) => {
      const distance = getDistanceMeters(playerLat, playerLon, nodes[neighborId].lat, nodes[neighborId].lon);
      return distance < getDistanceMeters(playerLat, playerLon, nodes[closest].lat, nodes[closest].lon) ? neighborId : closest;
    }, neighbors[0]);

    opponent.currentNodeId = nextNodeId;
    opponent.marker.setLatLng([nodes[nextNodeId].lat, nodes[nextNodeId].lon]);
  });
}

This approach makes zombies unpredictable, while also keeping the game smooth and engaging.

7. Hand Tracking Controls: Adding an Immersive Player Experience

To take our game to the next level, we wanted players to control movement through hand gestures instead of traditional keyboard inputs. This required us to dive into hand tracking technology, specifically using the ml5.js library. With this setup, players can simply tilt their palms to navigate the game, making the experience more interactive and unique.

The Challenge

Using hand tracking for real-time control was tricky, especially when converting palm movements into smooth and responsive directional input. We had to identify the correct hand landmarks and translate them accurately into up, down, left, and right movements.

Solution: Implementing Palm Tilt Detection

Using ml5.js’s Handpose model, we detected landmarks on the player’s hand. The idea was to compare the position of the wrist and the middle fingertip to determine the tilt direction.

Here’s the core code that made hand tracking work:

javascriptCopy code// Function to detect palm tilt and determine direction
function detectPalmTilt(landmarks) {
  const wrist = landmarks[0];
  const middleFingerTip = landmarks[12];
  const deltaX = wrist[0] - middleFingerTip[0];
  const deltaY = middleFingerTip[1] - wrist[1];
  const angleRad = Math.atan2(deltaY, deltaX);
  let angleDeg = angleRad * (180 / Math.PI);

  // Normalize angle to [0, 360)
  if (angleDeg < 0) {
    angleDeg += 360;
  }

  // Define thresholds for each direction
  const directionThresholds = {
    'up': { min: 45, max: 135 },
    'right': { min: 315, max: 360 },
    'right_ext': { min: 0, max: 45 },
    'down': { min: 225, max: 315 },
    'left': { min: 135, max: 225 }
  };

  let detectedDirection = null;

  if (angleDeg >= directionThresholds['up'].min && angleDeg < directionThresholds['up'].max) {
    detectedDirection = 'up';
  } else if (
    (angleDeg >= directionThresholds['right'].min && angleDeg < directionThresholds['right'].max) ||
    (angleDeg >= directionThresholds['right_ext'].min && angleDeg < directionThresholds['right_ext'].max)
  ) {
    detectedDirection = 'right';
  } else if (angleDeg >= directionThresholds['down'].min && angleDeg < directionThresholds['down'].max) {
    detectedDirection = 'down';
  } else if (angleDeg >= directionThresholds['left'].min && angleDeg < directionThresholds['left'].max) {
    detectedDirection = 'left';
  }

  if (detectedDirection) {
    movePlayer(detectedDirection);
  }
}

This function calculates the angle between the wrist and middle fingertip to determine the tilt direction of the player’s hand. Based on the tilt, it then triggers movement in the corresponding direction.

Code Walkthrough:

• Identify Hand Landmarks: Using the ml5.js Handpose model, we capture the hand landmarks, focusing on the wrist (index 0) and the tip of the middle finger (index 12).

• Calculate the Tilt Angle: We calculate the angle between the wrist and the middle fingertip. By interpreting this angle, we can figure out whether the palm is tilted up, down, left, or right.

• Set Directional Thresholds: To ensure accurate and intuitive control, we set angle ranges for each direction (up, down, left, right). For instance, a tilt angle between 45° and 135° means the hand is tilted up.

• Move Player: If a valid direction is detected, we trigger the movePlayer function in that direction, allowing the player to navigate the maze.

Conclusion

This city-based maze game was an exciting challenge, combining real-world map data, gesture-based controls, and dynamic AI. We learned a lot about balancing game complexity with playability, and it gave us some big ideas for future updates—like multi-city maps, expanded AI behaviors, and even more immersive experiences.

Curious to try it yourself? Play the demo here! Let us know what you think!

Then you should read this article to the end.

My goal for this article is to help you understand the differences between Constants and Immutables, and when it's best to use them.

Firstly, let's look at the individual terms and see what they mean, and how they are used:

Constants

A "constant" state is a variable that cannot be changed after the contract is compiled.

contract Example {
    // An example of a constant 
    uint8 public constant speedOfSound = 343;

    // An example of a string variable (not constant)
    string public username = "@CyberDev_D";
}

Immutable

An "immutable" state variable is set during contract creation and it cannot be changed after the contract has been deployed to the blockchain.

contract Example {

    uint256 public immutable timeDeployed;

    constructor() {
        // the timedeployed is set during the contract creation
        timeDeployed = block.timestamp
    }
}

I originally found it a bit confusing to differentiate between a constant and an immutable, it almost seemed like they were the same thing, but here's an illustration that would help solidify the core differences.

The Differences

To illustrate:

Constants

Imagine you are a builder, and in the community you are assigned to build houses, there is a rule set by the government.

The rule states that "Every room in any house must have two windows".

This rule is set before the building starts, and it doesn't matter the style of house, or the size of it, as long as it has a room it must have two windows. That's the "constant" that has been set.

A constant is set before the building begins

Immutables

When building (Compiling) starts, imagine the first foundation brick you lay, bearing a unique serial number, that is assigned to it only during construction. When construction is complete (deployed), that serial number becomes permanent.
That means it is immutable, it can no longer be changed.

An Immutable is only set during the building process

Using the illustrations above you can note that:

• Constants are set before the building starts

• Immutables are set only during the building process

It is important to understand this because it can help you save on gas, if you use them the right way.

For instance :

constant' Keyword: Variables declared with 'constant' are variables that never change after compilation and are hard-coded into the contract. Since these values are constant and do not change, they do not require storage on the blockchain, which would incur additional gas costs. Instead, the value is replaced at compile-time wherever it is referenced in the code. This results in gas savings when interacting with these variables.

'immutable' Keyword: Immutable variables are assigned a value only once, during the contract's construction, and are stored in the contract’s storage. However, unlike regular state variables, accessing immutable variables is more gas-efficient. This is because the Ethereum Virtual Machine (EVM) replaces references to these variables with their assigned values after the contract is deployed, similar to constant variables. As a result, reading from immutable variables costs less gas compared to reading from regular state variables.

Did you learn anything new from this?

If you did,
Please share this article and give me a follow @CyberDev_d

Introduction

Decorators in general are not a fairly new concept, they've been in use in other languages such as python for quite some time, but they just came into the playfield with the Decorator ECMAScript proposal, which is currently in stage 3 as of this time of writing this article.

In this article, you should understand what decorators are, how to make use of them, and when it might be necessary to make use of them.

What are decorators?

Decorators are functions called on classes, class elements, or other JavaScript syntax forms during the definition. They are essentially higher-order functions,

  function double(Z){
   return function single(y){
      Return Z(Z(y));
  }
}

( a function that either takes another function as an argument and returns a value or a function that returns another function), which are written to extend the functionality of what is being decorated without fundamentally changing its behaviour.

According to the official ECMASCRIPT proposal for decorators Decorators have three primary capabilities:

• They can replace the value that is being decorated with a matching value that has the same semantics. (e.g. a decorator can replace a method with another method, a field with another field, a class with another class, and so on).

• They can provide access to the value that is being decorated via accessor functions which they can then choose to share.

• They can initialize the value that is being decorated, running additional code after the value has been fully defined. In cases where the value is a member of class, then initialization occurs once per instance.

Essentially, decorators can be used to metaprogram and add functionality to a value, without fundamentally changing its external behavior.

How do they work?

Syntax

There is no special syntax for defining decorators, any function can be applied as a decorator.

A decorator expression begins with the @ and is followed by the name of the decorator. Decorators are called with () and could receive arguments. Arbitrary expressions could also be used as a decorator using the syntax @(expression). Class expressions could be decorated, not just class declarations. Decorators come after export and default .

// Decorator  being defined
function Decorator (value, context){
  return value.call();
}

// decorator expression being used
@Decorator 
randomFunction(){
  //Do something
}

//or

@Decorator("Some Value")
randomFunction(){
  //Do stuff here...
}

Decorators begin with the "@" symbol at the very start or top of the function they are trying to decorate. For example, @Decorator above is a decorator that has been declared for the method randomFunction(){}.

Decorators can be applied to four types of values:

• Classes
• Class Fields
• Class Methods
• Class accessors

When decorators are applied, they are evaluated in three steps:

1. First the decorator expressions ( the thing after the @) are evaluated interspersed with computed property names. This action flows from the left to the right and from top to bottom. The result of this evaluation is stored in the equivalent of local variables to be later called after the class definition initially finishes executing.

2. Decorators are called (as functions) during class definition, after the methods have been evaluated but before the constructor and prototype have been put together. For example @superUser decorator could be evaluated to the function

// @superUser evaluats to  ==> 
function superUser(){
  //do stuff here
}

.

When a decorator is called, it receives two parameters;

1. The value being decorated or undefined when it's a class field being decorated
2. A context object containing information about the value being decorated

// JavaScript takes an input and context object
const Decorator = (input, context) => {
  return output
}

// Using typescript interface for clarity
type Decorator = (value: Input, context: {
  kind: string;
  name: string | symbol;
  access: {
    get?(): unknown;
    set?(value: unknown): void;
  };
  private?: boolean;
  static?: boolean;
  addInitializer?(initializer: () => void): void;
}) => Output | void;

The values passed in the context object vary according to the type of value being decorated (classes, class methods, class fields, class accessors).

3.) Decorators are applied (mutating the constructor and prototype) all at once after all of them have been called. First, the newly constructed class is not made available until after all methods and non-static field decorators have been applied, then the class decorator is called only after all methods and field decorators are called and applied. Then finally, all static fields are executed and applied.

Decorators for Class Methods

type ClassMethodDecorator = (value: Function, context: {
  kind: "method";
  name: string | symbol;
  access: { get(): unknown };
  static: boolean;
  private: boolean;
  addInitializer(initializer: () => void): void;
}) => Function | void;

The class method decorator receives the method that is being decorated as its first value, and can optionally return a new method to replace it. If a new method is returned, it will replace the original on the prototype or on the class itself in the case of static methods.

For example:

// The @logged decorator receives the original function `m()` and returns 
// a new function that wraps the original and logs before and after the function is called

function logged(value, { kind, name }) {
  if (kind === "method") {
    return function (...args) {
      console.log(`starting ${name} with arguments ${args.join(", ")}`);
      const ret = value.call(this, ...args);
      console.log(`ending ${name}`);
      return ret;
    };
  }
}

class C {

  // Method decorator "logged"
  @logged
  m(arg) {}
}

new C().m(1);
// starting m with arguments 1
// ending m

Decorators for Class fields

type ClassFieldDecorator = (value: undefined, context: {
  kind: "field";
  name: string | symbol;
  access: { get(): unknown, set(value: unknown): void };
  static: boolean;
  private: boolean;
}) => (initialValue: unknown) => unknown | void;

Unlike the method decorator, the class field decorator doesn't have a direct input value when being decorated. Instead, users can optionally return an initializer function which runs when the field is assigned. This will receive the initial value of the field and return a new initial value. If any other type of value besides a function is returned, an error will be thrown.

function logged(value, { kind, name }) {
  if (kind === "field") {
    return function (initialValue) {
      console.log(`initializing ${name} with value ${initialValue}`);
      return initialValue;
    };
  }

  // ...
}

class C {
  @logged x = 1;
}

new C();
// initializing x with value 1

It's also worthy to note that since class fields already return an initializer , they do not receive addInitializer and cannot add additional initialization logic.

Decorators for Classes

type ClassDecorator = (value: Function, context: {
  kind: "class";
  name: string | undefined;
  addInitializer(initializer: () => void): void;
}) => Function | void;

Class decorators receives the class that is being decorated as a the first parameter and then returns a callable ( a function, a class or a Proxy) to replace the original class. If a non callable is returned an error will be thrown.

function logged(value, { kind, name }) {
  if (kind === "class") {
    return class extends value {
      constructor(...args) {
        super(...args);
        console.log(`constructing an instance of ${name} with arguments ${args. join(", ")}`);
      }
    }
  }

  // ...
}

@logged
class C {}

new C(1);
// constructing an instance of C with arguments 1

Here's how to use Decorators in your next project

JavaScript

Decorators haven't been natively added into JavaScript, and it's still in stage 3 of the 4 staged approval process. Therefore to use decorators in our project we need to set up a transpiler such as babel.

Here's a plugin for decorators in barbel https://babeljs.io/docs/en/babel-plugin-proposal-decorators

Typescript

If you are using Typescript you first need to enable the experimental Decorators compiler option either on the command line or in your tsconfig.json to properly use decorators:

Command Line:

to --target ES5 --experimentalDecorators

tsconfig.json:

  "compiler options": {
    "target": "ES5",
    "experimentalDecorators": true
  }
}

Let's get you started..

So you've finally decided to go with nest.js and you intend to set up your first project, in order to do that here's what you need:

• Node.js latest version

• Nest.Js CLI

To install the Nest.js CLI use this command: $ npm i -g @nestjs/cli

Once you have installed the above requirements, you now have the opportunity to use the Nest.Js CLI, with this you can scaffold a new Nest.Js project with just a single command Nest new [New project name].

Here's how to do it.

Step 1

Open your terminal in the directory you want your project to be stored in. For example, the screenshot below shows mine open in a directory named " learn_nestjs_with_apis ".

Step 2

Type the following command into your terminal Nest new [New project name] replace [New project name] with the name of your new project like the screenshot below:

Step 3

Pick your preferred package manager. I'd pick NPM for this article, as seen in the screenshot below.

allow packages to install

once that is done you should see this in your terminal

One last thing! You need to verify your folder structure to ensure the installation was correct, take a look at the folder structure below, that's what yours should look like.

Then finally you can start your project by running this command npm run start:dev

Congratulations! you've successfully set up your first Nest.js project!

Thank you for reading, please do follow for more articles