Lotus Framework

[omgitsjeckle]

Well, as a few know, I just recently got back into programming; and was experimenting around with the Ogre rendering engine. While I have no complaints thus far on working with the Ogre rendering engine, I feel more at home with C# and Truevision3D, granted most of it was with the 6.3 release, it was almost a seamless cross over to 6.5.

One thing I noted though in my experiences with Truevision3D, is that while it contains almost everything needed to program a game, there is no ‘out of the box’ framework for state and entity component management. So as I project to get myself reunited with Truevision and C# I’ve started work on a framework dubbed currently as Lotus.

Currently the framework is in a fairly rough and early stage, though to the point where I feel comfortable enough to make an announcement and release a example application demonstrating how the state management works; an’ also in part to see if there is any interest in the project to warrant future announcements regarding it’s status and updates in the future.

The current features are very minimal, and include :

- Truevision3D engine creation.
- Support for a global application state.
- Per-game state management.
- The start of an input wrapper, no need to use the MTV3D65 namespace.
- More to come shortly.

My next steps are to add in a component based entity management system, and further flesh out the input wrapper class. But for now you can find the example application below, please provide any feedback or insight you may have on the project. I take to constructive criticism well, so please don’t try to beat around the bush in any comments you may have about the project. Source for the example application is included so you can see how things are created and managed, you just need to copy the current MTV3D65.dll to the /bin/Debug/ directory to be able to run the application.

Download : link [ 48kb ]

[vsleepy]

sounds interesting!

[omgitsjeckle]

Been busy the last week with work, so I haven't had time to progress as I had wished; but it's comforting to hear that you are interested in it's progression vsleepy

Anyways, I was able to wrap up the file packer frontend and the class to suit within the framework this weekend, along with a few big steps taken in the entity based component system and state manager updates. Here is a screenshot of the file packer frontend :



In it's current state, the packer will add the specified files / directory to the pack file and apply the desired password. The password is then encrypted using a custom encryption system, which is appended to a xml file along with some information about the packfile. Now the class within the framework only has to call Lotus.Utilities.LoadPackFiles(PathToXml, YourUniqueKey) for seamless use within the framework and your application. A simple text file is also created from the frontend with filenames and id numbers, for a quick reference to the ids associated with the files within the package.

I would be interested in finding out if anyone expresses any interest in the framework, or at least thoughts on how things are being accomplished thus far, be it negative or positive. Within the next week I will flesh out the component system some more and post a snippet of how they are used within your application, and with luck follow up with a demo shortly there after

[Raine]

I'm interested in this as well.. I'm going to check the component system out of curiosity. I don't know if you noticed, but I posted something about this some time ago.

[JohnB]

It's a good start but you still have a lot to do.

I'd suggest you look at other component systems before you get too much further into it.
There are some good links about component systems in RainC's post here:

http://www.truevision3d.com/forums/showcase/entity_system-t16928.0.html;msg115744#msg115744

Some of the important questions you need to consider include:

- How will the components be bundled & accessed? (entities/game objects/etc.)
- How will you handle spatial and logical groups of entities/game objects?
- Will you allow multiple components of the same type in the same entity/game object?
- How will you handle components that require/depend on other components?
- What events/actions/messages will you support? (update & render probably aren't enough)
- How will you initiate & distribute the events/actions/messages to the entities/game objects?
- Will you implement a scripting system or not? (lua/code injection/etc.)
- How will you handle the design time data? (prefabs/templates/etc.)
- How will you handle shared data? (materials/textures/models/animations/shaders/etc.)

I'm glad to see other people taking an interest in this type of system.
They may not be the best solution for every situation but they are a powerful alternative to traditional object heirarchies.

Like I said, it's a good start - I'm looking forward to seeing where you take it.

John B.
 

[omgitsjeckle]

JohnB,

Thank you for the link to RaineC's post, I had yet to find that, though I had read those links quite a few times in the recent past, it was interesting to see RaineC's ideas on implementing the idea

You are absolutely right on that fact that I still have a lot to do, in fact I've started over from step one, as how things were going with the previous layout of the code became to much of a hack to have everything working, and not well structured and thought out code as it should be.

Thank you for the list of thoughts to consider, you prevoked some much needed, serious thinking on my part. I will happily keep you all updated as I progress down this road, just keep in mind that my previous post on the timeline of releases is now completely off base

On a side note, about the scripting system that JohnB had mentioned, I have a version of the Squirrel Scripting Language ported over to a managed library. If there is an interest, I can wrap this into the framework at a later date, or at a bare minimum post a small demo and source of early tests when wrapping some of the Truevision methods into it. Let me know and I'll see what I can do

[Raine]

Sadly, that implementation was way too far from a realistic usage of the entity system. It is really much more complex and the points John listed perfectly shows this.

[omgitsjeckle]

Here is a brief class diagram of the current rewrite in progress of the Lotus Framework. It is to simply show my current progress, and possibly to get some insight on the current layout of things; I don't claim to be a professional with the know-how on how to do everything correctly, so if something stands out to you in the diagram that doesn't look right, please let me know


[ click for full view ]

This doesn't include any of the component based management at this time, I plan to start that within the next few days after some further testing and reading. But as I progress, I will keep updating this post with my current method of handling methods, and to ask for insight

[Zaknafein]

Just a quick note, usually .NET properties (even if they're read-only or write-only) should not be prefixed with get/set, just name them for what they represent. For example, GetInitialized should be just Initialized.

[omgitsjeckle]

Old habits from my C++ days die hard :-P Just wondering though, is there any reason as to this aside from it a good C# coding practice? It's a trivial matter, and will take no time at all to change. Probably would also be beneficial to me, as well, to get into the grove of following the language standard; Thanks for brining this up Zak, never would have thought of this otherwise.

[Soganatsu]

hey omgitsjeckle!

The class diagram looks very nice I'm doing something similar for our dev environment right now and I'm wondering what this whole GameState Thing is about. From XNA I know that you can switch with it from menus to ingame, etc. so ig. tell what's rendered. But fro your diagram I can't really tell what your's is supposed to do

Cya,
Philipp

[Raine]

Properties are translated into methods, whose names are prefixes with get_ / set_. It would turn out to be get_GetInitialized, even if you don't happen to see that method it feels redundant anyway. Other than this, GetInitialized() sounds like a method.

Initialized, or IsInitialized is a better property name, like Zak already pointed out. Search for naming guidelines. The one Microsoft's using is pretty cool and readable.

[omgitsjeckle]

Property and class object names have been changed to follow the Microsoft naming guidelines, thanks again for pointing this out Zak and RaineC

Soganatsu,
The game state interface is similar to what XNA has called screens. Which allows for the switching between, and management of, menus, play interfaces and similar tasks. The state interface will be expanded a little for a basic management of any objects that require states, for example A.I., but I will be leaving that class fairly open ended as state management can be very game specific.

I'll be posting a demo, with the source, that shows how interfaces, methods and the like are implemented at a later date after I get in more functionality of the framework, and the component system. So that should also help to explain things a bit further for you Soganatsu