Its easy to tell that we are just a large bunch of programmers on this mailing list. We all just slamming away on what technologies to use.
I don't think the technical challenge is our main issue. I think its more that there just aren't enough of us with free time to devote to even doing the fundraising, let alone the actual coding. I like the idea of open source in theory, but it is very difficult for games, especially if we want any good online functionality, which have their own ongoing costs. To survive, the project would need to be able to fund itself. I like Leo's idea of making it open source but still available for sale through the android store or something, but I'd say if we like the idea of the game, closed source would probably be the most likely to succeed in the long term. On Tue, Dec 17, 2013 at 5:32 AM, Stéphane Magnenat <[email protected]>wrote: > On Tuesday 17 December 2013 08.01:11 Linus Probert wrote: > > I've got some experience with embedding Lua in C/C++, it's easy in C and > > works well with C++. Lua on the other hand is really nice working in, if > > possible one should work towards writing the core engine in C/C++ and > then > > implementing the logic of the game in Lua, that way ugly code in the game > > logic has less of an impact. The largest perk with this though, is that > the > > code for the game logic doesn't leak. > > While I have no experience in Lua beside reading a tutorial, I agree that > Lua > is superior to Python with respect to embedding, and certainly would be > great > for map scripting. However, I am afraid that for the core engine, Python > along > with mathematical packages such as numpy (and scipy if necessary) would be > better. Maybe we can have a Lua VM in Python for scripting maps ;-) > > > Cloning the original glob2 into such a code structure would be a good > start > > and we wouldn't have to wait for design decisions and discussions before > > coding since the original is the template. Once that is done one could > > focus on evolving the game only now the codebase is easier and less > costly > > to work with. > > I agree, I would love to see how smaller the unit state machine code could > be > with co-routines. Maybe I should try during the upcoming holidays ;-) > > have a nice day, > > Stéphane > > -- > http://stephane.magnenat.net > > _______________________________________________ > glob2-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/glob2-devel > -- ------ Bradley Arsenault
_______________________________________________ glob2-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
