Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Most engines do the latter for export, but leave handling the correct formatting to get an asset into the engine, up to the user. And if its not just so, theres few post-import tools to edit or adjust the outcome. I can understand this in the more serious IDEs because of the wide variety of 3rd party tooling, and platform-specific formats that need to be accounted for.
I don't know if I'll even need everything I designed, or if I want to implement it, but for example I should be able to do playtests (run in engine) with hot reloads, debug tests (console output + debugging), test builds (export with logging enabled), and final builds (no logging), or even create custom configurations. -
The current design allows for rewindable versioning, on a per platform basis, and a very straightforward export pipeline that cleanly separates builds by platform, each folder holding builds (both internal and builds proper) that in turn each holds a folder that holds a versioned series of builds for that build type on that platform, from oldest to newest, so if anything goes wrong at any time the user can always revert and look for changes.
Or instead of building all that shit I could just use git. I don't fucking know.
Whats major is I don't want to have to do manual exports (click+drag, copy/paste, etc) every time, for every platform. I want one and done. Click a button and its exported, assuming everything is configured, and I've dotted my tits and crossed my eyes. -
All the other shit is obvious, visual tools for managing w/ components are attached to what entities. An entity browser, with assignable sprites. An entity editor, for editing field values of components attached to an entity class. prefab builder, with relevant hover-over field editors.
And of course a basic map editor.
And of course, half the power of tooling is in managing data and the ease of asset change.
That means a 'logical' tile manager. Whats that? Instead of these basic bitch sprite-import splicers, instead I can visually browse through collision shapes or create new ones and assign them to tiles--along with tile names and tag data, and rearrange the tiles in the set by simply clicking and dragging, to better manage them based on frequency of use, interest, and so on.
Maybe I'm fucking spoiled & want the best. But it seems like when somethings almost perfect, it always leaves you wanting more.
Mores the fucking pity. -
yeah i remember spending a significant amount of time implementing the loading, unloading, de+serializing modules and assets and architecting all that in a way that is not cancer to use in an earlier iteration of that one engine i did years ago. And i completely ignored change management and the compounding thing, that ubity did woth prefabs, because it wasn't a requirement back then.
-
@thebiochemic we learn from the past and realize the past sucks. and then we build better.
or in the case of front end, or in the case of js frameworks, reinvent the wheel. -
I found most of this really interesting to read, but I wonder technically what kind of solution you were aiming for, as in: how "swappable" should game engines be? Are you thinking of an API, CLI, UI or all of that?
FWIW I've implemented some things of which you spoke in another context using: docker base image management (<platform+major_ver>/<software>/<software_major_ver>), with a CLI to scaffold & generate Dockerfiles & use Gitlab CI pipelines for release & test automation and as UI triggers. Could a combo of svc SaaS + git + scripting/build tools achieve your aim? -
@webketje actually it could, if only docker were more portable across platforms.
or there were a more lightweight version of docker.
I just finished designing an entire asset management pipeline and christ on a fucking pogo stick, if it isn't convoluted.
Theres a lot of game engines out there, but all of them do it a little different. They all tackle a slightly different problem, without even realizing it.
1. asset management
2. asset change management
3. behavior change management
4. data management
5. combinatorial design management.
6. Combinatorial Behavior management
7. Feature completion
ASSET MANAGEMENT is exactly what it says on the tin.
ASSET CHANGE management can be thought of handling the import, export, formatting, platform specific packing, and versioning (including forking) of an asset.
BEHAVIORAL CHANGE management is a subset of asset management, because code is a subset of assets (depending on how you define 'assets'). The oldest known example of this is commenting and uncommenting code.
Or worse, printf debugging.
This can be file versioning, basic undo services, graph management of forks and mergers, toggles for features or modules, etc.
DATA management is about anything that doesn't fall into the other categories, everything from mission text to npc dialogues, quests, location names, item stats, the works. Anything you'd be tempted to put in a database, falls under this category. Haven't yet seen many engines offer this as an explicit built in tool as of yet, because the other problems are non-trivial as is, so this is a bit of low hanging fruit that gets handled by external tools, or loaded from formats as simple as json.
COMBINATORIAL DESIGN management is the idea of prefabbing, blueprints of broader object design using nested prototypes of existing game objects, to create more complex, reusable set pieces. Unity did this well. GM does this in part.
COMBINATORIAL BEHAVIOR management is entity-component systems, plus tooling to make it easy to add, remove, and configure components and their values on entity blueprints, also not uncommon. Both stencyl and unity do this. GM has a precursor to this in the form of configurable fields, but these fields are not based on component scripts attached to objects.
FEATURE COMPLETION is that set of gameplay mechanics or styles of design that an engine naturally makes easier to include or build in a game.
I don't think I'm aiming for all that, but I think at minimum a good engine has to do asset management, behavioral change management, prefabs, and entity-component systems with management tools for that. And ideally, asset change management.
rant
game engines