GameDev - gusenov/kb GitHub Wiki

Books

History

Today

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

Languages

Rust

C++

Python

Go

JavaScript

C#

Haskell

GDL

Databases

Hot Reloading

Math

Physics

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

  • FH Vorarlberg / Game Engine Architecture
  • Game Engine Architecture
  • Foundations of Game Engine Development by Eric Lengyel
    • Volume 1: Mathematics - 200 pages
    • Volume 2: Rendering - 412 pages
  • Multi-Threaded Game Engine Design by Jonathan S. Harbour - 592 pages
  • IndieGameDev
  • Wikipedia
  • gcup.ru Всё о создании игр
  • Хабр
  • DTF
  • Mod DB / Engines for Games
  • LINUX.ORG.RU
  • Godot for AA/AAA game development - What's missing?
    • Rendering
      • compatibility backend
        • based on OpenGL ES 3.0 / OpenGL 3.3 / WebGL 2.0 and is intended to run on very old PC hardware as well as most older (still working) mobile phones
      • modern backend
        • implemented in drivers such as Vulkan, Direct3D 12
        • can implement rendering methods, such as forward clustered, mobile, and more in the future (such as deferred clustered, cinematic, etc.)
      • using data oriented algorithms to process the culling of objects and both secondary command buffers and automatic batching to efficiently submit the draw primitives
      • material options and advanced visual effects (including circle DOF (Depth of Field), volumetric fog, AMD FSR, etc.)
      • advanced global illumination techniques such as lightmapping (including SH (Spherical Harmonics) lightmapping), Voxel GI (which is fully real-time) and SDFGI (Signed-Distance Field Global Illumination) (which is a single click, open world GI solution)
      • Screen space GI can be used to enhance the realism even more.
    • Low level rendering access
      • there is no architecture that can be considered a one size fits all solution
      • cater to solving the most common use cases, and leave the door open for users to solve the less common on their own
      • low level access to all the rendering server structures
      • creating custom renderers or plugging custom code during the rendering steps, which is very useful for custom rendering techniques or post processes
    • Physics
      • soft bodies and cylinder shape support
      • multiple threads
      • ability to bind custom physics engines at runtime
        • integrate other engines such as PhysX, Jolt, or Box2D if needed
    • Scripting
      • lambdas
      • first class functions/signals
      • useful built-in data types such as integer vectors
    • Visual scripting
      • visual scripting really shines when combined together with the premade behaviors
      • Without a significant amount of high level behaviors available, visual scripting is cumbersome to use as it requires a lot of work to achieve simple things by itself.
    • Core engine
      • optimized, especially in the memory and data-oriented areas
    • Extension
      • add features to it practically in any language and without recompiling the engine
      • modules
      • pluggable, dynamic add-ons
      • modular game engine
      • achieve results by combining what is there
    • Editor
    • UI system
    • Multiplayer
    • Navigation
    • Audio
    • Animation
    • Streaming
      • The traditional way to make games longer since the beginning of times is to divide them in stages. As soon as one stage is completed, it is unloaded while the new one is loaded.
      • Increasingly, game design has been moving from “individual stages” to “open” or “continuous” worlds where the boundaries between levels disappear.
      • This is handled nowadays by a type of technology called “streaming”. It means that assets are pulled from disk on demand (loaded only at the time they are needed), rather than as a part of a larger stage. The most common types of streaming are:
        • Texture streaming: All textures are loaded in a tiny size by default. As textures get closer to the camera, higher resolution versions (or mip-maps) are streamed from disk. Textures which haven’t been used for some frames are freed instead. At any given time, the textures loaded (and their detail) closely reflect the place the player is in.
        • Mesh streaming: Models are loaded as low detail (few vertices). As they gradually approach the camera, higher resolution versions are streamed from disk. Models that were not used (displayed) for a while are often just freed and will be loaded again when needed.
          • The most complex is mesh streaming, which generally needs to be implemented together with a GPU culling strategy to ensure that very large amounts of models can be drawn at no CPU cost.
        • Animation streaming: Modern games have long cinematics, which require a lot of animation data. Loading those animations requires a lot of memory and loading them takes a lot of time. To avoid this, animations are streamed by generally keeping the first second or two in memory and then new sections are loaded on demand as the animation plays.
        • Audio streaming: Similar to animation streaming, it requires storing the first second or two of audio and then streaming the rest directly from disk.
      • most important feature missing for managing large scenes or open worlds
      • There is also a risk of running out of memory if too many assets are loaded in parallel instead of streaming them.
    • Scene job system
      • servers (rendering, physics, navigation, etc.)
      • Servers are also now multithreaded
      • asset loading can now be done multithreaded (using multiple threads to load multiple assets)
      • scene system (which uses those servers)
      • Scene nodes are mostly intended to carry complex high level behaviors (such as animation trees, kinematic characters, IK, skeletons, etc.)
    • Swarms
      • Scenes, as mentioned before, are designed for complex high level behaviors in the hundreds of instances.
      • Still, sometimes, some games require larger amounts of instances but less complex behaviors instead. This is needed for some types of game mechanics such as:
        • Projectiles (bullet hell for example).
        • Units in some types of strategy games with thousands of entitites roaming across a map.
        • Cars/people in city simulators, where thousands appear all across the city.
        • Sandbox style simulations.
        • Complex custom particles that run on CPU.
        • Flocks, swarms, mobs, debris, etc.
      • swarm system that takes care of the rendering and physics in large amounts of those objects and the user only has to fill in the code logic
    • Large team VCS support
      • friendly to version control
      • integration with the filesystem dock
      • real-time refresh of assets if they were modified externally (and checked out)
      • Support for permissions and file locking: Git does not support this out of the box, but Git LFS and Perforce do. This feature is essential for large teams to avoid conflicts and keep files protected from unintended modifications (e.g. a team member modifying code or a scene they don’t own by mistake).
    • Commercial asset store
      • medium-sized studios still rely on significant amounts of assets and pre-made functionality
    • Game specific templates and behaviors
      • provide a great set of building blocks that can be used and combined to create more specialized game functions and tools
      • high level and ready to use components and behaviors
      • player controller
      • environment controller
      • tools to manage the game pacing and flow
    • Specialized artist UIs
      • The difference is not so much in features supported. In fact, the feature set is fairly similar! The main actual difference is in how they are presented to the user.
      • entirely dedicated and isolated interfaces for each of these tasks (materials, cinematic timeline, VFX, animation, etc.)
      • Sure, they are monolithic and hence less flexible, but for a large team with high amounts of specialization, an artist does not need to understand as much in-depth how the engine works in order to produce content with it.
      • provide simpler and more monolithic interfaces for artists to be able to do their job without requiring significant time investment in learning the technology
  • SteamDB / Technologies Статистика использования игровых движков в играх на Стиме
  • OSS Insight / Game Engine - Ranking

Unreal Engine

Pixel Streaming

4

5

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)

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

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

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 раскритиковал ручные сохранения в играх
    • По большому счёту, они позволяют игрокам избежать наказания за неверное решение, отчего в целом снижается азарт и падает внимательность: сложно относиться к игре всерьёз, если знаешь, что по нажатию одной кнопки можно запросто отменить любую свою ошибку.

Blockchain

Indie

From scratch, reinventing a wheel

LOLZ