Re: LLVM discussion
That this sounds like BGT, and I don't see why you wouldn't just use that.
In terms of 3D audio, I'm pretty sure I'm the only person on the block for anything under $10k, and it's not ready. It's close enough to ready that you can get it running, but it's not ready.
As for actually doing this, there's not much point unless it's more than a scripting language with easy libraries. In that case, just develop the easy libraries and don't even worry about the rest: whether I have to do "import magic_audiogame_engine", "using magic_audiogame_engine", etc, isn't a big deal. And it avoids a ton of stuff.
My current methodology is what I call library-driven development. I develop libraries as I develop projects. The intent is that they're separable: audiogame_engine is the core part of any game (use pyglet, it's deprecated because I didn't know pyglet exist
ed) but really it's also half the code to a space invaders. Once you've got 10 or so of these handling everything you need, you've done it. Just release them all separately, or as an installer that installs them all, or whatever.
Python is a bit hard to distribute, but if you're going to develop the distribution component for people that doesn't matter so much. Ironically, C++ is probably the easiest: statically link the runtime and all the libraries in, and you're done. You don't even need an installer. In the middle is something like LuaJit, Angelscript, etc: you don't have some of the distribution complexities of Python, but you do have to develop the entire host environment (so not really a fair trade-off). I'm not saying that C++ is really on the table: C++ is a horrible thing for new and old coders alike.
In python, adding the following things to your mixing pot gives a full game engine.
No coding is required, save perhaps for distributing. Pyglet (graphics, sound), pickle (built-in and can serialize anything), SQLAlchemy (talk to databases), requests (talk to web servers, i.e. scoreboards or update checking), any of several astar implementations (pathfinding), either PyBox2D or PyODE (the former is better. Solves the collision checking problem), and maybe blist (faster containers in a profound way i can't go into via a parenthetical note). What might be left is writing easier wrapers on top of these, but I can't think of a game that needs something that list of Python packages doesn't offer. Other languages have similar and equally effective combinations-the fact that I can't tell you what c# needs means simply that you need to Google, for example.
If we want to talk about the Unity road, we get to talk about inventing interfaces that don't even exist yet. I don't think you're talking about that
, but feel free to correct me.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
