2019-04-30 20:57:24 (edited by amerikranian 2019-04-30 20:58:25)

***ATTENTION!!!***
To anyone smart enough to know what they are doing, I urge you to read this carefully and think rather than act when you're posting. The last thing I want this to turn into is a giant drama. I want to have a civil discussion and hopefully learn from it.
So, my question is this: Let's say you are a BGT user. You coded some games, doesn't matter how complex they are, and you've been told the following:
"You should switch to language W because of X, Y, and Z"
I won't put in a language and the reasons, allowing you to fill in the blanks with your own imagination, but that language must be different than bgt.
What will be your reasons for refusing such a request? What does BGT offer that you think the other languages do not?
I am not asking for reasons as to why should you switch from BGT to, say, c#, I am asking what will be your reason not to do so.
This question came up after a certain user expressed a rather strong dislike of anything but BGT and refused to provide any good reasons as to why they love BGT and that's the only thing they will use. I am hoping to hopefully understand the possible reasons behind such a  refusal so that in the future we can possibly provide a smoother transition from BGT to more complex languages.

Coding is not hard. No, not at all.
What is hard is making code that accepts different and sometimes unexpected types of input and still works.
This is what truly takes a large amount of effort on a developer's part.

Thumbs up

2019-04-30 21:23:32

The answer to that question can be complex, and isn't always rooted in stubbornness or foolishness. Whats always hot and new isn't always the best, or most comfortable tool for the job. Some people still work with [MAC OS 9], some still use [MS-DOS], or even [make games] for DOS, or use DOS based [Word Processing] software. People even still make monochrome GameBoy games, because they enjoy the hardware limitations and challenge.

Thw only true constant here is that languages, software, and hardware never really die, they just become niche. There are some advantages and disadvantages to this, as with many things, but one shouldn't judge others for their choice of tools, even though they are entitled to their opinions.

-BrushTone v1.3.3: Accessible Paint Tool
-AudiMesh3D v1.0.0: Accessible 3D Model Viewer

Thumbs up

2019-04-30 21:24:49

For me, there are a couple things that allowed BGT to have a pull on me for a while. I am certainly glad with python now, but I will still use BGT occasionally. For quite a few reasons.
1. The chalenge: With BGT, you won't find help on stackoverflow when you want to solve a problem. With BGT, there have been many things I have managed to do that I had been told would be impossible. Things such as writing a scripting engine that is actually somewhat advanced, reading DLL structures, etc. I like using BGT sometimes because it places me in a limited environment and with it's limited dll support and other things, I can try to break it and make it do new things despite everyone telling me how impossible it was. It's just for fun, and if it's stable sometimes I can use it in games like stw, but I feel that it helps me become more intelegent sometimes because in python, you install a lib, you import it and use it, and your done. with BGT, you make a lib, understand the internals, and get it working in a stable fassion and you experience the warm feeling if doing something that others constantly told you wasn't possible.
2. Compilation. With python, you install pyinstaller, compile your script, and hope it works. Same with most other languages. With BGT, you click compile script. Some languages like pure basic have a cool compilation process, but with a lot of low level languages, you could write a small application that is 20 lines of code that took 10 minutes to write or less, then find yourself spending 2 hours trying to make pyinstaller work with a phinicky library.
3. Executable size: With BGT, you get pretty small executables that you can send to people and they can just run and play. With pyinstaller, you get executables with a size of at least 4 MB. It's not a huge deel, and languages such as CS and CPP can make quite small exectables, but it's just something else to be considered.
4. Code protection: With BGT, you compile and send, and you have rather little worry of someone decompiling your code and steeling it. With python or CS or nearly any other language that does not compile to machine code, which is a lot, code protection usually takes a vast amount of creativity.
5. Existing tools: When making a small sidescroller, BGT just has everything you need to get working quick. With other languages, you need to implement your own sound, keyboard, networking, sound protection, etc etc.
6. Speed: BGT is generally fast. In some cases, faster than some operations in languages like python. You can cythonize sure, but you just askd for potential reasons to stay with it, so I'm just trying to provide some ideas. In languages that are just as fast or faster, you usually need to learn a lot more to get them to work.
7. Ease of use: With BGT, you make a main function, you make a sound object, call the load and play_wait methods, and there you go you got a sound player. This as well as other game tasks are much harder in other much larger languages.
8. All together: When you combine the above reasons together, and I'm sure I could come up with more but I am out of time, you got a pretty quick language that compiles easily, is easy to learn and use, has tools and somewhat ok protection, etc. You can see how to someone who just wants to make a quick game, it does exude quite a pull.
Like I said, I now use python and other languages and I am very happy. I am not trying to worship BGT or anything lol. I hope I dont's tart any arguments, I hope I have somewhat satisfactorily answered your question.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-04-30 22:36:59

Hello,
Amusingly, for the first year, before the issues of virus detectors getting sensative, I was in the "bgt is fine leave me alone" category.
There was only two reasons behind this:
1. I knew what I was talking about with BGT. It was simple to understand, has a nice layout with braces, and the error messages are generally amusing, in a geeky kind of way.
2. Fear. With a new language comes fear of screwing up. BGT is a beginners language. It stops you from screwing up too badly. It's not that easy to use up all the memories computer, corrupt the hard drive, or blow up a spacecraft using BGT. Sure, you can do it, but it's not *easy( to do.

To that end though, I wanted to comment on post 3 a bit, and go over my personal experience having switched from bgt to other languages:
1. the challenge: I can see that. I like a challenge myself, but so far python, and other languages, are still providing that without limiting myself too much.
2. Compilation: Well... BGT's compile didn't just compile. It error checked, then compiled into an exe file. Pyinstaller just does the latter. that's why you run the script first as a python file, to error check, then you pyinstaller it. Which kind of ties into number 1, great challenge!
3. I can't disagree with this at all. BGT's compression is amazing to see, and i do miss it. Though I also know that other languages can beat BGT, I'm just not quite brave enough to learn them. YET!
4. I'd say a good 85 percent of languages compile to computer machine code, and for those that don't, wrappers are available that force them too. Even python can be forced, I *think*, It's just not as easy as BGT. Even with BGT, advanced users reported reverse engineering programs to be laughably easy.
5. Ehh. Language dependant but fair enough. Python pretty much comes with all that bundled too, you just have to know where to look, but... Fair enough.
6. I *completely* disgaree on this one. I've not come across anything (yet), that BGT does faster than python. I'm open to being disproved! Also, long live cython.
7.  Again, I agree with this. the sound library thing is a big reason to stay bgt for a lot of users. But honestly, writing your own sound wrapper is a good excersise to test your understanding of the programming language, and once you've done that, it's just the same as bgt.

Hopefully that didn't come across as me being nitpicky, it is just my personal experience from a different perspective.
I'd say out of all of these, the biggest BGT stay reasons are:
easy to compile,
easy to learn,
sound library support,
speech support for screen readers,
fear.

Reasons not to though, are of course:
speed,
flexibility,
virus checkers,
cross platform support,
native TCP in networking,
and more!

Nathan Smith
Managing Director of Nathan Tech
It's not disability
It's ability!

2019-04-30 22:51:51

The main reason for me is it's ease, and it's simplicity.
I managed to learn a good amount of what's in the manual in about 4 months, and it took me maybe a couple months of just screwing around in .bgt files to learn what I was actually doing, and now I don't think I'm all that bad.
I'm still working on arrays and stuff like that, but that's my next thing to tackle.

yo! so I'm working on programing, it's really hard. But I'll tell you where you can contact me if your stupid enough to do so.
Contact information:email: [email protected]
Skype: Brennan Draves
I'm usually found on online games, chatting, and being warned bye admins for talking to much, f**k you admin!

2019-04-30 23:26:25

As much as I like other programming languages, for me what makes me not to drop BGT is its executable (and the program's size too) and
9. BGT has a very simple and easy to use audio engine.
Yes, there are other audio engines much better than bgt's one, but they are more
complex to use or lack functionality, like in Pygame a pitch function. Phillip managed to just get it right, making it simple so that everyone could understand it and use it correctly.

Thumbs up

2019-04-30 23:29:22

@darter, about speed, make a loop in BGT that executes 10 million times and assigns a couple vars and stuff, then attach a timer. You will see that this same loop will run considerably slower in python. For compilation, the theory is of course that you test your script, then you compile and all works. Unfortunately, things get a bit trickier than that, especially when you want to protect your code with cython which makes pyinstaller unable to read imports to include the right modules and aaaaaaaaa! big_smile And another thing I never got to mension because I ran out of time, just randomly on the subject of python, with onefile, everything extracts to a temp dir when you run it, and then deletes itself when you close the app. This accounts for longer launch times in python than BGT and major disc overhead. With that said though I really do enjoy python. As for languages compiling to machine code, I think there was a misunderstanding. By machine code, I mean core machine code, like assembly instructions. Take CS, for example. It's a very widely used language, but you can run it through a decompiler and in some cases even get comments back, as well as variables and other stuff, and source code that you can actually recompile, on account of CS going through the middle phase of IL code which can be easily broken. The only way to make python compile into machine code is to use cython to first convert it to C. Otherwise, you compile to python bytecode. I do believe languages like pure basic and go, for example, do however compile directly into assembly instructions, which are very hard to propperly disassemble because of how little needed information they contain. I do agree though that if you want a challenge in python you can choose to make your own library rather than installing an existing one. Though in BGT, people literally will tell me no sam it is not possible to read DLL structures. It is not possible to make a fast scripting engine. It is not possible to get 3d audio working. As a person with very very low self confidence, it is extremely refreshing to be able to sit down and be like "oh... yeah?" With python or other mainstream languages you have virtually 0 chance of being the first to write something. However this last reason is more of a personal one for me and wouldn't really contribute all that much to public projects.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-05-01 15:35:55

No reasons for me.
Sam, in CS, which is my favourite language you have a .NET Native thingy. The process is not that hard
You import ccostura32, write a quick config file, obfuscate with dotfuscator and compile with NET Native

Raduvay se, raduvay
Raduvay se domaki ne
Kolko liste po gorach
Tolko zdrave na taz kyshcha

2019-05-01 16:54:56

@8, issue is that .NET native is windows-specific, I think.
@7, I ran the following code in Python just now:
timeit.timeit("""i = 1
... while i < 100:
...   i += 1
... """, number=10000000)
This took 36.944594424 seconds to run. Running it three times to gather metrics creates an average of 37.02766088533334, with each individual run yielding a time of 36.921045634999984, 37.095540741000036, and 37.06639627999999, respectively. Add the original number to the total and you get a new average of 37.006894270000004. The equivalent BGT code would be (for the loop only):

for (int q = 0; q < 3; q++) {
for (int i = 0; i < 10000000; i++) {
int j = 0;
while (j < 100)
j ++;
}
}

Give that a go and give me your results.

"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.

Thumbs up

2019-05-01 17:27:43

I have to go so didn't time each entry and calculate averages, but running that script took 96326 milliseconds. Devided by 3, that's 32108.666666666668 ms, or about 32 seconds. As you can see, this is indeed faster in BGT by about 4 seconds. Not a major improvement, but as I said, I'm just trying to answer the op's questions, and as you can see this is indeed slightly faster

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-05-01 20:42:32

Interesting. I am quite happy with the results of my question.
@3:
1: Understandable, but I can't say I relate to it. One neat thing about python is the ability to type in what you want on google and receive mostly good quality results for what you want. There are also many examples out there for pretty much anything you can think of, though some might be harder to find, e.g, text input, but that's why we have this forum.
2: You'll have no argument there. It is easier to compile BGT, though I think that is partially do to the lack of guides on compiling.
3: No argument there once again, though I don't understand why the size is a determining factor. Why does it matter? The mainstream games are way bigger and nobody complains.
4: Again, no argument.
5: Eh, one would argue that all you need to create a game is pygame, but that is a flawed argument within itself do to no screen reader support and the lack of a good sound library, so I'd say I agree with you on this about 50% of the time.
6: We learn something new every day I suppose.
7: Point taken and noted.
@4:
1: Are you suggesting that the reason why somebody would stick with BGT is because they feel superior with the knowledge they have and cannot stand the thought of being a newbie again? I just want to make sure I am reading this correctly.
2: Again, something I can't relate to personally, I grew up with the knowledge that I am going to fail and sometimes failure makes me stronger as a person. Still, I suppose you have a point there, though I'm not sure if I can do anything to ease anyone's worries and fears. Sometimes you just have to go for it.
On the other hand, maybe the advice above is the soul reason as to why I'm single... nope, totally not.
@5: Good point, further reinforcing the simplicity point of post 3.
@6: Again, why does the size of the executable matter? I fail to grasp the point here.
As for audio engines, hopefully that won't be a complaint for much longer, as if you've seen my topic on the sound pool in python, I mentioned Carter's sound class. He created something just like BGT's sound object, which should hopefully put a stop to the complaints.
Thank you all for responding and if you think of any more possible reasons do let me know. I'm thinking of creating an article that focuses on what you will absolutely need to create audiogames in python. Might be a bit before it's posted, though. I have finals coming  up and stuff, so if anyone wants to do it instead of me go ahead.

Coding is not hard. No, not at all.
What is hard is making code that accepts different and sometimes unexpected types of input and still works.
This is what truly takes a large amount of effort on a developer's part.

Thumbs up

2019-05-02 10:53:04

Hello!
Pygame does have a functioning sound library? It's called mixer.
HTH

Nathan Smith
Managing Director of Nathan Tech
It's not disability
It's ability!

2019-05-02 15:37:46

@amerikranion, I mean, the executable size isn't, really, that important, but it's just a little bonus.

yo! so I'm working on programing, it's really hard. But I'll tell you where you can contact me if your stupid enough to do so.
Contact information:email: [email protected]
Skype: Brennan Draves
I'm usually found on online games, chatting, and being warned bye admins for talking to much, f**k you admin!

2019-05-02 16:07:31

Yeah, Ethin you are right, but BGT does not compile on other platforms either. You know my opinion about that "language

Raduvay se, raduvay
Raduvay se domaki ne
Kolko liste po gorach
Tolko zdrave na taz kyshcha

2019-05-02 16:26:47 (edited by Ethin 2019-05-02 16:27:48)

@14,, .NET compiles to MSIL -- which gives it an advantage just as the JVM class file format gives the Java Virtual Machine an advantage -- it can be run on pretty much any platform that can run either ELF or PE binaries. Wth Java its even more of an advantage; a java program can run so long as there is a JVM implementation for it (there are some processors out there that natively support running JVM class files directly on bare metal, supposedly).

"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.

Thumbs up

2019-05-02 16:42:10

for cs, to run on other platforms, you can use mono. Also yeah the executable size would just be an advantage.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-05-02 18:27:02 (edited by Ethin 2019-05-02 18:27:55)

@16, only a slight one. You can make ridiculous executable sizes -- pack files much? (Also, its really easy to create large executable files in languages that compile to native code. Hint: debug information, huge data structures, large constant arrays, ...)

"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.

Thumbs up

2019-05-02 19:42:11

Hello,
I don't think bgt is the optimal language for coding games anymore, especially due to what's happening with antiviruses right now. But I don't think of learning another programming language at the moment because bgt offered ease. I could start coding immediately when I installed the program by looking at the user guide. For example python is not like that. I have to lern from another source and that makes me feel lazy to do so.

I post sounds I record to freesound. Click here to visit my freesound page
I usually post game recordings to anyaudio. Click here to visit my anyaudio page

2019-05-02 20:19:47

Lol sorry I wrote that last post in like 30 seconds at the end of class. For executable size, I meant to say that you just have the small advantage of what can be quicker downloads and sometimes more clean folders. Everyone loves to download things quickly and play them. For example if I wanted to write a text adventure, I would probably write it in cs just so it's more easily portable and launches quicker, etc. As I said only a slight advantage, but nice small apps like that do still look nicer. I'm not much into writing text adventures in python because then every time someone launches my command line application to play, a bunch of stuff either gets extracted to a temp directory or you have to distribute your app with like 70 odd files and a larger package. BGT has many problems, but one thing you must admit is that it's executibles are more times than not quite quick and nimble. Your app can launch in like 150MS and you can play faster, and while no one complains about slow loading times, everyone appreciates slightly faster loading from time to time so they can get playing faster. HOwever I am of the opinion that people should see this as just a small advantage. I ran into the same issue with adding lav into stw. With lav, you can't play anymore on xp. I knew there were still some players who used XP, but I think a lot of developers in this comunity do need to make the choice to move on so they can make bigger and better things. Eventually I added LAV which requires much more processing power and generally better hardware, and potentially breaks xp support and causes slower loading times, but it's over all a much better experience for the people with that hardware. People shouldn't be afraid of large executibles or massive game sizes or even slow loading times if needed, because they are perfectly normal and are sometimes required to make a bigger and better game. Of course the lower the loading time the better, but I do believe it should not be a reason to stick to a certain language and if there is no choice as mentioned, people get that things have to load, so it's ok.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-05-03 15:59:55

So as I only know a teensy weensy itty bit of Java, but what's better about Python than Java?

You should've gone for the .net ...

Thumbs up

2019-05-03 16:28:43

Python has better, lighter GUI libraries as far as I'm aware

Raduvay se, raduvay
Raduvay se domaki ne
Kolko liste po gorach
Tolko zdrave na taz kyshcha

2019-05-03 20:17:07

Hello.
So first and foremost I will begin by saying that I haven't programmed in any of the other languages, but I have looked at cintax. But with that said yeah. I personally love bgt pretty much because of what everyone else has said here. It's smooth, it's quicker than something like python when it comes to loading the game data. And it's just smaller. I mean, why would I want a 30 meg python game when I can have a game in bgt that has twice as much content as the 30 meg python one, and it's not even 3. Look at cp. It's 3 megs and nobody's bashed it for being bgt at all. So yeah, I don't intend to start anything, I just think that some games are just so so good that nobody cares if that dev switches or not. But when it comes to another game, one that's not as good, people are like, oh look. You need to switch to language l because m n and o. Yeah, no intentions of starting an argument, just my feelings personally.

-----------
I'm the true source of dark evil. Beware.
Have a nice day peeps

2019-05-03 20:19:41 (edited by Ethin 2019-05-03 20:20:07)

Java is pretty neat in its own way though. Compile once, run anywhere (or write once, run anywhere (WORA)) is its philosophy -- and it has pretty much accomplished that. Its statically typed, something that Python is not, making it far stricter on what you can and can't do. Its a bit harder to make a mistake that ruins your program in Java than it is in Python (though that depends on what your trying to do). The especially awesome thing about Java, though, is not the language, but the virtual machine. The virtual machine is an "abstract computing machine." That means that it has what it neds to run any kind of program and nothing more. It has CPU registers, for instance, and to a degree it has memory as well. But it doesn't have a network card, or a GPU, or a disk drive, or any other components of a "physical machine" because those are not requirements to run a program. What's even better though about Java is that:
1) you are free to make your own custom implementation of the JVM in whatever programming language you like, so long as you conform to the JVM specification. (JVM in Python, anyone? Would be slow but kinda fun to try.)
2) You are free to embed the JVM in other applications (native code). (Yes, you read that right.)
3) Like the CLR, you are free to make your own programming languages on top of the JVM, and they can work howevr you want them to work, so long as they are decomposable into JVM bytecodes.
The CLR is similar in this regard, but lacks the embeddability or implementation parts, and I don't think it has any specifications that define its "abstrac computing machine" or native C/C+ interface for embedding.

"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.

Thumbs up

2019-05-03 23:28:33

Well, that helps. Thanks!

You should've gone for the .net ...

Thumbs up

2019-05-06 00:25:15

Another smaller reason I thought of is that I don't think some people like indenting code. Again this shouldn't be a reason to stay, indenting can be quite useful especially when working with sighted collaborators, but if we are looking for reasons to stay, that's just something I could see somebody using as an argument.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com