Posts: 1 to 25 of 35

Earlier today, I wrote a post outlining my reasoning for why I think BGT is not a suitable audiogame development environment, trying to write as objectively as possible and proposing an alternative. There has been a lot of unfounded bashing of BGT lately, and I don't think that is fair without propper factual backing. Here is my take on the matter:

Hi,@Ghorth, first of all this is funny because from one minute to the next, I'd just clicked the topic to reply to it and your post wasn't there, then I logged in 30 seconds later and it was .Anyways, one thing I've been wondering about JS is, how can you obfuscate with things like electron. I was curious about how Cyclepath worked one day, so much to my surprise I was able to google how to decompile electron or something like that, it was like August, I forget exactly what the search query was. But in the first few results, I discovered the unpacking util for app.asar. Then, I was able to decompile Syclepath and from there found a package.json file linking to your gitlab, where I then found the official repository along with those for some other things like Dark Defender I think, an fps you were working on in JS, etc. Anyways, what I'm getting at is, for closed-source apps, is there any way to obfuscate the code so it isn't so easily accessible?

One thing about it is, if you want to use python, its hard to get started with it because you not only need to learn to code in python, but you need to learn how to set up virtualnv or something like that so that you can have an environment to work in that doesn't mess with your other python stuff. You also need to learn how to find out what methods you can call on modules. Python stuff is confusing to me, I know about dir(), but not much else, and it seems anything you want to do, you first need to become a detective and sort of trace these things back to their roots to find things you can call.

SO if someone could come up with a guide, or a series of tutorials from a blindness perspective, I know for one thing I would appreciate and use it, and I'm sure other people would as well.

Also, python lingo seems to be a bit different as well, and that's another source of confusion for me. I think you don't say methods in python, I think you say attributes, or something to that effect, and they have random seeming names for things other languages have standardized.

regarding obfuscating code, yes, it is indeed possible, tools for doing this are called minifiers and they make your code a huge js file with the variable names changed to some unintelligible two or three letter names, they remove all comments, newlines and indentation and make other changes that make your code smaller, faster and, as a consequence, harder to read. Most serious websites, especially those made with modern web frameworks like react or angular use them by default but it should be possible to do this for just normal code too.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.

Javascript was my primary platform until 2008, and I still used it some as late as 2010. One of the big problems I had was cross-platform compatibility and audio support. Hah-flippin'-hah, you sure got me there, internet. -_-The last time I tried webaudio, I was informed that I required a server to do anything with it, period. Local files are a forbidden security abomination now, apparently. I do not have a server. Keep in mind that the more complicated the setup, the less likely I am to find it worth the effort. Then there's the fact that JS as it is in 2018 is nigh unrecognizable to JS as of 2008. Not just more advanced—practically a different beast entirely. So all that background is apparently pointless, now, presumably along with all of those scripts I collected and created to make it work more smoothly"But," you say, after some true but neither necessary nor kind remarks about it being obligatory to keep up with changes to remain relevant, "It's clearly worth the effort, as this article demonstrates."No, it really, really isn't. I can port a good game from BGT to JS and back. Or crappy games, even, since DLE was originally written in JS. All of these arguments for moving away from BGT, with the exception of cross-platform support and community supportonly matter if people are actually making games that need the bells and whistles. You can have all the post-2014 3d sound you want (I know this existed in the 1990s; I've made posts complaining about that very thing, because it has had stupidly high barriers to access prior to Camlorn's efforts) in the world, but if your game sucks without it, your game sucks with it. You can set up your code such that you can swap out BGT's audio system with something better. You can, other than those at-signs, write code that is very easy to port to another language, including ways around the dictionary and array implementations. So my thoughts are that the effort involved in switching to another language is not worth it without solid games in the first place.To quickly reiterate the main points:

The lack of cross-platform support is a legit problem.

The lack of a strong support community is a legit problem.

The lack of 3d sound and fancy libraries are not important at this time, because no one has made a BGT game that requires them. At most, I'll grant that the FPSes could stand to switch platforms, since over-the-top presentation style is a distinguishing factor when it's mostly just the social PVP flare type.

My philosophy is that the game must be good first, pretty second (if not later). BGT's technical limitations put a cap on prettiness, not the underlying game, for 99% of games people want.

The fact is that a lot of BGT developers do not know anything else and don't know what they do not have, which makes sense but limits them. This trend of BGT pseudo-fps games would indeed benefit from 3D audio and the LAV BGT implementation, as I understand, is unstable at best. WebAudio does not require a server. Again, look at both Dark Defender and Cyclepath. You said it, JS is not what it once was and many qeople who have used it for a while complain about problems that have been gone for a while. You could just as well defend that since Lightech Games and L-Works games worked well, BGT is unnecessary and VB6 works perfectly well. The setup for a JS-based project is somewhat complicated for the first time, for now, because nobody has cared to try using it and making it better for everybody else. You are right, a game sucks no matter which language it's made in, but that is because you are going on the premise that what we'll do im port games. The average BGT programmer, as seen in post 3, knows what BGT offers them and little more. We're used to a quick but limited support. Obviously as you said, some things are bells and whistles, but 1, sometimes bells and whistles make games all the more innovative, and 2, the lack of bells and whistles aimed toward game development in the Blastbay *game* toolkit is part of what I mentioned.

Yeah there are ways to make code extremely hard to read. Cyclepath was my first real game in javaScript so I didn't know a lot about that kind of thing which is why it's probably so easy to just grab all that stuff. Made a lot of repo's private on my Gitlab though, thanks for making me aware that people could simply just register. That shouldn't happen. Not on my private Git. LOL

Although most of your points are completely valid, there are just a few things to consider:1. bgt is adequate for basic audiogames. If you are a beginning programmer and want to get off the ground quickly, bgt is your best bet, at the moment, simply do to it's all in one nature. If someone would just want to get started and not do a tun of searching, bgt is the only way to go, I think, correct me if I'm wrong. There are no guides / wrappers for other programming languages which tell you how to make an audiogame with the required libraries. Something wherein you can just type sound.load(filename); and then play it. The just slightly higher learning curve might send them running to bgt.2. I find it ironic that you mention bgt's executable size as a drawback. Electron apps, if I am not mistaken, are huge.Do understand me, most of your points are correct, It's just that when someone would ask me how to start learning to code and that they wanted to create audiogames, I'd point them to bgt, simply because most of the concepts introduced in the language tutorial are general programming concepts, and those can be hard enough to grasp for a new programmer.

@10 you are absolutely right about Electron. I definitely didn't compare that part of the two, I just find it somewhat funny that BGT is supposedly compiled and generates 800kb executables.

As for your other point, BGT may be a starting point right now, yes, but part of what I aim for is for the process to create games in something else to become much more straightforward. Again, as I said at the end of my post, BGT is by far not the worst we have, and yes, I agree that you don't need much more for simple games. But I don't think it should be much more than that, a starting point to introduce you to basic concepts and let you move on to other things. I think we, as developers, should, in a way, strive to show our users the capabilities that current technologies have when they may make playing experience more enjoyable, and yes, I realize this last sentence may possibly ge me more bashing than the whole entire post.

I think people starting out in BGT is fine, its just they stagnate there and never move on. I've embarked on a process to learn python, and my god its powerful and easy. I love all the data analysis stuff that comes built in.

The only problem with BGT is that it's no longer maintained. Networking support and dealing with Dynamic Link Libraries (dlls) requires attention and really needs to be improved. Oh yeah, and that problem where Windows Defender hates BGT and thinks that it's a virus, I almost forgot it. Regarding the toolkit and the language, you can write more than just a basic game in BGT for sure. Just look at Manamon, Perrilous Hearts or Survive the wild. Both games are written in BGT, and both games are popular here among users, despite the fact that they don't have 3d sound support.Regarding Javascript, I'm currently studdying it. Not necessarily for games, but also for making web apps. There are tutorial series on modern Javascript on the following website: https://javascript.info/

Everything is basically already here, all that's needed for bgt to be dumped for new developers is a tutorial (which actually got started by ctoth) that just walks someone threw setting up python or any other language of choice, get's the accessible tools, give a few library hints with maybe some example code, and after that to tell the programmer to use google and good luck.

Well, in my case my preferred environment for development is the .net with c#.

I think that is a very good tool, with interesting frameworks on it, one more accesible than others.Some games will can be created withtout problem with wpf, or more complex care viable with monogame / cocos sharp and you habe 3d support with... well you have two or or three options to concider... if you don't want to count the options of c++ that can be loaded through interop.

Have an accessible ide if you like heaby but functional complex coder programs and more.Is curious how on this community, that platform is not considered for the debelopments.

Oh, and one more thing. BGT's weird bug where, occasionally, a sound will get stuck in an infinite loop of the last second or so, and the game hangs. That one's mysteriously stayed away for quite a while, so I forgot to mention it. Yeah, that major nuisance is fair game for migrating elsewhere.

helloi also should add some points:if you look at exec.bin in the bgt, it is a valid executablebut, your script files which are compiled into bytecode and encrypted are appended at the end of it and will be copied into the new executable file that you can run itthe executable then reads itself and execute the script bytecode (no JIT (just in time) compiler, which makes it slow)the 800 kb size is the size of that exec file which contains bgt's functions, classes etcand, if you want your game code to be seen easily by others, consider using jsbgt's audio capabilities are less than its requirements (Direct Sound 8 has many many more features)also no frame rate feature (you should use timers which are inaccurate)and the worse, bgt isn't developed anymore

Basically, CAE, it's not being updated. It can't take advantage of modern computer features like multithreading or SMP. It has no extendability (i.e. you can't add graphics into a game if you wanted to). You can't use databases or SMTP without PHP scripts, which complicates everything. You can't do even 1.1 percent of what you can do in a programming language like C++.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.

I agree with Cae here. Making it single-threaded only was a deliberate design decision. The Boost C++ libraries that support smart multi-threading with threadlock barriers and whatnot were not even a thing by the time BGT was first released to the public if I'm not mistaken, and even if they were, Philip didn't want beginners to have to struggle with yet another fundamental programming concept that becomes second nature once mastered but is really difficult and challenging for most novice programmers and/or scripters if you will who haven't had any previous experience. Just look at how many people are still struggling with something as rudimentary as handles, although I do agree that the way they are implemented in BGT, or rather Angelscript itself, is somewhat counterproductive and non-sensical. :-)However, all this academical stuff aside, I haven't yet come across a single instance during the development of my games where I would need to implement something that I couldn't do because of BGT's single-threadedness, if that's even a word. :-) Yeah, some things could have been done more elegantly or efficiently if multi-threading was an option, but to tell the truth, whocares about code elegance or performance efficiency in the context of solely Windows-based audiogames without taking advantage of any truly modern computer features, as someone called it? If it works, doesn't crash and has no gameplay breaking bugs, I'm fine with it, given the scope it's intended for.

The only real, practical, every day problem with BGT not being updated any more that I can foresee is that games written in it will sooner or later become less and less reliable, eventually leading to the point where they will just no longer work on modern versions of Windows at all. Even if Microsoft is painting the thing as just a single universal OS by the name of Windows 10 to rule them all, the fact is that every major aniversary update is essentially as huge and complex internally as what service packs for prior Windows versions used to be, and some could probably even be called entirely new iterations of the system. If not now, then it will certainly become the case at some point in the future. Not to mention that if it was still being maintained at least on a semi-regular basis, maybe something could be done about the Windows Defender false positives, and improved networking capabilities and DLL support could also come in handy in relatively many cases that *are* related to game development.

Even so, I do not consider the current state of things a major drawback until actual serious problems start appearing. I've noticed that only games that do utilize an internet connection of some sort seem to get flagged by antiviruses. A game that doesn't touch the network object at all seems to remain unnoticed. And if your game does use internet, like Manamon, Super Egg Hunt or Oriol's games, creating an exception for it is not that hard after all, as long as you are using an accessible antivirus. So, for the time being and for my needs, BGT is still a good starting point for me, at least until I finish all my currently ongoing games. When I'm done with them, I can start worrying about the future, before I start developing any new projects.

@CAE My biggest problem is that the audiogaming industry is already a few years or even decades behind. I am of the opinion that, if we have the option to use something newer, better, and more supported, it should be taken. Yes, BGT may be a decent way to make a few first projects, but we are limiting ourselves. Not everyone needs what other languages may offer, but many people who make more complex games find themselves wanting feature X that is not practical to implement with BGT. Once again I will say that I do not think JS is the only right approach, just as I think that BGT is not the most horrible one. If it has achieved this popularity it must mean it is good in some way. I am simply trying to outline its many issues and the reasons why I would definitely consider at least taking a look at other options. I am liking the JS approach more and more, and I do understand that right now it is quite a mess to set up, especially on Windows. If people agree with me, however, I am willing to write an article and possibly a few scripts to make this process much easier and faster.

I myself would certainly be interested in the JS approach. I would appreciate some pointers when starting off, so that I wouldn't spend loads of precious time just trying to figure out how to set things up by trial and error. I've had some initial experience with Javascript when developing a website, and its cross-platform support is definitely one of the reasons that make it interesting and appealing as an alternative to BGT. However, I assume it would have the same issues as Python, for instance, or any interpreted language for that matter? That is slightly decreased performance, even if most of it is probably impossible to notice on the end user level, and relatively easily decompilable source code?Lukas