Some C++ Helium Framework questions.

[cristopher Ismael Sosa Abarca]

Hi,

I'm new in this Group.

I'm making my own game engine from scratch (education purposes and maybe serious) and i have time to see this game engine ongoing, but i didn't see recent activity about the game engine itself, but i see interesting C++ frameworks for games, and my question i can integrate any of these C++ frameworks into my engine?:

The following libraries to integrate is:

• Platform
• Foundation
• Inspect
• Reflect

Those libraries will save me a LOT OF TIME and FRUSTATION when i develop my authoring tools, and other question if here's any external dependency of these libraries? because i downloaded Platform & Foundation to satisfy the dependencies required by Inspect and Reflect.

Thanks.

[Nicholas "Indy" Ray]

cristopher,

All of those projects are licensed via the Helium Open License which may be viewed here: https://github.com/HeliumProject/Helium/blob/master/LICENSE.md

Which in sort mean that yes, you may use those libraries in your own engine, so long as you include the proper copy write in your projects source code, documentation and/or other materials.

Indy

--
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.

[Philip Degarmo]

Hello,

The libraries that make up helium are very good candidates for integrating with your own engine. The licensing is very permissive and commercial friendly, and parts of helium have already been used commercially in shipping products outside of games in at least two instances I know of.

• Foundation, Inspect, Math, MathSimd, Persist, Platform and Reflect are very easy to get up and running for your own projects, game or non-game related. Personally, I'd throw them in any C++ application I ever decided to do, game or otherwise.
  
• Engine and PcSupport add the concepts of assets and packages. This work would be a very good foundation for you to build a content pipeline on top of.
  
• Framework adds some structure to build components/gameplay on top of. The design is pretty experimental. We have a few working prototypes that demonstrate it.
• And then of course you could go all the way and start building on top of the editor and existing renderer/content pipeline.

How much to integrate depends on what you want to do. It sounds like you want to build technology, not necessarily a game, so I guess it depends on where you want to focus your time. If you want to work on plumbing, like your own window management, renderer, or content pipeline you might want to just take the first group. If you want to build gameplay systems or build middleware (like your own audio library) take the first two or three groups, depending on if you want to use the component-based design or roll your own. Or just take the whole thing :)

As to the activity of the project, there's 3+ of us working on it, but we all have full time jobs which ramp up and down in workload. We still meet physically 4+ times a year to work on it over a weekend. So this project is definitely not dead, and if you choose to use parts of it, you can absolutely ping us for help anytime.

As to future direction, we are keen to support a great development experience on devices (mobile or console.) i.e. wysiwyg editor on PC, pushing live data changes to a mobile device. The current projects are in pursuit of this goal:

• OpenGL support
  
• Refactoring the code/data layout on disk to accomodate end-users using the engine without compiling (like unity) while keeping it nice and simple for those that want full native code access
  
• Allowing games/devices to consume pipeline data over TCP/IP
  

Philip

[cristopher Ismael Sosa Abarca]

Thanks you for your replies. but the only disadvantage about your libraries is the lack of documentation. Anyways may be very useful for us.