How to make Assets (Serialized Components with Persist)?

[Christopher Sosa]

Hey!

I want to try to generate new Assets (those .json files in the Data/ExampleGame directory) for testing my new components & definitions and since the included assets (in terms of serialized components/definitions made by Reflect/Persist) are now outdated and doesn't work anymore with my changes such the removal the Bullet components, Renderers, and the Config assets for the Renderer and platforms. And the Editor project doesn't seems is complete in any way, so there's a method to generate them?

Thanks.

[Philip Degarmo]

Hey Christopher,

Most of the components needed to have the editor modify the data files are there - reflection, serialization, asset/package browsing, and the inspect UI library. However it's not hooked up and last I heard, inspect needs to be modernized a bit. There have been a TON of improvements to reflect, but inspect has not kept pace beyond keeping it compiling. All the example json data files you see were created by hand.

The asset system doesn't depend on the renderer, bullet, etc. So you can safely remove any references to those systems in the json files. It should have no problem constructing just your components and you could build your own components to interact with whatever other libraries/middleware you choose.

A word about the state of the project in general: The good news is that the base systems are in really good shape. Reflect and the serialization layer support a broad range of data types. The asset/package system is a bit young and could use some cleanup, but the architecture is in place and it's not a huge chunk of code since reflect does 90% of the legwork. The work over the past few years has been towards laying a foundation that supports features usually reserved for AAA engines and that is scalable to large projects. Unfortunately, this has been at the expense of high-level features like the editor. So while there is a lot of work to do to make the engine usable by non-programmers, it could be a really solid foundation to build exactly what you want, and the data-driven asset/component system should give you a good way to pull in other libraries to fill in the gaps.

I'm really excited you're playing with helium and I know Geoff feels the same way. So we are definitely happy explain the architecture and offer suggestions for suiting it to your needs.

Philip

--
You received this message because you are subscribed to the Google Groups "Helium Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to heliumprojec...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Geoff Evans]

Hi Chris,

I echo Philip's rundown of our current state of affairs.  We are mostly industry vets that like to take an industrial-strength approach to building good bones into Helium, which is why much of the tooling remains undeveloped.

Most of the bleeding edge work can be found in the game-refactor branch.  The work in progress there is meant to isolate each sample project to have distinct assets and code per-game-project, and will perhaps be a bit more understandable about how the core asset engine is meant to work.  In this branch the preliminary coding passes to discover and dynamically load both code and data from different projects is in, however there are bugs that need to be run down.  Its probably 10-12 hours of debugging away from being able to bring back to master.  I would love to get some more time in that branch to wrap up that work because it brings a lot of sanity to assets and proejct-specific coding paths that are all jumbled together in master.

Beyond bringing that branch back to master the project has a big change ahead of it to be usable for content creation: a big reconciliation needs to happen between the core Helium::Asset model and the EditorScene.  EditorScene is the data model that most of the UI chrome in the Editor is programmed against.  The functionality within EditorScene needs to be merged with the core asset Definition/Instancing system.  Its a tricky change to make without having to rewrite *all* of the editor code, but thankfully its mostly deleting code and shelving secondary features like Object Layers (visibility and selectibility).

Most of the progress we make as a project is made during weekend hackathons, and we haven't done one in a while.  It's long overdue.  I think we should shoot for another hackathon for October.  What do y'all think about a Halloween edition :)

Is LA very accessible to you Chris?  Is this you?: https://www.linkedin.com/profile/view?id=ADEAAApk1NgBoemy1Q7oEZjRygcdKHCJuTGimHo

--

Geoff Evans

[Philip Degarmo]

I'm in. Most weekends are open for me in October.

[Christopher Sosa]

Hehe thanks you. but (since i don't have linkedin, unfortunately i'm not that guy) i live in El Salvador, Central America so i can't go to your hackathon. And i want to start an serious project and the Helium project looked an great foundation for my engine (after several rewrites), and made a lot of changes (some of them you don't wanna like it) and hardly i made it to work the current changes to the Helium project i did was:

• Renamed Helium namespaces, macros,etc to my engine brandname (Sorry an pal told me was an good idea)
• Removed BSON/Mongo Reflect support.
• Removed the dlmalloc for Linux makes it to crash, specially when you use SDL2, this was hard to diagnose, Valgrind hopefully gave me a hint of dlmalloc.c was doing it to crash.
• Removed the old premake4 build system with CMake build system (pretty rough but does a good work)
• Removed OIS/GLFW/Win32 Windowing/Input system with SDL2 (The input system is not tested yet).
• Removed the incomplete rendering engine with OGRE3D 2.1 (very WIP)
• Removed Bullet components (still i have to choose rewrite the Bullet system or use Newton dynamics)
• Fixes compilation issues with Reflect JSON support with newer versions of RapidJSON.
• Qt5 Editor (i just started it)
• Improved the Nedmalloc allocator a bit.
• The GamePreprocessor is fine with some modifications.
• Added Scratchpad like EmptyGame example but is used to test things in the raw-est way possible.
• Removed some hardcoded code from Framework.
• Replaced the Math and MathSimd libraries with my little math library: KMathLib does the work well.

Recently i have very little time work on it currently because also i work as gamedev programmer at Beyond Games an recently formed mobile game studio (which uses F#/Xamarin i don't like absolutely) in the El Salvador studio. But i feel honoured being mentioned by industry veterans. If would live in the LA i will happy to assist it but unfortunately i can't, my development occurs in private repositories at GitLab and i'm the only one working on it, and i hope i don't make any controversy in the rebranding of the namespaces and strings of the name of the game engine since i thought you're no longer interested in develop it anymore but i have to ask here because its pretty complex. anyway thanks you!.

Telling me about the newest code happening in the game-refactor branch with a lot of changes made me scream "Goddamnit" in my mind, due the big organization changes i did to your engine. I'll happy to discuss this!.

Again, thanks you very much!.

[Christopher Sosa]

And looks i'm the only interested in this project, probably because people moved to Godot, Unity, UE4.... I like to make things from scratch...

[Geoff Evans]

I don't think I agree with your pal's advice, renaming all the namespace pretty much ends any possibility of doing code sharing or merges... so you are effectively forked.  It's is a shame, some of your changes seem interesting.  Good luck with your project.

Cheers,

-geoff

[Christopher Sosa]

I can make the changes go back (i've marked what i changed), sorry anyways!.

[Christopher Sosa]

I think i can cherry-pick and apply the changes directly!

El jueves, 1 de octubre de 2015, 21:25:15 (UTC-6), Christopher Sosa escribió: