OpenRTS split up into components to make it reusable for other games

Currently OpenRTS is collection of different things, working hardcoded together to show the potential of the OpenRTS Library. And my 2 cents are the potential is high. But not all games which created on top of OpenRTS want the use all the things contained in OpenRTS together.
Like @Pesegato described in http://hub.jmonkeyengine.org/t/how-about-splitting-the-model-dataset-from-the-openrts it will be fine if the Model-Dataset is splitted up in a separate package. I support this idea and I can identify another parts in OpenRTS. For example: the Map-Editor, the OpenRTs-EntityEditor (https://github.com/meltzow/OpenRTS-EntityEditor). And I am sure there is another cool component.
On the first view, it sound like to create more complexity because now OpenRTS are multiple components. But if you look into a component the complexity is smaller, because this component contains only stuff (and classes) for his own thing.
So my question is, what do you thing about it? And another, can you identify other components in OpenRTS?

2 Likes

I guess there are usefull components in any program and yes, in OpenRTS, we have some interesting piece of code :

  • Generic Grid for tile based map
  • Geometry library
  • Builder Library based on XML dataset
  • Steering behavior machine for motion of many non collidable entities
  • FlowFields for pathfinding with large groups of entities
  • ActorPool System to draw on View anything with few defintions

…and maybe others.

These pieces of code may be used in other projects and I would be very proud if they where ^^ They need to become more generic and OpenRTS has to be refactored to make a good use of it but nothing hard for most of them.

The way @Pesegato does it for the builder library is, I think, the best :

  • find a component you may use
  • create a generic framework with it
  • use it in your own project
  • adapt OpenRTS to it, as thanking

But I see some problems with that, because new born framework will be immature and will need to evolve with the new needs it adresses. Backward compatibility may become a challenge.

If the work is done : great ! If OpenRTS encounters compilation problems or bugs because of the dependecy’s evolution : bad :frowning:

Finally, I thinks it’s useless to extract components from OpenRTS before anyone expresses the need for it. Let’s focus on our ambitious goals :smiley:

1 Like

Well, that only means that the spin-off framework was badly designed. In this case, just roll back to the “old” solution.

However, if done right, it is a win-win situation because all dependent project will benefit from the improvements of the shared library. For example, I hope that my lib will remove some code bloat and make the OpenRTS more manageable. :stuck_out_tongue:

Also dudes: please use the “like” button to express your approval. It’s the hearth-shaped button on the bottom of each post.

1 Like

So I have the work-in-progress (and gradleized) GoldMonkey https://github.com/Pesegato/GoldMonkey

I’ve made the goldmonkey branch on openrts. Now I’d like the “goldmonkey” branch to import the goldmonkey lib; how should I do that @wuendsch ?

hi,
I am not sure which classes will contained in goldmonkey. goldmonkey must be a own subproject. We must see if goldmonkey depends on the core or vice visa. On the first view, I would say, the core depends nothing, and everything (in OpenRTS) depends on the core.
if needed we must blow up the example project which depends on both.

first we must isolate the classes. After that we can analyse the dependencies.

Well, maybe I didn’t explain properly how GoldMonkey is supposed to work.
GoldMonkeyAppState is an AppState; and as such does not depend on anything. When attached it reads the model/data assets and then intantiates the *Builders, which in turn create the objects.
There will be some built-in builders, like the ColorBuilder, but the game should provide its own builder. OpenRTS has its Builders, and my game has its Builders.

Therefore, “core” must attach GoldMonkeyAppState during initialization and must depend on it (of course in the goldmonkey branch), so the gradle build config must be modified accordingly. This is where I need your help.

Then, I can refactor “core” so that unneeded code is deleted/rewritten.