{"id":13534148,"url":"https://github.com/HacksawStudios/GASM","last_synced_at":"2025-04-01T22:31:15.378Z","repository":{"id":87523035,"uuid":"123915389","full_name":"HacksawStudios/GASM","owner":"HacksawStudios","description":"Framework agnostic EntityComponent System for Haxe","archived":false,"fork":false,"pushed_at":"2021-03-19T13:57:50.000Z","size":600,"stargazers_count":20,"open_issues_count":1,"forks_count":2,"subscribers_count":5,"default_branch":"develop","last_synced_at":"2025-03-28T19:06:07.253Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Haxe","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/HacksawStudios.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2018-03-05T12:20:44.000Z","updated_at":"2022-12-17T09:28:26.000Z","dependencies_parsed_at":null,"dependency_job_id":"7a771645-e731-4bdd-b6be-129735602c72","html_url":"https://github.com/HacksawStudios/GASM","commit_stats":null,"previous_names":[],"tags_count":140,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HacksawStudios%2FGASM","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HacksawStudios%2FGASM/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HacksawStudios%2FGASM/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/HacksawStudios%2FGASM/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/HacksawStudios","download_url":"https://codeload.github.com/HacksawStudios/GASM/tar.gz/refs/heads/develop","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246720510,"owners_count":20822913,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T07:01:26.994Z","updated_at":"2025-04-01T22:31:14.907Z","avatar_url":"https://github.com/HacksawStudios.png","language":"Haxe","funding_links":[],"categories":["Libraries"],"sub_categories":["Haxe"],"readme":"# GASM ECS\r\n\r\nFramework agnostic ECS layer.\r\n\r\n## What is it?\r\nEntity Component System heavily inspired by Flambe, but which is designed not to be tied to a particular renderer. So for example it could be used together with HEAPS, OpenFL, Pixi or Kha.\r\nThe idea is to abstract the features that are common across frameworks, for example by having a sprite component tied to a sprite model with data such as x and y position.\r\nYou can then add components modifying the sprite model without being tightly coupled to a Sprite class from a particular framework.\r\n\r\nThis will remove a lot of the coupling between game code and rendering framework, but not to remove it completely since that would mean having to limit yourself to features that can reliably be replicated between frameworks. However it means that you can reuse a lot of components without modification, and should minimize the effort of porting a game to a different renderer.\r\nTargeting a new framework means writing a few classes to ensure that the Entity graph is tied to the rendering system and models for graphics and sound that can interface with the framework classes. \r\n\r\nNote that ECS purists will not consider this a proper ECS framework, since components contain the logic instead of systems. If you are writing a complex RPG or MMO, proper ECS might be worth looking in to, but for more typical small scale web or mobile projects I think having logic in components is preferable.\r\n\r\n## Why should I use it\r\nThere are several complete game engines using ECS, that are easy to work with and perform well (Flambe, Unity, Phaser, etc).\r\nHowever, when working with games that can have a commercial lifespan spanning decades, often they can outlast the technology which can turn very costly to address if the code is coupled to a specific stack. Haxe allows reaching many different platforms, and makes it possible to write code that transcends specific platforms, but typically you will still depend on for example OpenFL to abstract platform specific functionality.\r\nGASM takes this one step further, and makes it possible to with minimal effort switch to a new platform abstraction should the need arise.\r\nHowever, in the case of GASM the abstraction does add another layer of complexity and does cost some performance, so is essence there are two scenarios where GASM is a good choice: \r\n1. You work with games that have a long lifespan, and want to abstract as much as possible from underlying technology to minimise risk and cost associated with having to port your games in the future.\r\n2. You like the ECS flavor, and want to use it with your platform abstraction of choice.\r\n\r\n## What does it mean?\r\nThe name comes from the separation added to different component types, Graphics, Actor, Sound, Model. \r\nGASM has model types for graphics (SpriteModelComponent, TextModelComponent) and sound (SoundModelComponent) which are used to interface with the framework used. \r\n\r\nRegardless of in which order components are added, they will always be updated in the following order:\r\nModels -\u003e Actors -\u003e Graphics -\u003e Sound\r\n\r\n## Current status\r\nProject is under active development and the current focus is having a stable HEAPS adapter and fixing any issues we might encounter while making our first games using the framework. An OpenFL adapter exists, but is no longer maintained since we decided to go with HEAPS instead.\r\nSome optimization is done to ensure performance seems acceptable, and at least with the shallow entity graph in the bunny mark test in examples, the overhead introduced by the framwork seems like it should be acceptable for most games. Compared to Flambe there will be additional overhead due to two things:\r\n- The model components added to interface between graphics objects in different frameworks means extra calls when updating an Entity.\r\n- Extra logic to ensure the different component types are updated in the correct order.\r\n\r\n## Future plans\r\nGASM will only handle parts which makes sense to abstract, and currently no additional features are planned. SOme more generally useful components might be added as the need arises, but for now there are none planned.\r\n\r\n## Usage\r\nRun:\r\n```\r\nhaxelib install gasm\r\n```\r\nThen add the integration for the backend you want to use:\r\n```\r\nhaxelib install gasm-openfl\r\n```\r\nor\r\n```\r\nhaxelib install gasm-heaps\r\n```\r\n\r\nThose are also available as npm packages, and assuming you already installed haxe-module-installer you can use:\r\n```\r\nnpm i -D gasm\r\nnpm i -D gasm-heaps\r\nnpm i -D gasm-openfl\r\n```\r\n\r\n## Getting started\r\nHave a look the the examples for some ideas of how to use GASM:\r\nhttps://github.com/HacksawStudios/GASM-examples\r\n\r\n## Features\r\n1. Core ECS implementation\r\n\r\nEntity and Component classes.\r\n\r\n2. LayoutComponent\r\n\r\nCan be used to position and scale display objects to create layouts.\r\n\r\n3. Loader\r\n\r\nBoth HEAPS and OpenFL offer asset management, but they are designed to have assets available at compile time. If you need to do runtime loading you will have to make your own solution. In our case we do branded and localized games, and don't want assets to be compiled with the game.\r\nThe Loader class can optionally be configured to handle branding, platform and locale specific resources with fallback while providing accurate loading progress.\r\nSee Preloader class in gasm-heaps for an example of usage and preloader integration.\r\n\r\n## Compatibility\r\n\r\nThe goal is that the core ECS system should be possible to use for an integration on any target.\r\nSo far only core entity component functionality is tested on Haxe 3.2.1 and 3.3.0 with the following targets:\r\n  neko\r\n  python\r\n  node\r\n  flash\r\n  java\r\n  cpp\r\n  cs\r\n  php","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FHacksawStudios%2FGASM","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FHacksawStudios%2FGASM","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FHacksawStudios%2FGASM/lists"}