@26 why shouldn't i repeat the repeat button if all the people do is repeating the same repetetive points that have been made so often, so use the repeat button as an argument? That was the best sentence lol. And also no, that is not at all what i am doing, it's more what the people do when they run out of arguments or want to force a discussion to go further in the hope that someone else will give the points. Then this happens but i don't need that, i know when i have lost.
So argumentiert man nicht, schau dir mal das win7 thema von mier an, da geben die sogar zu meine posts nicht zuende zu lesen.

@27 Nobody said they haven't read your whole post in your Windows 7 topic. The only post that comes close is Nizzas. It says it's not worth reading your post to the end because there is to much misinformation, but the post briefly addressed all of your points, so Nizza must have read it anyway. But I'm sorry for going off-topic. Let's return to the BGT topic.

English child, english!

Guys, just let him do whatever he wants with this. He knows the consequences, lord knows they have been raised at least thirty times by now. It is his choice to continue using something when when clearly being shown the negative side to his persistence.

I'm not even going to bother continue arguing. Simter I suggest you should too.

Another invalid arguement.
Either way, am I the only one who thinks that python code actualy looks easier than bgt code?
Sure, there's indentation but I find indentation easy.

Python code looks more English than BGT for me.

@40, what's with the assumptions? Only 3 devs use PB and then you go about generalising like that? And I know 2 folks who use PB that pays for all their games, so you really should stop making baseless claims like that. That demographic who is more likely to crack and dadadadada are the folks who still use BGT.

Yeah, I shouldn't have generalised there, but you're more likely to see a BGT cracker than a PB one.

Hy guys!
@camlorn, I'm sorry for other bgt users, but I totally agree with you here. Indeed bgt is dead and so it shall be, everyone who is using it is hitting a dead horse for too long now. The warrying thing is that this fenomenon is not going to stop untill, perhaps, windows will break something critical enough that every bgt game out there will crash at startup, otherwise, I don't see a very optimistic result ahead of us on this line.
Sometime ago, I really stood and annalised the thing, the entire problem, as best as I could and know it so far. Now, after turning the coin both sides for almost half a day, I think I understand what's going on.
So, basically, bgt is, even now with today's technologies and frameworks, like the concept of the dark side of the force in star wars. In other words, bgt is guaranteed to offer you shortcuts to power, it's seducing like hell so that it worpped the minds of some that could have been wanderfull programmers otherwise, and is generally more quick and easy and besides, like the dark side feeds on the natural imotions of anger and hate from the user, so does bgt have some great games written in it and uses this fakt to its advantage, recruting more newbies.
However, like the dark side, as much as it offers power, strength, imortality, whatever, so does everything its offering come at a terible price, limitation. Basically, when you reach those limitations, you're out of luck. When using bgt a long time ago, I hit those limitations pretty hard, so I bounced backwards all the way off the bridge, hitting python for a short while, then pb, for an even shorter time than with python(literarely afew days at best) and, finally, to c#, where I am to this day.
Now, let's inspect the other side of the coin, we must do that as well, right?
Bgt is dead, I get that. Bgt is a pile of trash, I get that as well. Bgt is limeted, I get and agree with that, too. Bgt encourages some...questionable,  if not down right horible, programming stiles considering the design patterns and other tricks practiced today, I really experienced that, it hits later in more serious development, believe me. But, I really have to ask this question, for the sake of asking, what choices do we have currently? Let's see...
for one, we have pb.
Pure basic, or as I and others like to call it, pb, is designed with games in mind, as they say, one of its strong points. I believe that, for this thing alone, even if it's not really true in the first place, some people around here are using it, good luck to them.
However, what I don't like about pb is the fact that, as someone stated before, even if it's marketed as a very simple language, it's actually not.
I get it, it has some really awesome libs, plus the cross platform part. Want me to tell you something, pb is as much cross platform, in my opinion, as C or C++ are. yeah, it abstracts away things for you, but it compiles the same native code from a functionality standpoint as your tipical gcc or msvc would generate. And as an added minus, it doesn't even use llvm, so no cross compilation for you, dear user!
But, that's not quite the point I'm trying to make, rather another idiom or whatever for not using pb.
My actual point is, or should be, pretty obvious. Well, how could a language priced 79 euros at its minimum, still expect its users to manage memory on their own? so, pb users, I'm telling you, you are paying that amount of money for a bunch of interesting C libs, a very accessible ide, I admit, some docs that are almost nothing to the beginner and, I think, that's all.
So, for me at least, pb fals out of the equation, unfortunately. I, personally, won't have the patience to create games that can't use oop, or in the building of which I have to manage memory manually. That's why we ran away from C and C++, right?
if it comes to that, I'd rather invest and learn to use azure along with a language like c#, this will bring me a long way forward. But this is besides the point, so let's go on.
2: python.
Contrary to popular belief around here, python is really easy to learn, more english like than even basic, pascal, or whatever, in my eternal, undieing opinion. and again, contrary to popular belief, not only through learning bgt first you can learn python. If we step outside our little community, try to awquardly land in this horible sighted world, a quick google search for python beginner tutorials can easily overwhelm a harddrive of 1 TB with text alone. I'm exagerating and all that, but I think you got the point alright.
Now, python was my favourite programming language for quite a while. Even though things have changed, I still consider it my second on the list.
for one, the amount of learning resources and tutorials is, as I've said, staggeringly high. As a little joke someone said around here, google is practically maried to python, lol.
Something else I like about python is how it can adapt to many workflows and stiles, that's why it was chosen amongst the most used programming languages, I think. A practical example to that is how it is adopted even in games, e.g the pygame library, and, more recently, lucia.
Now, What's not so good about python is everything about the release process.
one, it practically needs to package the whole interpreter and whatever libs the thing needs along with your actual game. That's pretty lame, in my opinion, but I understand it can't be otherwise, that's the way python was made.
then, speed is another factor to take in account. Even though it's faster than bgt, I think? it is not so well designed for fighting games, fps, or whatever. If you want an example, look at sound rts or even undead assault, though that's online so might not count at all, don't know.
next, we have some, rather minor, security issues. For example, even if you encrypt the bytecode as you can with pyinstaller, the key would certainly be there, in the onefile or onedir bundle, readable for all to see if they know where to look. One other option is to go the cython or raw C root, for better security, but, through doing that, one is durtying the beauty of python, or, as a beginner, it might be even impossible or confusing to do at that level.
So, in my opinion, python does its job very well indeed when there is no problem of not wanting to publish the source. For example, I believe that django is the way to go if you don't want php or asp .net. Or, for another example, python used in the context of a scripting language for something is really great indeed, I'd go so far as to say that python is an extremely advanced, and more useful, lua.
next, and unfortunately last, c#
Believe me when I say, c# and the .net ecosystem is my way of development, I hope it will be so for a very long time.
We all know the benefits of any jit compiled virtual machine, like the jvm, clr, etc, as well as the particular things that make clr special, so let's skip that for now, OK?
Personally, I think that, twards games at least and especially audiogames, the .net beast has the most potential, but, unfortunately, almost no good, accessible enough game specific libraries or engines exist in .net, like things we have, in a form or another, in the two languages I spoke above.
Personally, I don't build games that much any more. Since I stopped using python actively and embraced the c# way, I only build apps, small tools for various things I need to do...or don't, but just for the fun of it, or sometimes, because of bordum.
Even though things are this way, it doesn't mean I have no experience with game development in c#.
Once upon a time, I went to a programming competition where I was told to create whatever I want, as long as it meets some criteria not important for this example.
Back then, I was relatively new to the .net world, so I thought, foolishly, that I could make a game and finish it in time, too. Of course I didn't finish it, only the backend was done.
Only once I started thinking, I realised I don't have a nice framework that could be simple and even remotely tailered to fit a small concept demo of an audiogame, to present to some sighted people in there.
So, from then on, I really think c#, although it has alot of potential, is not quite there, at least regarding the eas with which you can create games. For example, I thought to use winforms as the frontend and, shall we say, it ended up pretty badly because, as I should have known, one can't really expect to create a small fps using winforms or wpf as the frontend, no matter what you have in the backend and still somehow manage a cool looking and sounding game.
Because I like the .net world so much, I want to talk about it abit more.
The only game engine I know that's practical and good enough for true production is unity. Besides the fakt it has a great amount of core libraries, a huge community, great documentation, videos, etc, the most important thing is that it has its own editor, with tools like level editors, physics engines, animation and scene management, etc. Plus, it has a significant amount of comunity created or comercially available pluggins with which one can make even more things than with the core libs, sappi and screen reader support is just something pluggins enabled game devs to do for accessibility.
one huge, jiant brick wall rises in front of us when we want to try this engine our selfs. Guess what, its accessibility is practically nonexistent. If some things are accessible there, it's because of coincidence, not design. Something like...I couldn't find a nicer, custom made controll that's completely inaccessible, so I threw in some native controlls that are **unfortunately**accessible.
Well, I kind of understand why they can't really make it accessible, too. The problem is, their engine is so focused on visuals, they'd need to rewrite a good part of the engine for it to make even the most remote kind of sense for accessibility. Though, with their money, resources and power, I don't think they won't be able to go through with that, but, at the same time, I understand that this might make the entire engine pointless for sighted, I sincerely don't know at this stage. Let's say that, at this point, without major changes from the unity team, it suddanly becomes accessible to the point of being usable enough for a game. What would likely happen is we would try to use it, only to discover everything more complex, like the level designer, is really based on sight, so that we would find our selfs in the same position as with the winforms designer, usable, but requires alot of calculation for the map to look even remotely good, mostly it will look and feel very offle.
So, unity is not accessible at this point, unfortunately. So, what else do we have?
well, an option I really like is monogame. Plus, unity uses the power of monogame internally, so even though we step down to a lower level, what option is out there if not this? I tell you, not much.
So, monogame. For those of you who might not know, monogame is an open source implementation of the XNA framework, an abandoned attempt made by microsoft at a framework dedicated towards games. I don't know why it was discontinued,it was a very nice idea, basically a kind of direct X coupled with some wrappers and design things to make it easyer, optimised and made specifically to run on the .net ecosystem.
As an open source version of xna, it shares the same trades, plus something of its own, the advantages of open source. For example, with the original XNA, you were limited to windows, while this uses the power of mono, recently known as xamarin,  so that means you can run your game mostly cross platform. Some of the platforms are what we'd expect from xamarin.XXX, android, iOS, mac OS, some linux distros and win10, 8.1 and 8 through uwp. But it supports more than that on its own, something game specific, yeah, consoles. For example, the XBOX, play station family, maybe nintendo switch, nes, I don't know, just maybe. Now, I realise why unity is so powerful and popular, not only because of the level designers, physics engines, whatever, but also because it uses monogame as its backend.
What monogame doesn't have in terms of audiogame development are very few, but somehow alittle significant things.
1. Maintenance and support. I am not really sure about that, but I think it's not actively developed any more. I might be mistaken on that one, so please correct me if I'm wrong. I didn't search for accurate info about it, so I might really be mistaken.
2. The absence of support for a great ide and tooling. I think it has vs or vs code extensions, but the instalation of the thing is, last time I checked, to say the least, really a not so plesent experience. You have to install dependencies and things in the correct order, otherwise you might get not so good surprises.
3. Accessibility. As it's just a framework, it's as accessible as what you use to employ it, so, if vs, pretty good accessibility, I'd say. Something else is the problem, though. Cross platform speech support, screen readers, sappi, braille, whatever is not present in the toolkit, but that problem can easily be solved by integrating third party solutions like the xamarin plugins for speech, plus something like toke or universal speech if you're on windows.
4. Physics. No luck in the framework last I checked, but box 2D can solve the thing, I believe.
5. audio. The audio in monogame is pretty lame, but don't despair, bass or, most recently, synthiser can solve the job pretty nicely. Only thing is we must find a way to get a file, memory stream, or whatever from monogame, as it stores everything in a content pipeline, like the original xna.
6. The last thing to say here is we don't have most of the things unity has, mainly level designers, map  creators and all that shit, but we can make it our selfs when the time comes.
So, as a conclusion to the longest wall of text in the audiogaming history, monogame is, in my opinion, the way to go forward. Everything unity has and we need can be built by us, only thing we need is a greatter colaboration than this community has ever seen, and, most importantly, we need knowledgeable people. For example, I don't even know how a level designer should look like, but I can certainly, for example, DK, write documentation, or write the speech part. Thing is, most of us say bgt is offle, please switch to something else. But the thing is here, that something else we are talking about is sometimes hard to master, or split across multiple languages, whatever, as I explained above.
Finally, the time has come to change that, we finally have most of the tools, we only need to bind them together into a cohesive piece of software people can use more easily. This way, I really think we will have great games, as people won't have to deal with so many complexity, instead they will try to concentrate on the game mechanics, or at least, I hope so.
The ebon sky studios team gave us an example of an engine that's very great indeed, there we saw that people indeed have creativity, just they don't want to learn such, to them, complexityes. But, as with all game creators of this kind, it's pretty limited, even tied to a specific game janra. And plus, without abit of coding, it's even more limited than bgt and, at least with bgt, you at least could call dlls. This engine is a good start in the right direction, but never good enough for, DK, more serious game development, sorry ebon sky studios.
And on a closing note, I want to congratulate you, @camlorn, you are doing what needed to be done since a long time ago, the fall of bgt. Keep it spinning man, perhaps we'll have something to be proud to call a truely usable audio library some day. If we are all going to gather and create that game engine I talked about, I'll be sure synthiser will be a main component for audio in there. Only, I think raw memory streams will be required for that. It can't be that hard, bass does it and it works pretty good. I'm sure you can do it, too. It takes just abit of time, right?
So, what do you guys think? would such an engine really be possible to create if we all join in the effort?
I really think that, at least with the power of monogame and .net backing us up, this game suite could more than be done. Now, I await your feedback.

@45
Python is fast enough for an FPS.  I don't know why people think it isn't.  Doom runs on the lowest end pocket calculators these days, and ours doesn't even have graphics.  At the upper end of an online game with a hundred players and 50 areas and each player goes to a different area so you have to simulate all 50 areas at once, and you're running astar everywhere--sure, it'll start having problems.  But even Swamp has 5 maps total.  People talk about how Python has speed issues, but no one ever says "here is my game, and I failed because it's slow".  Talking about speed is just this mythical thing that floats around audiogames.net, the only thing that I know of that had speed issues was SoundRTS, and that wasn't Python, it was just replacing lists (which are arrays) with sets because checking if something is in an array of a thousand items is slow no matter the language.  And most people didn't notice, we just fixed it because there was a group of 5 or 6 of us who started playing with literally thousands of units, and once the data structures were swapped it went from unplayably laggy to lag-free.

Size of the app doesn't matter, because size of the sounds dominates anything else for any reasonably sized game.

C# can be as easily decompiled as Python.  You don't quite get the same level of "here is your actual source code" out of it, but the .net framework uses an intermediate language that's much higher level than assembly.  I think there's tooling to go all the way to native code, but if you don't you can actually even introspect the classes in the executable, recover attribute names, etc., it's not that hard.  System.reflection exists, in other words, which means that if you don't go out of your way you're shipping a database of every type in your program sufficient to be called dynamically with not that much work.  Your encrypted sound database that uses in memory streams etc etc etc? Hold my beer.

C# is fine as far as it goes. I won't use it because I was programming in 2010 and I refuse to get shafted if an IDE goes inaccessible on me, but in general use whatever you like.  But the reasons you're saying you chose it for don't matter much either way, and you're gaining much less security than you think you are.

@48
You're talking about networked fpss, if I'm not mistaken.  Networking comes with an inherent 50ms lag minimum, usually much more, and without very well done client-side prediction you can't hide it.

In order to determine whether it's the game's networking code or the game's algorithms, you look at the CPU usage on the server. Low CPU usage but high lag is networking, high CPU usage and high lag is work on your algorithms.

if it is slow because of algorithms, my money is on collision that looks like this:

for a in objects:
    for b in objects:
        if a.collides_with(b):
            # something

Which (irregardless of language) will become laggy very quickly.