Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

park

5
Posts
3
Topics
11
Followers
2
Following
A member registered Feb 12, 2017 · View creator page →

Creator of

Recent community posts

Atlas community » Wiki · Created a new topic Modding

A mod contains:

  • An id (e.g. my_cool_mod)
  • A name (e.g. “My cool mod”)
  • An author (e.g. park64)
  • A mod version (e.g. 1.0)
  • A list of supported game versions (e.g. [ “0.4”, “0.3” ])
  • A description
  • Some files containing data and/or code

On disk, a mod should be a folder containing:

  • mod.jsonc, the mod’s metadata file
  • data/, if the mod is a data mod
  • mod.gd, if the mod is a code mod
  • supporting files, such as images, custom data, or scripts, if needed

More to come: modding API spec and mod examples

🫩

i do plan to add natural resources: stone, iron, coal, steel(iron+coal), aluminum, uranium, not sure after that

i do plan to add different crops and probably rice

brownian motion already in the game

Atlas community » Wiki · Created a new topic Under the hood

Engine

The game is made with Godot and written in Rust and GDScript.

  • UI, controls, and rendering are mostly handled by GDScript.
  • Simulation and performance code are handled by Rust.

Simulation

World

The world is divided into chunks that are 16 meters by 16 meters. Each chunk is divided into 256 tiles, each 1 meter by 1 meter.

The world is generated with three maps of procedural fractional Brownian motion (fBm):

  • Height map, to determine what is underwater and what is mountains
  • Hydration map, to determine what is grass and what is desert
  • Temperature map, to determine where trees can spawn

People

Person behavior is divided into two systems: tick and think. Think occurs every 0.5s to 2.0s and plans out the next sequence of actions to take, based on drives, traits, relationships, and external factors. Tick occurs every frame and acts upon the plan that was set forth during think. Tick is always executed every frame, but think is slowed down for people that are farther away from the player to save on resources. A think length of 2.0 causes no issues, but 0.5 is a little more responsive for player satisfaction.

Performance

Performance is a priority. On my development laptop (M4 Pro), the game runs steadily at 120fps both early game at 128x speed and late game at 16x speed.

Pathfinding

As usual, pathfinding is the biggest draw on performance. We make several optimizations. Pathfinding first starts at the chunk-level, where a person asks, “what chunks do I need to cross to get to this other chunk”? The chunk-level pathfinding makes educated guesses about where water is likely to be by sampling the center point and checking if it’s water.

When entering a new chunk, a new tile-level pathfinding request is made, where the person asks, “what path do I need to take to get to a certain edge of this chunk?” so that they can navigate to the next chunk in the chain.

If the total distance is shorter than 2 chunks, the game first attempts a simple raycast straight to the target. If raycast doesn’t hit anything, then we can walk in a straight line and don’t need to waste time on pathfinding.

The pathfinding can sometimes build up and cause a frame spike. This is fixed by designating a ‘pathfinding budget’, the number of paths that the simulation is allowed to serve per frame. Currently it is 256, so if more than 256 people request a path, some will not get it until next frame. This doesn’t cause issues as long as the person can get a path soon, as they will take an educated guess on the direction they should walk. At high game speeds (>32x), the pathfinding queue can grow infinitely and cause people to starve as they make incorrect guesses about how to get to the food.

Rendering

Most entities are currently simple rectangles (which will probably change), but rendering thousands of onscreen entities is made cheap with MultiMeshInstance2D, which allows us to draw several thousand meshes with one draw call.

Simulation performance

The game can maintain 120fps while simulating over 500,000 entities. It does this by managing all of these entities on the Rust-side, where they are lightweight and performant. Godot can only access the data that it needs through calls to the Rust-side API.

Modding

Warning! Mods can currently execute arbitrary code. There is no logic that stops a mod from mining bitcoin, installing viruses, stealing passwords, or worse. Do not ever download mods from untrusted sources.

The game will offer first-class modding support. Currently it is a second-class feature and is present but disabled by default.

Mods must be placed in the mods/ folder, which currently resides inside the .PCK data file. You can view and change the .PCK with tools like GDRE. In the future mods/ will be brought out into the game folder for easier installation.

A default code mod called mymod1 is present and shows how to instantiate a code mod.

A data mod can be created by putting a data/ folder inside of your mod folder. For example, to modify or add AI definitions, you would create mods/<my_mod_name>/data/ai/core.json and add your AI definitions to that file. Using an existing definition ID will overwrite it with your new definition when loading the game.

Datamining

I try to make GDScript accessible but make no effort to make the compiled Rust DLL accessible.

Currently the GDScript is compiled to bytecode, but online tools such as GDRE can restore the original code.

Atlas community » Wiki · Created a new topic About
(3 edits)

‘Atlas’ is the working name for a society simulation in early pre-alpha development.

This is a project that I started to see if my dream game was technically feasible. So far, it seems to be.

Here is what I aspire for this project to be:

  • Large (4-8 sq km) procedural open world
  • NPCs create and develop settlements with the player living among them
  • NPCs cannot tell if they are interacting with the player or another NPC
  • NPCs are complex, with their own traits, relationships, jobs, and desires
  • Settlements can rise and fall with or without the influence of the player
  • Settlements vote on their own laws, policies, and strategies

Here is where the project currently is (v0.3):

  • 16 sq km procedural open world simulating 1,000 NPCs
  • NPCs develop buildings in a settlement
  • NPCs have drives such as hunger, industry, and safety
  • NPCs dynamically plan a sequence of actions that satisfy the most drives at once
  • Economy system
    • Land owned by the settlement is sold off and property taxes are paid on the land
    • Landlords build houses, farmers build farms, bakers build bakeries, taxes paid by building owners; complete with landlords, farmers, haulers, lumberjacks, bakers, medics
  • Simulation can run at ~120fps on 32x speed

Here is what is finalized for next version (v0.4):

  • v0.3 features, plus:
  • Day/night cycle
  • Graphical improvements (terrain shadows, entity shadows, normal maps)
  • NPCs develop settlements on their own or choose to become a nomad
  • NPCs have personality traits
  • NPCs form relationships and remember each other
  • Talking NPCs choose phrases based on personality, relationship status, job, and external conditions
  • Settlements choose their own policies

More features are slated for v0.4 but are not yet finished, and may be bumped to v0.5, so I will not name them yet.

Please keep in mind this project is in early development and not considered a playable game. For now, this is a sandbox simulation that you can watch evolve until I iron out the kinks in NPC logic and implement a player controller.