PokeParadox said:dasfool said:Kagato said:It would be much more preferable to call an interpreted script engine (say Python/Pygame), and only require the minigames to provide code for their game routine. I think you're better off putting more work into the framework so that you end up with a better minigame library.
I'm with Kagato on this. I think we should have a framework pre-designed and then just have the minigame authors be responsible for little modules that are added onto the framework and call back to basic functions in the framework. Either have these compile with the main program or be an interpreted language like python or lua so that they can be edited on the fly when necessary (I'd prefer the later).
Look, I know that it's in many ways beneficial to support scripting languages, and yes maybe in the future it will be possible to add support for LUA and python into the engine. As it stands however, we have a launch deadline to aim for and no LUA/Python support in the engine... I personally don't have the time to research and implement this and still get this ready for launch... if you know someone that can add it in then by all means we are not stopping you. This is our engine, this is how it is right now, we can't magic support out of thin air, and no one else stepped forward with anything, so we can only do what we can do. Sorry if you feel this excludes you, but we are doing are best to help this community project along.
Maybe you could use and adapt an already existing game-engine that uses scripting languages, if you want that? Like for example löve.