So after a while of feeling like I was out of my league when learning C# I've decided to try Python. So what are the difference between the main audiogame engines in Python?
You probably want Earwax. Based off the discussions I've seen around here it's the least buggy.
I wouldn't call any of them engines. They just "simplify" things that probably shouldn't be "simplified". Maybe they're helpful to newbies, I'm not sure, but all I do know is that Lucia's sound pool was so broken at one point that using it was slower than not using it, and as far as I know that never got fixed.
Yeah, Lucia is broken, and pyAGE seems to be dead. Earwax would be your best bet. Someone needs to sit down and write a true audio game engine. One that doesn't just wrap BGT functions in Python or whatever language. I would do it but I'm not currently smart enough plus high school and job program.
Bleh, no, that's the problem. You don't get "an audiogame engine". You get an FPS engine that's for Swamp-style games that has certain assumptions in it and as soon as someone wants to do something even remotely different they have to write their own from scratch. Even Unity is this way, they just have nice devtools and a lot of prebuilt things to wire together, plus a community of people for the last 10 years building more and more things that play nice with the ecosystem.
It frustrates me a lot to watch everyone here think they can simplify interfaces of other libs. if you could simplify the interface of the other lib and actually meet the needs of everyone, the other lib would have started with the simpler interface in the first place. It's not like all the things Earwax, Lucia, etc etc etc. are trying to simplify went "you know, let's make this tons more complicated than it needs to be". There are useful things you can throw in a library, sure. Keyboard configuration utility functions are useful. But this idea that we can just go out and write an engine and then there will be this beautiful thing that makes audiogames simple? That's wrong. The things you look at that are complicated are typically complicated for a reason, and any time anyone here says "I want to write an audiogame engine" and doesn't follow it up with "for my puzzle games" I just scream inside because that's genuinely not how this works. Start by explaining why you didn't grab one of the sighted things first--Monogame, Bevy, whatever else you care to name.
I really think this misunderstanding is probably a good part of why these projects die off. Not because they aren't useful but because even the authors writing them eventually have to come to this realization that they're not going to be able to build a cohesive whole. Or to the other realization that when they tried to meet the needs of all 10 different game genres or whatever, they ended up with an interface that's not simple, code that's hard to maintain, etc. The reason that web services and the like have things like Django is that those are domains in which 90% of your users are doing the same thing. For games, if 90% of the devs are doing the same thing, we don't get new and unique games, we get clones of the old thing over and over. In web land, to continue using it as an example, the money comes from the fact you decided to write a site that hosts cat pitures, but all the things involved in hosting cat pictures are the same as hosting dog pictures. In game land, a cgame about cats and a game about dogs will start by implementing cats and dogs with entirely custom AI logic. And the rest of the concerns beyond the most basic level like playing a sound or knowing a key is pressed or saving data to disk? They're all like that.
My actual answer to this question is that I have yet to see an audiogame lib that I would use myself, but maybe what we have at least lets people who are learning feel lest lost, I dunno. I'm really glad that the community finally collaborates, but the next step is going to be devs learning that the best way to produce useful code for others is to pick a very specific problem and produce a thing that solves only that problem and nothing else but that problem.
PyAGE isn't dead, i'm just busy with much more important things right now. Development will continue eventually.
Sadly, that's the realisation I think I'm slowly coming to. I don't have the maths knowledge to make FPS-style things, and not enough experience in puzzle games ETC.
I mean, yes. But I couldn't do this either. A fully general game engine that solves everything is a pipe dream. Your level representation is probably wrong for 10% of people. Your event handling is probably wrong for 10% of people. Your saving code is probably wrong for 10% of people. And so on. I don't just mean Earwax, I mean all of them. And yeah, those 10%s are going to overlap, but once you've gone far enough down the list no one is using your framework, they're all tearing it apart to use little bits and pieces. So you either make it enterprise as fuck (have you seen my EventRouterFactoryBuilder?), so configurable it's harder to understand than if you just didn't use it, or something super specific to the kind of game you want.
My advice here is: don't try to produce a cohesive whole. If you want to publish a package that has a bunch of game helper modules that's cool, but you have to approach it like that and avoid making thing a depend on thing b and c so that you can't just use thing a by itself.
Unity, Love, Godot, etc. do prove that you can do generalized things, but the sort of generalized thing they actually do is "we can render complex graphics efficiently" and "we can do physics efficiently". As soon as you look into e.g. networking they're all "here is a thing that sends packets. Have fun". In general networking is where this kind of conversation breaks down the fastest, so that's not surprising, but it's a good example.
Consider also Factorio and other RTS games, where the entire engine must be 100% deterministic and replayable which, among other things, means that floats are banned from your engine in favor of fixed point math. SoundRTS doesn't scale big enough to need it--this isn't a problem audiogames people have had to solve. But your nice general level thing, is it deterministic? And of course you're going to say "that's a great idea, let's do that" but deterministic also means slower, possibly slow enough that you couldn't do a Swamp with it, and probably custom physics algorithms (though, in this case, it's surprising that "the deterministic physics library" doesn't seem to be a thing--probably because fixed point matrix multiplications are hard to implement efficiently on X86, but who knows).
My advice is write a game but do so by thinking about it as "libraries", then publish the libraries; this is roughly the plan for my MMO engine thing, and I'm already doing it with Synthizer. As a programmer you should solve the problem in front of you, not the problem you think is maybe in front of someone else.
I really like the idea from #7 of fixing the problem you are actually facing instead of solving problems you think you will have or problems other programmers will have, since the former approach always produces useful code, whereas the latter might end up producing things that aren't actually useful. so, the latter doesn't allocate the scarce resource of time as efficiently.
I've been thinking for some time, what I would do (and might end up doing at some point) is to develop a playable game and then review which parts seem reusable for developing other similiar-ish games and then modularize those and package them off as seperate game dev utils.
say what you like about sable, but one thing the dev is doing that I think is smart, is having a dev team actively working on a game using the tool, so the sable dev gets feedback on what things work and what needs to be added.
OK, that's good advice. I'm also finding I'm at a bit of a crossroads in terms of technologies right now, and I'm not sure which route to take yet. Also, it's summer, and as Claire rightly points out, I only really code in the winter, because I'm too busy flitting from thing to thing in the summer.
Agreed. I found with Earwax I wrote the game board for Lucky 13, then had no idea why I'd made those design decisions when anyone else came to use it.
Also, I do like the idea of codeless, or at least minimal code setups. The Earwax story builder, although hardly feature-rich, was fun in terms of what you could make with it. Maybe I should focus on allowing people to make MOO-style rooms, and attaching code to events with Lua or something, just as a simple game creation toolkit type thing.
@9 I have to say that I've really enjoyed reading your posts about developing earwax and related tools. Documents a real case study of developing a audiogame dev toolkit and a good resource to learn from, even though I would make some different design choices personally. Thanks for making that whole process public, so people can benefit from it
I want to be clear I'm not saying don't do Earwax. Just that, overall, I think there's a misalignment between what the community here is explicitly aiming for and what's both possible and the correct path. The community is explicitly aiming for Unity, but a version of Unity that's what people who have no idea what Unity does think it is. The community is explicitly aiming for "Pyglet, but simpler, and works for everyone". The community is explicitly aiming for "this library makes my single-player game an online game just by adding these few lines". yes, I know not literally. But this is nonetheless the sentiment. And then everyone is disappointed when it can't happen.
It's present even in this thread. There's a lot of reasons I tell people not to use C#, but C# is actually possibly the most popular game programming language on the planet, and the game library ecosystem for it is really really good. No one here including myself is going to outdo it. It doesn't simplify. To use another terrible analogy, it's like cutting a statue out of a block of marble, where the statue is your game and the marble is your tooling. You can't go to marble-are-us and get some sort of "simplified" block of marble that will work for every statue. Maybe you can get 75% of a dog that just needs the ears added, or something. But if someone already cut it down before you, you're very limited and you can't put back all the bits you gave up without just getting another block of marble.
The only way to do this stuff is to make yourself a better programmer, until one day you look at what's available and go "ah hah, now I understand why it's that way". Which is why when people come on here and are like "I want to learn programming by doing games", I suggest that they learn to program with almost anything else first. You could give a newbie game dev a rewarding experience with something like Sable, if Sable was going to have actual scripting rather than just "rename the fireball spell to laser" But that traps you within the engine and you can't do anything the engine doesn't already support without modifying the source of the engine in some way, which puts us right back here. The only way to do something like it that works for everyone is to basically be like "literally every function this engine offers can be replaced with yours" which is a really tall order.
My pleasure. I'm not sure about some of my design choices either, but it has definitely been a fun ride.
Programming sure can be depressing!
I actually think Sable is going the right way about it. I get the not being able to script thing, but the kind of people who are going to use Sable probably aren't going to want to script anyways.
I've been thinking a lot about scripting. I've yet to find a solution I really like for it.
@Chris and DragonLee, thanks for the comments regarding Sable/ its development. I appreciate from posts I’ve seen outside the Sable topic over the past year that Sable, or its concept isn’t popular amongst other programmers, but I do think it’s important to remember, that it was never designed as a tool for programmers. . As Chris points out , our target market has always been people who can’t code, which is why Sable was written the way it was. To keep on topic and Following on from Camlorn’s point he makes about picking a specific problem and addressing only that problem, that ties in with our logic behind Sable, to be clear though our goal isn’t to solve the RPG problem, since that’s far too broad a gap to fill with a tool like Sable, instead our goal is to solve the problem that people with no coding knowledge currently have no tools to turn their own creative ideas and stories into a game, specifically an RPG. Further following on from this point of focusing on a very specific problem or issue, we never intended Sable to be the be all and end all of RPG creation, which is why we focused Sable on being able to make only a very specific subgenre of RPG’s, which is Windows based, offline, single player, turned based RPGS (try fitting that in a subject line of a topic though hahaha), I don’t think you can get much more specific than that, as it really is focused in on only a very, very small specific subset of RPG’s. From the very outset we’ve always said that using a tool like Sable will be restrictive, but that hopefully it gives people who can’t code a chance to turn their hand at game design. even though there’s no coding for the end user, a lot of work still needs to go into making a good, well balanced, interesting and immersive game. Sure we picked RPG’s because the whole team has a passion for that genre, but also since RPG’s are as a general rule probably the most story driven of the various game genres , this gives creators a chance to add uniqueness to their games through their own stories and how they want to tell that story, since that is such a big part of an RPG. I do also completely appreciate that RPG’s need good mechanics too, we’ve tried to make this side of the prototype build as robust as possible, but both me and the rest of the team recognise that we could have built this in a way to make it a lot more flexible and give creators much more freedom with customisation and creation. @DragonLee, definitely having a development team working on the game side of everything has definitely been helpful too, firstly as I’m not so creative when it comes to game design, it means I can leave that all to them whilst I focus on coding. Secondly though, having a team working on games means we always have a small revenue source filtering in from games we produce , which helps fund development of Sable. Even if Sable turns out to not be popular, I know it won’t have been a total loss since we can still ourselves continue to produce games. obviously being part of a team is also helpful, just through motivation, having people to test stuff and bounce ideas of one another is always handy too, plus it’s great to be able to get instant feedback on anything new I code in, be it praise for a great addition, or condemnation for a terrible, terrible idea hahaha
Not sure why you can't satisfy yourself with scripting. You'll have to code a lot to bind all the functions, but "I've now exposed the function to move an object" and "this function in this file gets called on this kind of game event" should both be very easy problems?
Maybe go copy whatever Roblox does, since Roblox is basically online RPG maker with Lua.
Ultimately with Sable, I was around for Audiogame maker in like 2006. Audiogame Maker was almost exactly the same thing you're trying to do. It never got entirely finished, but it was finished enough that people did make games with it. Sable is going to be popular for maybe 4 to 6 months once released, then everyone is going to realize that being able to tell a different story isn't enough. Once the market is flooded with games that all have the same mechanics but different stories, the players are going to stop being interested. I don't understand how people get the idea that a good story is enough for a game. You have to offer the players something different mechanically. It doesn't work otherwise.
But the point is, what you're trying for was done. Maybe you'll prove us wrong, but the last one faded into obscurity within a year.
I didn't know that C# was the most popular gaming language on the planet -- or close to it. That's bad-ass to hear. I guess I'll need to refresh my C# knowledge Anyway, typically what I do is for each game or tool-that-acts-like-a-game is that I write my own engine for the game and if I can, I reuse things from other things I've written or from other libs I find. Maybe its inefficient to do that, but its proven that it does work, even if it slows me down a little. It ensures that I actually know how my game works.
yeah, it's either the most popular or very close. Unity is written in it, and it's what you use to write stuff for unity, so when Unity ate the game market it came along for the ride. I suppose maybe JS can be argued to be more popular, and there's a lot of C++ stuff around, but if it's UNity and big it's C#.
For when you don't want to run inside a .net runtime, they've got this CIL to C++ cross-compiler thing, which I'm pretty sure is how they get things like iOS. Not 100% on that though--my knowledge of all of that only goes a little way for the obvious "I'm blind and" reasons (I know about il2cpp because work has had to deal with it as part of our Unity support).
It's the toss-up between coding my own editor (bound to fail), or allowing people to use an external editor, and them seeing obscure filenames.
I'm sure the problems seem way bigger in my head than they are in real life; honestly I've never given it a concerted effort, since my main language tends towards Python, and I'd either have to give people the ability to code arbitrary Python, or give them a substandard language like Lua to hack about with.
My current wet dream is to code stuff using Dart, then allow scripting in Python. That means embedding the Python DLL, and I'm still figuring out Synthizer's comparatively small list of functions.
You don't want to embed Python. That's a very special sort of hell where you reimplement all of py2exe or whatever else, assuming that you want it distributed on client machines. If it's just going to run on a server that's probably fine though. be careful of the threading concerns, if threads matter to you, and be aware that it's not possible to sandbox it for all the same reasons you can't sandbox normal Python.
Lua is actually a very featurefull language, with exactly two things I don't like about it: undefined variables return nil instead of an error, and arrays are 1-based. It's got everything else up to and including the Python-style operator overloading. The only downside is that the standard library is tiny, but there's enough modules out there that you can just plug a bunch of things in no problem if you need them, and Luajit is about as fast as C.
I don't understand why you need cryptic file names, if you can just tell the engine what file the script is in. If you can't and you really need that, you can just open the user's normal editor to the file. Or, instead, offer an interface where you do like:
attach_evt_handler(object, "on_collide", collision_function)
My weird tentative plan for my MMO thing is to do level building in Python, having it spit out a bunch of json, and then having users do scripts with multiline strings.
I wouldn't worry about cryptic file names. You're never going to get a nice level editor. Nice level editors are the kind of thing where you need an entire person on it full time. You want the minimum that works. There's a reason that a lot of games around here use weird text-based command languages. In the case of scripting you're going to find that it's much more important of a question "what can be scripted", not "how do I install the scripts". Scripting in general, game or otherwise, will eat the entire codebase if you let it.
But in general "nice level editor" isn't the problem in front of you to circle back to my main point. The problem in front of you is "a level exists and I can play it". Don't plan your game around what you want the Ui for builders to be. Players are who matter first. In business speak we call this being customer focused, and it's kind of annoying in your job interview when you have to come up with stories in which you put the customer first, but I've found that for small personal projects it's the only way, even if you consider yourself the customer. Obviously your backend tooling and things need to be good enough to let you make gameplay and levels happen, but you can always build a nicer UI later. So why handle it now? A nice UI but no working game is just a fancy way to fail, kind of. I mean yeah you could push it through, but you'll probably find out that because you did it that way around you can't support a bunch of capabilities you didn't know you wanted when you started and things like that. it backs you into a corner but, in programming, backed into a corner is kind of synonymous with throw it out and start over.
OK, thank you for all that. I didn't realise Lua was so powerful (not to mention fast). I just saw the nil thing and thought "Ugh, another language to learn that doesn't give me much". Seems I was wrong.
#20 (edited by lemm 2021-04-06 00:56:25)
@Camlorn, I agree with you completely that storyline is only one element of any game, the only reason I mentioned storyline and why we picked RPG’s was that generally RPG’s are as a genre more story driven than most other games. most other game genres can get away without a great storyline and still be a good game, where as an RPG with a lack of, or just poor storyline will often quickly become a bad RPG, or at least not a memorable one. All that being said, I agree though that even RPG’s need good mechanics to go alongside a storyline, although Sable could definitely be written to offer much more flexibility, I think it has a strong enough set of mechanics for a prototype for users to play around with (since the current build is just a kind of proof of concept), especially with all the additions which have gone in over the past year following the public alpha release last May. I never actually got to play around with audio game maker, since I only lost my sight in late 2004 and probably only discovered audio games around the end of 2006. Due to this I can’t personally comment on anything regarding Audio game maker, but one of the Sable testers says they used it, like you said in your previous post they also said it was never finished, they did say it was really buggy, but also that Sable offered much more complexity than audio game maker ever did. Anyway, I’m pretty sure I’ll never convert you to being a fan of Sable (more chance of hell freezing over I reckon hahaha!), but none the less I respect your opinions on the matter as you are vastly more experienced at programming than I’ll ever be, so I do take onboard your comments as I really am just a novice starting out at programming. On a separate note, really excited to hear you are thinking about your own MMO RPG, as mentioned previously I’m a huge RPG fan and would love to see a really epic MMO RPG in the audio game community.
Be careful of always telling people how Sable is a prototype: You've been working on it for years, and I am personally not convinced you'll ever get around to writing the "proper" version, since that would necessarily require you doing all the work you've already done in another, as yet unfamiliar language. Plus the extra hassle of converting people's game files from whatever BGT stores things in to something more generic.
I don't doubt you think of it as a prototype, but fact remains you're still fixing bugs in said prototype, and from your posts, it doesn't look like any of the proper version has been written, or that you've even gathered the tools required.
I hope I'm wrong by the way, because I really respect what you're doing.
@Chris, that’s a fair point. The prototype has definitely taken longer than I expected, part of that is that this is my first full coding project so I’ve been learning as ai go, but also for the early years of the project I was working full time in my Sales day job, but also along with another director running my recruitment company at the same time too, so time has always been sparse. Although I was made redundant from my day job the year before last, its freed up some time for coding but I’ve had a lot of other family stuff going on which has taken time away from coding. I think one of the reasons I keep mentioning it being a prototype is that firstly its written in BGT, which just isn’t sustainable, but also being my first project, although the code works its not well written and I’ve made lots of bad design decisions. I think how actively I can keep adding new features to a tool like Sable will play a part in how successful Sable is, but I think continually adding new features to a prototype, is somewhat redundant which is why I’m keen to highlight this is a prototype so I can freely move onto building a new version and people understand why I’m not constantly adding new features to the prototype. I’m currently doing my final pass through of testing and adding final polish where needed, then I think I’m going to be taking a break from the current prototype build of Sable whilst the game design team work on Crimson Eclipse and I can focus more time into other languages. Regarding the new build, one think that will hopefully speed development is one of the game design team has been studying c# at college for the past couple of years, so the intention is that he’ll also come over to the coding side of things to help code, this should speed development, but is also handy having someone with a level of coding education behind them, rather than myself where its all just been self-taught and where I’ve probably picked up an absolute ton of bad habits!