GameDev - gusenov/kb GitHub Wiki

misc.

Books

History

Today

What's next

Device

  • Steam Deck
    • Wikipedia
    • «В моем ПК стоит процессор AMD, видеокарта Nvidia, сам ПК от Falcon Northwest, плюс у меня есть мышь Corsair, клавиатура Logitech и монитор Samsung. Именно эта взаимозаменяемость деталей, совместимость и открытость платформы позволяют нам создавать такие продукты, как Steam Deck» (Габен)
  • Overclockers.ru / Valve: геймеры массово переходят с клавиатур на геймпады
  • GameDeveloper.com / Designing Game Controls

Developers

Patterns

Game Loop

Animation

Procedural Generation

Generative AI

Midjourney

Muse AI

Languages

Rust

C++

Python

Go

JavaScript

C#

Haskell

GDL

Databases

Hot Reloading

Math

Physics

KawaiiPhysics

Havok

Audio

Visual

Pixel Art

Character controller

AI

GUI

Job System

Games

Multiplayer

Security

Data-Oriented Design

  • Wikipedia
  • A curated list of data oriented design resources
  • Mike Acton "Data-Oriented Design and C++"
  • Games from Within / Data-oriented design
  • CppCon 2018 / Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”
  • Data-Oriented Demo: SOA, composition
  • Data-Oriented Design
  • Data-Oriented Programming. Reduce complexity by rethinking data by Yehonathan Sharvit - 451 pages
  • An introduction to Data Oriented Design with Rust
  • Andrew Kelley
  • Хабр
  • Our Machinery
  • BSVino/JaiPrimer: A description of Jonathan Blow's programming language, Jai
  • reddit
    • Is structuring game data like a database a good idea?
      • Data Oriented Design
        • it is possible to structure an entire game as an in-memory database
        • "table oriented design": object impedance mismatch (which occurs when building OOP apps on top of relational databases) can be solved by designing the app around the database as closely as possible, in other words embracing relational models and completely kicking OOP to the wayside
        • think of a structure of arrays like it's a table with fields
        • instead of implementing databases with SQL, I can implement them with structs containing C++ std::vectors (or any type of dynamically allocated array)
        • code (pure functions) operates on these arrays
        • program can be turned into a flat pipeline (of pure data transformations) with an obvious dataflow, simplifying optimization, design and debugging
        • Because the data is stored in arrays (vectorized), utilizing SIMD instructions, applying loop optimizations (like loop nest optimizations), improving cache usage, reducing memory usage (by recycling and minimizing allocated arrays), utilizing CPU cores (data and task parallelism) all become trivial to add to the program.
        • actual design of the data can be done with regular relational modelling tools (ER diagrams, normalization, etc.)
        • structuring games via relational modelling is like an entity component system but with the entities being implicitly defined rather than being explicitly defined
      • when I mean database, I mean structure of arrays where the arrays are like columns and the structs are like tables
      • moving from an Array of Structs style to a more Struct of Arrays style of organising data
      • think about your access patterns. Does it make sense to chuck everything into a big-ass array? Maybe, but maybe not.
      • What about if you need to only access objects in the player's immediate area? Why bother running AI, scripting, and rendering for stuff all the way across the map that the player can't see or interact with? In this case, maybe partition the map into "chunks", each one composed of an array of only the data that chunk needs. Then only update/render the chunks in a given radius of the player.
      • think about the data you need, and consider how to organize it in a way that gets it through the transforms needed as fast as possible
      • computer memory literally just one "big-ass array" of bytes
        • NO
          • quick Google search into cache hierarchies will show you it's a lot more complicated than just a big array of bytes
          • memory, at the level of the hardware, is more complex than just a long line of byte-sized cells, and although, as you say, there are various abstractions over that
          • caching is far more about accelerating reads than writes
          • caches are small and rely on data being accessed from sequential memory locations, and if your data isn't accessed from sequential locations, you gain no benefit from caches at all. So regardless how seamless the user-facing memory model is, laying data out in one order vs. another — while totally equivalent in the model — can be the difference between the cache working for you or not at all.
          • Virtual memory is a whole other topic and set of performance considerations, and has far more to do with the total RAM your software uses (vs. how much physical RAM the machine it's running on has).
          • If you mean how the data is stored on your hard drive, then no, it hasn't been one huge array for quite a while now, physically speaking. From a logical perspective yes, memory is a huge array, files are arrays of bytes, etc.
        • YES
          • Even if a computer has a very complicated memory model, the instruction set architecture and the operating system almost always present an interface to the memory as if the memory were a flat array of bytes. And every complicated memory model that I've discussed is basically about taking a large array of bytes and partitioning it into smaller slices/subarrays.
          • Caching happens transparently to the end user. If I write to an integer in memory, then the integer (4 bytes) and the surrounding 60 bytes (for a 64 byte cache line) are loaded into a cache line. In other words, the cache is trying to anticipate all data accesses (temporal and spatial cache locality). Whether I'm using any of the other bytes it loads or not is irrelevant. If I don't set my data to be contiguous in memory, then I'm not guaranteed to be fully utilizing the cache lines. It's as if the cache lines are like little arrays that multiplex slices of the larger array (memory).
          • virtual memory addressing is another example of an abstraction that makes memory more complicated. And yet again, it's the operating system that transparently takes care of calculating base and offset registers for each and every process, ensuring that no two processes can overlap in memory. The end user doesn't even need to know that it exists. It's as if the operating system splits the memory (full address space, which is like an array) into smaller sub arrays/slices, where reading and writing from the sub arrays/slices is "bounds checked" to make sure that the data accesses of one processes' owned virtual address space (which is basically a slice/sub array) does not trample on any others. That's "memory safety" in a nutshell.
          • page tables are similar to the above concept, except that the memory is divided into equally sized and aligned subarrays/slices of the larger array (memory), which are called "pages". Then each process gets a base and an offset not of bytes, but of pages.
          • memory is not an array of bytes... it's an array of bytes that is treated like many smaller arrays of bytes. And each process only gets one.
      • Data Oriented Design is more than just "pack it all into arrays". It's a way of viewing your application from the perspective of data transformations over time, rather than from the objects/messages method of Object Oriented Design, or the provability/mutations method of Functional Programming.
      • it all comes down to taking the data from one state to another. And yes, oftentimes a struct of arrays format with all necessary data packed together and coherent is the best way of doing that transformation.
      • you still need ways to sort data, do searches on it, compress/decompress it, serialize it, decode/encode it. And doing all of that in an O(n) or worse way can be a nightmare for performance.
      • chunking and sharding are common mechanisms for speeding up data access when there are vast datasets (think Terabytes) and massive concurrent access (think thousands or even millions of request per-second).
      • added complexity from the actual graphics-engine side, performance considerations and horribly designed (from a Software Architecture point of view) game frameworks push game devs away from thinking about game data as a whole (i.e. a data structure) and from keeping it apart from non-data elements.
      • many data structures and algorithms can be designed (read: flattened) to utilize arrays
        • It is possible to take a binary tree (implemented using pointers and heap allocations) and flatten it so that all of the nodes are in an array, for example: [0,1,2] could be interpreted as node 0 having child nodes 1 and 2. Binary searching, an algorithm, can be done on data in binary trees and arrays (because of the previous sentence).
        • Hashmaps can be implemented with linked lists or dynamically allocated arrays. A perfect hashing function can have it's entire range (possible outputs) mapped into an array that is the perfect size. No allocations outside of the first ever need to be done. For a leetcode question that I did, the most optimized solution to a problem that used a hash map for a less optimized solution, was an array that was treated like a hashmap with a perfect hashing function. I think it was the longest unique substring problem, which uses a sliding door and an array that's just big enough to store 256 chars or something.
        • And for other types of graph traversal problems, adjacency lists and adjacency matrices can all be implemented with arrays.
      • inserting into arrays is very slow (because it requires copying and pasting the entire array to a different hole in memory). So I can definitely see the strengths of heap allocation based data structures (like graphs) for data that is more dynamic than it is static. And then array based data structures are better for data that is more static than dynamic. And when I say dynamic, I mean that the size isn't known, or the data needs to be shifted around or moved a lot, as opposed to being transformed in place.
      • if I use data structures that are not contiguous, then the cache will contain a lot of unused data. But many of the data structures that I've mentioned can be made to be contiguous.
      • SoA approach
        • pack the cache with only the data relevant at the time
        • If you need to update positions before doing collisions, and handle collisions before rendering, it makes sense to encapsulate only the necessary data from each step into their own arrays.
      • If I don't vectorize my data, how can I take advantage of SIMD?
      • Unity heavily uses object composition (i.e. make a health class and instantiate it in the zombie class, player class, dog class and whatever else has health, as opposed to making an inheritance hierarchy in which zombies, players and dogs all instead inherit from the Health class.)
    • Is structuring game data like a database a good idea?
      • OOP in games, especially heavy OOP often gets a bad rep in games.
      • You could check Unity's DOTS initiative if you want to see examples of data oriented design in a high-level C# subset

SBC

OS

Android

Linux

Web

Qt

Game engine

Unreal Engine

Pixel Streaming

4

5

6

Unity

Godot

The Mirror

Roblox

Amazon Lumberyard

NVIDIA

Autodesk

Apple

Google

SDL (Simple DirectMedia Layer) is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D.

PySDL (pure Python wrapper around the SDL2, SDL2_mixer, SDL2_image, SDL2_ttf, and SDL2_gfx libraries)

SFML (Simple and Fast Multimedia Library) provides a simple interface to the various components of your PC, to ease the development of games and multimedia applications.

LibGDX

raylib A simple and easy-to-use library to enjoy videogames programming

  • raysan5/raylib A simple and easy-to-use library to enjoy videogames programming

Flame engine

MonoGame

Cocos Engine

Pygame is a set of Python modules designed for writing video games.

jMonkeyEngine (is a game engine for developing 3D games written in Java.)

Unigine

  • Wikipedia
  • Oil Rush компьютерная игра в жанре стратегии в реальном времени, разработанная компанией UNIGINE Corp.

Urho3D (free lightweight, cross-platform 2D and 3D game engine)

Defold (Cross platform game engine)

Permafrost Engine (OpenGL 3.3 Real Time Strategy game engine written in C)

Xash3D (open-sourced alternative for all fans of Half-Life modding)

NeoAxis Engine (Real-Time 3D, 2D Development Platform)

ClanLib is a cross platform C++ toolkit library with a primary focus on game creation.

Löve (framework you can use to make 2D games in Lua)

INSTEAD (программа-интерпретатор для простых текстографических приключенческих игр)

Stratagus (free and open-source cross-platform game engine used to build real-time strategy video games)

PixelLight (cross-platform 3D engine)

id Tech 4 (popularly known as the Doom 3 engine)

DarkPlaces (форк известнейшего игрового движка Quake engine)

Torque3D (C++ engine)

Irrlicht Engine (open-source game engine written in C++)

Panda3D (open-source, completely free-to-use engine for realtime 3D games, visualizations, simulations, experiments)

ursina engine A Python powered, open source game engine

Delta3D (open source software gaming/simulation engine API)

Cafu Engine

Nebula Device

ShiVa Engine (Cross-platform Game Engine and IDE)

Dagon Engine (Open Source 3D game development framework based on OpenGL 4.0 core profile and SDL2)

Rod (cross-platform 2d and 3d game engine for Nim)

OpenMW

Spring RTS Engine

FIFE (Flexible Isometric Free Engine) (free, open-source cross-platform game engine)

Fyrox A feature-rich game engine built in Rust

gameplay3d free 2D/3D game framework

Halley Game Engine A lightweight game engine written in modern C++

Castle Game Engine Free open-source cross-platform 3D 2D game engine with editor and powerful Pascal API

GDevelop Free, Fast, Easy Game Engine - No-code, Lightweight

GameMaker.io 2D Game engine

Flax Engine

Nau Engine

Claw Engine

Creation Engine

HaxeFlixel Free, cross-platform 2D game engine powered by Haxe and OpenFL

RPG Developer Bakin

CryEngine

Roadmap

Courses

Game Design

Игровые механики

Platformers

Jump

Story

Podcasts

Коллекции

Community

Conferences

Awards

Magazine

Press

Q&A

Marketing

Careers

Burnout

Competition

News

Monetization

Open Source

3D

Blender

Maya

Glossary

Cloud

Google Stadia (cloud gaming service)

Intel

JetBrains

Amazon

CI/CD

Prefab

Subscription

Test

Console

People

Reversing

Video Game Optimization

Profiling

Save

  • Wikipedia
    • Saved game is a piece of digitally stored information about the progress of a player in a video game.
  • 4PDA.to / Автор Fallout: New Vegas раскритиковал ручные сохранения в играх
    • По большому счёту, они позволяют игрокам избежать наказания за неверное решение, отчего в целом снижается азарт и падает внимательность: сложно относиться к игре всерьёз, если знаешь, что по нажатию одной кнопки можно запросто отменить любую свою ошибку.

Launcher

Blockchain

Indie

From scratch, reinventing a wheel

LOLZ