> A possible way to do it is to treat the core files as just another mod.
Nice idea, like it. It will be also a good sample by itself about how to create mods.
One more things to consider:
- usually game engine and mod are developed by different teams and have it's own independent source control systems.
- it should be easy to update game engine to the new version (like 'git checkout master').
So - maybe mods shouldn't be placed inside of game engine folder (it will cause problems with for example 'git checkout master' command).
One way to solve this - add paths to mods to config:
[mods]
/path_to_mod_a/mod_a
/path_to_mod_b/mod_b
As a result - the game engine will have it's own folder and version control and each of mods will have the same, and it's easy to udate any of it
(and if You wish it still can be placed inside of game engine folders).
About the performance - with lots of mods there will be lot's of file checks. But I doubt if it will impact performance,
actually, the Ruby (Ruby on Rails) dependency system works exactly the same way, there are 'mods' (called gems) and a set of ordered resource paths, and it seems there's no any
performance problem (usually there's about 10-30 gems per project).
And even if it will cause performance problems, it can be solved as follows:
- first time game loads it creates the 'resource_paths_cache.txt' (resource_name: /path_to_resource) file with all resolved paths.
- next time it just reads from it.
- if the list of mods is updated (game config is never than resource_paths_cache) - recreate it.
Maybe it's also worth to add following keys to help people discover this project:
- "rpg", "game engine" keywords in readme (to help people searching git for such things)
- add screenshot image displayed directly in the readme text (I use google image search query: "game site:github.com" that shows all game projects with images on github, and probably there are also other people using such technic)
Hmm, maybe, and because of this I called it "some analytics", I didn't wrote something like Glest better than Spring because it's codebase is about ten times smaller.
It's definitely not an ultimate criteria, but at least some criteria. In my opinion the size of codebase is somethink like an agility of project - less code means easier to start, less to learn, less time spend on supporting and updating it and less bugs.
I personally did it to define how high is entry point for me in these projects.
Nice game, but actually I found this via github.com search for games. Maybe it also make sense to add screenshots to Your github readme file, I sometime used google image search for "games site:github.com" and maybe someone else also will use similar search technic.
It seems that this topic is not only about Inheritance but also about general development, checked today some dev stats of some open source projects, maybe You also would be interesting (only .h, .cpp files where counted):
An interesting idea - there were AI competition in StarCraft 1, and the problem arise - every command choose it's own language to implement AI - how to build universal adapter or scripting language? So as far as I know they made integration via ports to communicate with external AI module that controlled the game world. Any scripting language (even JavaScript via Node.JS) can easily communicate via ports, so You can choose what You like. One problem - performance, but I belive there are just a small part of code that's critical to performance, and this parts barely needs to be moddable.
> A possible way to do it is to treat the core files as just another mod.
Nice idea, like it. It will be also a good sample by itself about how to create mods.
One more things to consider:
- usually game engine and mod are developed by different teams and have it's own independent source control systems.
- it should be easy to update game engine to the new version (like 'git checkout master').
So - maybe mods shouldn't be placed inside of game engine folder (it will cause problems with for example 'git checkout master' command).
One way to solve this - add paths to mods to config:
[mods]
/path_to_mod_a/mod_a
/path_to_mod_b/mod_b
As a result - the game engine will have it's own folder and version control and each of mods will have the same, and it's easy to udate any of it
(and if You wish it still can be placed inside of game engine folders).
About the performance - with lots of mods there will be lot's of file checks. But I doubt if it will impact performance,
actually, the Ruby (Ruby on Rails) dependency system works exactly the same way, there are 'mods' (called gems) and a set of ordered resource paths, and it seems there's no any
performance problem (usually there's about 10-30 gems per project).
And even if it will cause performance problems, it can be solved as follows:
- first time game loads it creates the 'resource_paths_cache.txt' (resource_name: /path_to_resource) file with all resolved paths.
- next time it just reads from it.
- if the list of mods is updated (game config is never than resource_paths_cache) - recreate it.
Maybe it's also worth to add following keys to help people discover this project:
- "rpg", "game engine" keywords in readme (to help people searching git for such things)
- add screenshot image displayed directly in the readme text (I use google image search query: "game site:github.com" that shows all game projects with images on github, and probably there are also other people using such technic)
Hmm, maybe, and because of this I called it "some analytics", I didn't wrote something like Glest better than Spring because it's codebase is about ten times smaller.
It's definitely not an ultimate criteria, but at least some criteria. In my opinion the size of codebase is somethink like an agility of project - less code means easier to start, less to learn, less time spend on supporting and updating it and less bugs.
I personally did it to define how high is entry point for me in these projects.
Impressive! I hadn't thought that I'll see native (well WebGL is almost native) 3D game in pure JavaScript any time soon.
I checkout repo, but it seems that 3D models are located in somewhere different, can't find it.
P.S. maybe it would be interesting for You as You works with a lots of JS, small presentation about CoffeeScript http://lanyrd.com/2011/rubyconfindia/sfkyy/
Nice game, but actually I found this via github.com search for games. Maybe it also make sense to add screenshots to Your github readme file, I sometime used google image search for "games site:github.com" and maybe someone else also will use similar search technic.
It seems that this topic is not only about Inheritance but also about general development, checked today some dev stats of some open source projects, maybe You also would be interesting (only .h, .cpp files where counted):
project: stratagus files: 5107 lines: 2878685 characters: 60588962
project: spring files: 1916 lines: 512323 characters: 12980590
project: btanks files: 503 lines: 86704 characters: 9530445
project: glest files: 311 lines: 49207 characters: 1092475
project: osare files: 88 lines: 15139 characters: 297715
About osare - In my point of view it's very good - to be able to do such a big work with a small amount of code.
An interesting idea - there were AI competition in StarCraft 1, and the problem arise - every command choose it's own language to implement AI - how to build universal adapter or scripting language? So as far as I know they made integration via ports to communicate with external AI module that controlled the game world. Any scripting language (even JavaScript via Node.JS) can easily communicate via ports, so You can choose what You like. One problem - performance, but I belive there are just a small part of code that's critical to performance, and this parts barely needs to be moddable.
Pages