Closed source encourages success, money makes things work Sent from my iPhone
> On Dec 19, 2013, at 7:49 PM, Bradley Arsenault <[email protected]> wrote: > > 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
_______________________________________________ glob2-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
