@75, thank you for that, I will temper my temper in future, pun intended.
#76 (edited by Ethin 2019-02-07 09:14:45)
Fuck I'm so glad cookies aren't made of cheese.
Lets demonstrate this: stand still Thom...
Hmm, I actually posted my idea to help with this a bit in the developer room, integrating I mean.
https://forum.audiogames.net/topic/2753 … s-with-it/
Currently, one of my favorite games is Trimps.
So I'm the Trimper Trooper!
@Ethin you make me look like a saint in comparison with your behavior. You also need to learn that you can't approach every argument like it's a debate, and you shouldn't argue with fanatics. The only time you should argue with someone is if you see the possibility to change their mind. So one guy might be like I love BGT, it's the best programming language ever designed and it does everything I want and need. You could come up with every possible bit of evidence to disprove those statements and it would make no difference, then you're the one who's wasting time. You also need to realize that you can't win every argument. You have this like orgasmic love for debate but when you feel you're coming out on the bottom, your points become less and less logical, and more and more circular.
It's just not worth it to get all bothered about shit like that. The whole reason I got bothered about the WEbL thing which lead to my ban was not because it necessarily affected me, but affected a whole group of people, and the guy just would not stop. I acknowledge that I didn't handle that correctly, but thinking back, I usually can think of ways to so something differently, in this particular case, I can't. I literally know of no other way to get him to stop and that probably didn't do it either, so it was probably best left alone. But yeah it does bother me when someone perpetuates stereotypes about us, and that person being among us makes it even worse. its like shit, we have so many misconceptions and stereotypes floating around, some of which of the stereotypes are quite true for some people, but do we really need to be pushing that image. The stuff you get bothered about is trivial, and I'm sure some of mine is too.
Sorressean, I just oooo, sometimes I paint an image of him in my mind on the front of a punching bag and just go at it. I don't like the way he talks to people, especially about code, but he was right in this instance.
Also it's worth trying to evaluate where you stand on this forum, a lot of people probably hate you, but getting to know you off forum, you're actually a good guy, a bit misguided at times, but you've changed quite a bit from your 2013 days.
#81 (edited by JLove 2019-02-10 11:23:00)
So, I guess my question is, I understand why a big company wouldn't want to redo a game that they already completed to add accessibility features. However, I do not see the reason for not just incorporating accessibility from day 1? If you start from day 1 and the first line of code, then it shouldn't be a big deal.
As for the whole BGT/other language debate, yeah, BGT definitely has some limitations, and for a game that's ultra complex, I'd say it should be written in another language. But it does allow people who never thought they could code a game to do so, and it can be a gateway for them to enter the world of programming and learn other languages. Also, for a game that's not brimming with complexity, it does make aspects easier. For example, one thing I do like about BGT is the sound pool. It would be nice if it could handle 3d sound, yeah, but for some reason Philip decided not to allow that, unless that was beyond his control and is limited by Angelscript. That being said, the ease of manipulation of 2d is nice. To implement, modify, adjust, or otherwise manipulate sound in other languages can be a nightmare. Take C++, for example. Sound and DirectX in C++. Fucking forget it. A colossal headache and a ton of bullshit. Not sure how python handles it.
@81, DirectX isn't the only sound engine out there in C++ though. A lot of audio libraries exist (OpenAL, FMOD, Wwise, BASS, ...) simplify (or complexify) the problem and make your job easier or harder.
I actually want to chime in on the BGT thing in particular here.
So okay. We get that it's not the most complex language, and that it's got limitations. But apparently it's friendly for building stuff (I don't know firsthand, mind you). But it's been used to make some decent and solid games, and I would think that for certain styles of games, BGT would be perfectly serviceable. Why can we not accept it as a niche tool and just mov on? Why all the fire-spewing about how people have to give it up and join the mainstream? We are not mainstream. Integration with the mainstream is good, and I welcome the chance to do more of that, but this doesn't mean we can't have games that are designed for us specifically, and if doing so means we sometimes use tools that are easier to use because it's either that or we don't get any such games...I fail to see the issue here.
No one is forcing any particular dev to use BGT, so the way I see it, let those choosing to do so continue doing as they wish. Either their games will be hamstrung and will fail, or they'll succeed. If they succeed, awesome. If they don't, and if BGT is somehow behind the game's failure, then hopefully they'll learn or be encouraged to branch out. It also needs to be said that some people do not necessarily want full integration wit the mainstream, either due to simpls straight-up preference, personal bias, cognitive concerns or some level of all three. Please remember that at its core, gaming is a hobby. It is something to do for fun. Everyone has a threshold beyond which all the jumping through hoops is going to feel like busywork and will make the hobby stop feeling worthwhile. I used to be this way for JGT and Japanese audio games, and I'm so glad I softened my stance. And some people may not feel it's worth navigating Steam, or getting a PS4, or only knowing like 21% of a game; these people should absolutely not be shamed because they prefer games they fully understand and can relate to. When we get to a point where many games are accessible and playable both, then fine. But until then, I think there are several people in this thread - specifically not naming names here - who probably ought to get over the conceit that mainstream is just the default best way to go. Personally, if I have to fiddle with menus for ten minutes and use guides just to get a game running, and even then am only getting a tiny sliver of playability from it (or get to a point partway through and get utterly stonewalled, or need sighted help half the time), then that's not worth it. Give me something I want to play, and don't shame me for not putting in hours of work for a hobby. I have better things to do than wrangle with technology for something which is, as far as time expenditure, nothing better than a black hole.
https://www.dropbox.com/s/z8ls3rc3f4mkb … n.txt?dl=1
With consoles not being accessible at first, blind people playing games was still somehow a myth to major game companies. With the xbox having built-in accessibility, and it becoming increasingly easier for developers to obtain the sdk's, that has certainly started the ball rolling on integrating accessibility, especially for Indie devs. But many franchises are still going highly successful, and most (with the exception of EA) think, again, why satisfy a handful and not get a return on investment? Then again, EA's games are quite obviously franchises in and of themselves, but the accessible games have been written from the ground up to incorporate accessibility features. If you think it isn't much to just add it in, think of the fact that just a simple city name change for a Rockstar game required hundreds of code adjustments, and hours of extra work for the voiceovers on modifying cutscenes, just for one bloody name change. It is grueling. Especially given the fact people apparently want more cinematic games with 4k/8k/12k/400k whatever ultra-hd graphics, and scenes so detailed that if you miss them you've missed a crucial part in the game. It's like the game can't exist on its own without the mini-movie. Consumer expectations have gotten obscenely high. This is why Indie developers can focus on whatever the hell they want, because they aren't corporate entities who have to focus on the bottom line.
BGT is only really a gateway into learning about BGT. Sure you learn programming concepts you can take with you, but look at the percentage of people who leave BGT versus those who always make BGT and swear up and down by the thing until their game breaks a boundary that the engine has in a bad way. Now you're looking to eek every last bit of performance out of it because now your game is running poorly. Mainly laggy network games. Look you can't even use dictionaries, they're so freaking slow. Python dictionaries make BGT dictionaries look like decrpit old granny, but not a nice old granny who bakes you fresh cookies, a mean old granny who beats you with her cane.
I actually think there's some delayed shock with it. Let's say you realize you want to move on to bigger and better things, so you start looking into python. OK you never indented your code, that's weird now, and now you're forced to, so it's a frustration, you need to figure out how to deal with that, and despite having nvda indent reporting by tones option turned on, I still end up screwing up indents and have to fix them, it just makes it easier. OK, but you get that down, now tutorials are talking about stuff you can do on the console, and it's like OK, and you look at it and it's close enough. You see that you don't need to put a variable's data type before the variable, python has no problem with things like a = 5 b = 3.25 c = "cat". Before I draw this out too far, you realize that there are a lot of similarities, the syntax is different, but you hit a hard wall when you get into packages, dependencies, working with libraries, and how actually difficult it can be just to play a sound with some libs where you have to set up streams and stuff like that.
I feel that BGT gives you this warm cuddly feeling about how programming is, then when you think you're a BGT baller, you go out into the real world and it's like holy crap, this is...... feeeewwwww.
#86 (edited by JLove 2019-02-11 01:13:25)
Which is my exact point. Let's say someone has the desire to make a game as a hobby, just because. Sure, they've got the intellectual ability to learn a programming language. But for a game that's not complex, one that's not going to involve complex maps with all sorts of layered things, hundreds of items, enemies, and other stuff, I can see the appeal of using BGT for no other reason than not having to deal with all the fucking ridiculous bullshit just to play sound, let alone getting it to move and the like. The person wants to make a game as a hobby, they aren't doing it for profit. So rather than stressing themselves out banging their head against the wall while trying to get a few sounds to play correctly to the point that they lose the enjoyment of the project, they choose to use BGT, since the game isn't a complex one. I'm currently developing a game, and am doing so in BGT, and yes, I've considered porting the code to a different language, but for the amount of complexity involved, it's not worth the headache of sound management to me. I know of several solid games that were created with BGT, so this theory that absolutely nothing worth anything can be developed with it is false. Games with ultra complex sound schemes, world maps, enemy and item behaviors, etc., should be done in another language, I agree. But for a game that doesn't require that, I see no problem with someone creating it in BGT, and I won't assume that just because a game was made with BGT, it will be nothing more than a total failure or a piece of detritus.
I don't really understand how playing sound in 3D is "so complicated". FmOD, Wwise, and so on provide much easier methods than using the raw system APIs or OpenAL. Sound has gotten much easier. Graphics, on the other hand...
And it's not just the sound issue. There's also the issue of making sure that whatever editor/compiler/dev tools for the language you choose is accessible to you with your screen reader. For example, if I remember correctly, Unity is inaccessible to us completely, and I just saw a post on Python in the dev room talking about issues with accessibility there as well.
@88, ah, but there is always the command-line. The accessibility issue was JAWS-specific. WinPython, if I'm not mistaken, is accessible, or at least was last time I tested it. And notepad2/notepad++ are alternatives.
Yeah... Idle (the Python GUI) is completely inaccessible. I couldn't do anything more useful than peruse the menu bar, and view the window title.
Have a nice day!
Ride is a great concept, but the execution leaves a bit to be desired. It's a talking text editor that lets you navigate indent code accessibly by expanding and colapsoing indents (ctrl+alt+right to expand, left to collapse.) Problem is I think it was made in BGT, and while for fun games with it aren't much of a problem, trying to make a text editor in it is, well, a bit too ambitious for the engine to handle. Notpad Plus Plus is open source so someone could easily put indent nav in there too. Even with NVDA indent navigation beeps, part of the point of indents is to make the code easier to navigate because sighted people can zero in on a particular section, or scroll the major sections of code without looking at each line. Having expand/collapse for indents gives a blind person that same advantage, I just think the actual text editor would have more potential if it were either written in another language, or if it were a Notepad Plus Plus respin.
Hmm, the only thing that makes a text editor in BGT ambitious is that it doesn't come with a GUI library, so you have to write one yourself. Which, as it turns out, is the work of a weekend. Friday afternoon to get it working, Saturday to fix the bugs and features you missed, Sunday to do the same for whoever you corner on Skype/Teamtalk.
I find it interesting that people insist that sound is easy with these other libraries. It's so easy, in fact, that I still haven't gotten any of them to work.
Someone did write BGT wrappers for Bass and Fmodex, so I suppose just doing that with ctypes should work. Judging by the mile-long tracebacks pyfmodex generates, it's bound to be easier that way.
Looking at examples, Visual / VPython is astoundingly simple, as 3d graphics go. So, naturally, I can't get it to work, either. Probably something to do with screwing up the camra? It's not made for hyper realistic graphics, though. But no one codes that from scratch, since they can see to use Unity / Unreal / various other programs that turn it into a drag-and-drop affair, enabling colleges to offer game design courses that do not require any programming. ... I'ma headbutt the floor until the world starts making sense.
Funnily enough, the two courses I took regarding coding (which taught me GML and the basics of Java, respectively) hammered the importance of indentation. It just makes cleaner code in general, particularly on the visual side of things...so if I for some reason decided to learn a language, indenting would come naturally to me. I feel this is a skill that virtually anyone could try and work on, since I don't see many/any real downsides.
https://www.dropbox.com/s/z8ls3rc3f4mkb … n.txt?dl=1
There is the indent nav add-on for NVDA. It's apparently supposed to do those things.
Have a nice day!
It won't expand or collapse indents though I don't think.
I just found this topic and so figured I would post a reply to clear some things up.
There has in fact been some development happening on BGT on and off for the last few years, but I have not had the time or interest to package it all together and make a public release. This includes writing documentation, fixing some known bugs in the new features, etc. Basically, Aaron (the owner of VGStorm) and I have been collaborating for a number of years. I was involved in the development of both Psycho Strike and The Gate, which is why I added Elias support in the first place (see below).
Some people have also paid for features and have then been given special versions so that they can use that particular feature, which is nothing out of the ordinary. It is very common to have private patches intended for a particular company that are not released to the public. I am free to release these updates if and when I choose to do so, and I might at some point, but I am under no obligation whatsoever to do so - especially given that BGT is freeware.
Years ago I implemented a wrapper for Elias version 1, which is now way out of date as we're currently on Elias version 3.1. This is why those BGT games do not work on Windows XP, because Elias was being linked with a technique that locates the dll automatically when it is needed but which does not require the dll to be present if it is not used. This is a new technique which, if my guess is correct, does not work on Windows XP as I believe it was introduced in more recent versions of Visual Studio.
As for the future of the project, I don't honestly know. I don't really have a lot of interest in it anymore and have mainly been doing work on it in response to small freelance contracts for specific features, hence the special versions as I mentioned above. I could technically make a public release, but I'm not really that interested in spending the time required to do so at the moment. Especially because I am in agreement with most of you here that it is far better to use something mainstream if you want to push the boundaries of what can be done with audio games. BGT was good for what it was intended to do when I began writing it 11 years ago. Nowadays there are many more resources available and I would advise people to move away from it at the earliest opportunity. By all means use it if you know that you will only target Windows, but make sure you are aware of its strenghths and limitations before you decide.
HopefullyI have cleared up some of the confusion.
ok, so i get that its updates are infreequent, but dang this thing was updated in what, 2015 or even earlier? yeah, no. that aint infrequent. thats discontinued for yah mate.
I read the entire thread and there are some things I'd like to address. Being concise has never been my trademark so be warned.
First of all, remember that the game makers are not necessarily developers. One might have the required creativity and originality to make amazing games, but lack the know-how and skills to concretize it. The other way around, one might be a proficient developer in multiple languages, know how to optimize L1 and L2 cache, but have no inspiration nor game design knowledge. Now one could have both and thus be total rockstars. It's just like how an engineer will make a app that works wonderfully but no one will be able to use it because the user experience is terrible (it's an analogy of course, not an absolute and generalizable truth, you get the idea).
So what do we have? Some brilliant people with exciting ideas not being able to develop games, and developers developing ok games. It's asymetric, because one produces average quality content while the other one could produce quality content. Now this is a gaming community, an audio gaming community and we all want the same thing: good games. One of the ways to have better games is to simplify the game creation itself which is just the application of an idea. The real fun is in the idea, not really the implementation to certain extent. Now I don't know BGT, but it seems to me it was an effort made years ago towards this direction.
Ok, let's imagine some guy makes a game with BGT. The question is, should that person have used BGT ? It's hard to give one answer to this question as I wear multiple hats. So I'll answer for every hat:
As a player, I don't care. What I care is if the game is fun or not. If the game is fun, then I'd say yes, because perhaps the game wouldn't have existed without BGT. If the game is not fun, then I'd think it's either the game is not my style or the guy who made the game didn't have a great idea. However, it would be extremely unlikely that I would blame the language in which he wrote the game. The virus flaging is annoying.
As a developer, I'd say no. I would recommend C# as I love this language and it has accessible tool chain to develop, debug, compile, publish, profile, namely Visual Studio. I wouldn't recommend BGT because there is not a large community around it, because there hasn't been updates in a long time, because it has a limited feature set.
As a former Ubisoft engine developer, it would be impossible to write a game like Assassin's Creed in BGT. In fact, I'd argue it would be impossible to write such a game in Python. It's all written in C++, except for shaders, tools and some assembly optimizations. This is because you have to use all the available resources of a system and to do that you need to be able to control how it's compiled on a specific target. You also cannot afford interpretation costs of scripting languages. I also wanna quickly address something I read about crrappy code written. In the gaming industry, it's done all the time. They do hacks, patches, work arounds, as long as it works and it's efficient. When it's getting closer and closer to a release, this gets even worse. Why is that ? Because all the game code is throwable. You heard me right, they will throw away all the game code, because they cannot reuse any of it for another game. All they can reuse is the game engine. So it doesn't matter if the game specific code is crappy or patched, the only thing that matters is how long did it take to write including the cost of testing and maintaining that code in the release cycle. It's all about money and the quicker you produce code that is good enough, the best return on investment you get.
Finally, and this is the most important hat, as Origine, as a human, it's not of my frickin business. Who am I to tell someone that the game he wrote, must it be good or not whould or shouldn't have been written in BGT ? People do what they want and that's it. I say that because it's not only related to BGT. Whether it's NVDA versus JAWS, C# versus Python versus BGT versus C++, audio games versus mainstream games, Windows versus Linux versus MAC OS, if one uses something that satisfies all of its needs, then there's no point on trying to make that person change because this is better than that. I used to be like that when I was younger. I would try to convince iOS users that Android was the best and that they should switch. No matter the arguments, it doesn't matter if they like iOS the way it is. Trust me, when you start to realize this, everything starts to be cooler. I started to like Apple products, I don't own any of their products, but I have to admit they have solid designs, they are cool and feel somewhat premium. Apple are excellent at marketing (well, less recently, but they were truely amazing at that). You will start to see value in everything, ask yourself why they are using that and not something else ? Why is it so important that they change ?
If someone wants to make a battleship in Excel with VBA scripting, so be it. If someone wants to make a game played by sending e-mails to a game e-mail server, so be it. Hell, if someone wants to use Windows file system as a game engine to make a maze of folder and files with hints to find, passwords to crack encrypted files and find the secret way to a hidden Nicolas Cage picture, so frickin be it. Who would I be to tell that guy that Python would've been a much better solution to make a maze game, because the path length limit on Windows will prevent him to make a deep enough maze ?
Note: I'm not trying to promote Windows file system as a fully featured game engine.
People make libraries, tools, frameworks, wrappers because they have the know-how and would like to see what could come out of it if someone with enough creativity could have access to such functionnality without having the struggle of implementing it themselves.
Second of all, yes there's a second of all, don't you remember the first of all at the start of this comment? If you've read this far, I'm proud of you, but mostly flattered. Let's talk about audio games versus mainstream games. I've seen that mainstream games are a million times more fun and featureful than an audio game will ever be. I played AHC and I didn't have so much fun for so long. Of course mainstream games are rich of features and content, because they have a budget of tens if not hundreds of millions (think of World of Warcraft for instance). However, I don't see often what advantages audio games have over mainstream games. Instead of saying that audio games will never be able to be like mainstream games and that they should be in order to be cool games, let's talk about what audio games could be where mainstream games could never be as well as some advantages of audio games over mainstream games:
1) Audio games require much less memory. Visual assets are responsible of most of the game size of mainstream games. audio however has a much smaller memory footprint. This leaves a ton of memory available for audio games to take advantage of. This means that an audio game could theoretically have so much more content than a mainstream game it's hardly impossible to imagine. You might think that memory isn't the big deal of today's mainstream games. Well, not really. When big companies release on consoles physical games, they have to burn the game on a blu-ray. The blu-ray is limitted on the memory you can burn and I can assure you that when they reach that limit, they will do everything they can to squeeze and shrink the game memory size. This also applies to RAM. You cannot afford to page on a regular basis. You also have more GPU and CPU available, because you don't need to render 3D graphics, calculating collisions, culling, etc. You could use the graphics card resources for your AI in your game!
2) You could also choose to not use those resources available and have much smaller requirements for your games. This means that you could run your games on cheaper hardware, possibly a very cheap audio games console. Think of how Amazon echo dots are sold $40, it's basically a limited audio game console.
3) Mainstream audio games would require much smaller teams. That's right, you don't need visual assets, so you don't need character designs, 3D modeling artists, animators, all the visual game engine features, motion capture, and so on. This means that a project like that would cost a lot less than a mainstream video game. Of course you're gonna say that there's a smaller public and the game is gonna make less money anyway. Yes, but this also means that there can be better quality audio games of a one man's job than visual games.
You get the point. Yes mainstream games are cool, but always wanting the audio games to be like them is an unfair comparison for so many reasons, one being that they don't need to be like video games, they can be their own thing. Also, remember that fun is subjective and it's not because you don't have ultra HD graphics that you cannot enjoy an audio game trying to copy a mainstream game.
#99 (edited by defender 2019-02-18 00:51:11)
Great post, I love your unique insight and the way you broke down the various different outlooks made it easy to follow. I'm honored that we have you as a member of our forum, and keep track of that karma because I think you'll earn allot with posts like 98.
However I do have a few points to bring up.
And I too am a man of many words, so buckle in.
1. Players not getting mad at BGT, aside from the virus problem for less savvy computer users or those forced into using inaccessible AV software, it's very much true that no one really cares. However the exception lies in network heavy realtime games like FPS's and Side Scrolling PVP titles, because only Sam and Mason have managed to make the BGT network object actually work for them at this point and that took a long, painful time.
Even after that we still can't have proper automatic weapons or extra elements like dynamic shell drops, positional bullet zings/impacts ETC because with distance and firing rate, especially with a larger server load (more than like 6 people) things start to slow to a crawl from the players point of view.
It takes allot more effort to get BGT to behave in those situations, and many new coders don't have the experience to really get their hands dirty and figure it out, because it takes allot of hacking and hours upon hours of frustrating trial and error which cut into school and personal time, leading many of them to burn out.
Even with that, I believe Sam's network code is still pretty inefficient so he has to shell out for a much more powerful VPS than other games with the same amount of players, and he doesn't even have to deal with visual stutters. This makes a consistent stream of donations a necessity for him, which means catering to the players willing to pay, leading to imbalance.
As players I think we use BGT problems as a scapegoat to avoid laying the blame at the feet of inexperienced coders, and the developers are happy to follow along. But that said, every experienced coder I've seen try out BGT is horrified by networking with it and refuses to touch it.
2. The reasonable among us don't compare audio games directly to mainstream triple A titles outside of proving a point, but instead to mainstream Indi ones, so while your observations are still useful, your missing the mark a bit.
Our community is full of people with depression/anxiety and social problems, striving for a purpose. That's not a dig that's just the truth. The large majority of us are early teens to early 20s so you can add emotional immaturity into that mix, and now our problems with forming teams, code theft, piracy, project management over time, community entitlement, and developer PR start to make allot more sense.
I believe the small market issue is secondary to this, with the bigger issue being a deep sense of envy and discontent around our standing VS mainstream games, which tends to manifest in a demanding and hard to please audience who often say things without considering the impact on the developer's confedense (though to be fair we are also wary do to previous broken promises).
Also the fact that so many young developers create games to fill a void in their lives and hang their self worth on the success of their projects, leading to half baked new features taking priority over bug fixes and gameplay balancing, or a prickly and dismissive attitude towards the community at large.
As you can see, these two problems feed into and magnify each other, and the more community involvement and popularity a game has the worse it gets.
It's not all doom and gloom as some of these things are improving, we're moving towards an account based, limited license, phone home on launch system for combating piracy, and some people are also running contests or just straight up paying for those who can't afford popular new titles.
We're cracking down on clones, and we still have a consistent but slow stream of higher quality projects from established developers, and smaller, less popular games receiving highly positive/enthusiastic feedback.
3. Aside from the typical pissing contests that have been raging on the internet for years now, I think most of us actually have a problem with the user end limitations of developing for a specific OS.
I understand you might have only been using OS choice as an annolog for language choice, but it's a real problem when people develop for IOS and not Android for instance because we already have so few audio games to begin with, and allot of people can't afford a reasonably new IPhone without selling their soul to the devel via a contract, and even then only in more developed countries.
And now that the Somethinelse titles, Sixth Sense, and Storm8 games are gone, it's a problem when games are only developed for the Android, too.
As for coding language, well, blind people as a rule just don't have gaming rigs outside of a handful of us, not even five year old ones. So if a game requires a certain version of Direct X or some special audio driver that the average somewhat out of date mid to high end business laptop doesn't support or something because you had no choice but to use that library as the developer, your going to have allot of users that can't run your game.
But that's just my take on it, I'm not a developer and I've only been involved in a few projects my self, so I encourage you to keep up with some of the threads and make your own conclusions.
Lets demonstrate this: stand still Thom...
#100 (edited by JLove 2019-02-19 07:59:12)
Two very good posts, @98 and @99. I have often said that one of the biggest problems in terms of the inability to get an ulta-quality game in this community is that we, as a community, don't work together enough. Very rarely do you see people collaborate on a project. And that's sad to me. All of these people who moan and bitch about clones and all this other crap don't seem to realize that if they actually got together, shared in the work load, were willing to share knowledge, experience, code, sounds, tools, and whatever else, we could have some audiogames that could rival mainstream titles. It's much harder for a single person to develop a game of that magnitude than it is for a team of people to do so. It's much more difficult for a single person to write out 10 thousand lines of code than it is if you've got 10 people who can write 1000 lines apiece. It's why the mainstream devs can do what they do. They don't just have one person coding for them. They've got a whole team of coders who work together. I am a firm believer that people who work together have the ability to accomplish great things. But people in this community rarely, if ever, do it.
I don't give a damn what language a game is programmed in. All I care about is the quality and the content. People say it's impossible to make a good quality game with BGT. I don't believe that. There are definite drawbacks to BGT, yes, and definitely some things I wish that Philip had fixed and improved upon, networking being a huge one. Maybe he just thought that no one would ever make a multiplayer game, or that they wouldn't try to make one with more than 2 or 3 players, and so didn't feel the need to make the network object more robust, I don't know. I think that he included some things without thinking about making sure that all of the common associations available in other languages were there. An example of this is vectors. BGT has a vector object, but yet two very common operational calculations that seem to be just part of other language math libraries are missing, namely an opneg method and a normalization method. Pretty standard and common, and very common to see those calculations done with vectors. All of that being said, BGT has a distinct advantage in the ease with which it deals with sounds. No other language has the sound pool like BGT does. With every other language there's a shit load of dependencies or other crap you need, and a shitload of headache and finagling just to get sound to play correctly. I remember looking at the way it's done in C++ and thinking what a ridiculous nightmare it was. No thanks. That sort of headache just isn't worth it. I do wish that BGT could handle 3D sound, but again, maybe when Philip created it he didn't realize that sort of thing would be needed. In any event, I've seen several games that were made with BGT that are quite enjoyable. I'm not going to judge a game based on its coded language at the end of the day.
As far as IOS and android development, the biggest issue is most likely Apple's proprietary bullshit. Remember, Android is open source, and their requirements for apps to be put in their store are less stringent, I believe. Apple has a shit load of hoops that you have to jump through, not to mention cost. In a community where devs don't have lots of extra money, that is a problem. I like Apple's hardware. It's exemplary in terms of quality. But their proprietary shit gets on my nerves.