I got it.

The way I see this is that this tool is an abstraction on actual programming. Some say this is an over simplified abstraction, while others argue this is just adequate for the minimal of tasks. Despite what anybody believes, there is bias. The true way to know if something is actually useful or produces results is to make use of the product. Because at the end of the day, even programming is an abstraction on actual electronics, and you don't hear engineers producing arguably "tangible" products criticizing programmers for their use of abstractions on their creations. Just some food for thought. I, for one, am excited that efforts are being made to increase AudioGame creation throughput. Whether the games themselves are considered to be "valuable" or "innovative" is a separate conversation.

Hi.

Personally speaking, when I started my 3 year Training back in 2017 I started out in the programming branch, because i thought that this would be the right path for me to take.

Half a year later I sat down with my instructors and I made it clear that I wanted to switch over to the salesman department.

The problem i had with programming was that I had issues getting the syntax and logic into my had and using the knolledge to code something that would work in the end. And when we got to OOP with classes and all that stuff, I was completely lost, this might also come from the fact that we were never told why we should do this.
It went like, this is a class, this is a wrapper class, these are variables and constants. You go and use it now.

Well urm, the fuck?
For those who care, we started out with java.

I see the GDE and the sable game engine, to throw that one into the mix as well from both sides here.

From the programmers side both of these tools are limited, errors can't be fixed unless you have the sourcecode of the program itself and you don't have the freedom to do what you want.

From my side or the more creative side, I don't have a problem with those engines. I'm far better in designing worlds, thinking about how I want characters or quests to look like, write up a story and let the hole coding part be the work of someone who actually knows his way around a programming language or leave it to an engine that deals with the intigration so I can focus on the things I am good at.

Greetings Moritz.

So, I took a look at the site. First, there is just about no formatting in the tutorials. No headings, grammar problems, and rather long paragraphs made it rather cumbersome to read, on a Mac at least. But this is for Windows users so what am I talking about, just use P for paragraph and skip all them links, I suppose. Second, wow, the program's interface, from reading the tutorial seems really convoluted. Like, having to confirm if you want to make a new project? That seems like bad design to me. But, again, I didn't build it, so there must be a reason why. Also, having to go through so many menus, dialog boxes, and try to remember what you're doing while doing 10 steps to do it reminds me of texting on an old flip phone, where I'd regularly forget what message I was writing, while writing a word. Meanwhile, a Python program, which doesn't actually work but should because I spent an hour on it, is below:

counter = 0
count = input("type '1' to increment.")
if count == '1':
    counter = counter + 1
if counter < 5:
    print("keep going. Counter is " + str(counter))
    continue
if counter == 5:
    print("You've reached 5!")
    exit

@34, you were extremely close. Here's how your code should actually look:

while True:
    counter = 0
    # input() returns str, not int
    count = int(input("type '1' to increment."))
    if count == '1':
        counter = counter + 1
    if counter < 5:
        print("keep going. Counter is " + str(counter))
        continue
    if counter == 5:
        print("You've reached 5!")
        break

That's it. You literally only made two errors (forgetting the while loop and not calling input() inside an int() function). Normally when getting input you don't call int(), but you do if you want to get the result back as an integer, since input() does not do this. Same goes for any other type other than str (since input() returns str). Good work!

Ethen, thanks so much for showing me how close I was, that's great. But, it also shows how logical some one must be to program in general-purpose languages.

Now, Arronlp, I don't know how you code your site, but there really needs to be basic formatting, like headings, lists, and things like that where necessary. I know, plain text is great, but, I'd say, markup makes things more readable on the web. For example, if you use Markdown:

## Section 1 – How it works

The GDE allows users to create Sonus Interactive projects on their home computer and export it into a game the Sonus can then process and play.
A project will consist of 2 main components, which are Game Objects and Global Variables.

Developers can use Global Variables to hold the data the entire game needs to access such as the players health or money, complete and incomplete objectives, or perhaps their score.
Game Objects are the functioning components of the game. Each game object consists of 3 things.

1. A list of their own local variables, these are like global variables except they are relative to the game object. Other objects can access this data if the developer intends but once the Game Object is destroyed, its local variables are lost.

2. Properties such as X,Y and Z coordinates and boundary sizes which tell the game how big the Game Object is and how far other Game Objects have to be from it to trigger a collision event (more on events in a moment). It also has a property to tell the game whether the Game Object should loop audio when it plays it or only play it once. The last property is the delay property which tells the Game Object how often it should fire its "Periodical" event.
3. A Game Object has a list of what are called Events. These are things that can influence the Game Object in some way, here is a list of all the Events a Game Object has:...

Free grammar fixes as well. Really, if anyone needs a proofreader, I'll do my best.

Edit: there should also be a link to the next section of the tutorial after you finish reading a lesson.

@37, I see what you mean now.
Let's be realistic and at least both agree that scripting languages are limiting. We agree on that? If so, excellent!
About 23...
I disagree with the real programmer bit -- the first sentence -- because you *do not* need to know all the minute details on how an alert box is created, or how an input box is presented (i.e. every single API call throughout the call chain). Plus, on Windows, that would not only be convoluted, it would be disgusting to even think about. Same for Mac. Linux... maybe I could figure it out given enough time, but its not really something I absolutely need to know unless I'm making my own GUI toolkit.
There is a partial point to be made in his second sentence, though. At least, the first phrase. The rest of it? Not too much.
He says, "There is so much you can't do". Here's where our (hopeful) agreement above comes into play. This is only true if: (1) the language in question is closed-source and the author does not allow "plugins" or (2) the project is open-source but the documentation on extending things is so complicated that no one wishes to attempt it. I disregard BGT because if you want to make "plugins" you need to make ridiculously over-complicated DLL calls. The plugins I'm talking about are the kinds of plugins that are loadable at runtime or that are loaded/directly compiled into the binary and improve the scripting language in one way or another immediately: they might add new functions, enhance the languages syntax or expressiveness, etc. If your using a scripting language like that, the doors of infinite possibilities is blown wide-open because now anything really is possible so long as anyone is willing to implement it for you or you implement it yourself.
I think the ultimate issue that occurs when you bring in a scripting language is the removal of a lot of control from the user of that language. For example, some languages don't allow you to replace their memory management routines, or use garbage collection. If your planning for your game to be available on platforms like the play station or Xbox, then fitting in that extra overhead won't do it (EA published a paper about this very issue in 2005) and so you'll need to remove that from the produced console end product. That's why you can't mod games like GTA V, for example, on consoles. You also don't have the ability to create extremely fast and efficient code with most scripting languages (Lua and Python included) because those languages make copies of literally everything. That, in turn, makes security extremely difficult (i.e. cryptography) because the last thing you do before you've concluded a cryptographic operation is to wipe all sensitive data from memory. Languages like Lua and Python prohibit this simple action and make it far harder to do.
The memory management issue is present in some programming languages too (i.e. the C++ standard library has this problem) but is mitigated by the fact that you can easily replace it. EA went ahead and just created alternatives to all the items they needed and have used that, I think, ever since. Unlike a scripting language though, a programming language gives you that "extra edge" you need and allow you to keep a single copy of all your data around instead of hundreds to thousands (unless its Python mind). There may be scripting languages that do this too; if there are, I don't know of any. So my point earlier still holds; textual programming gives you the extra control and power you need that just cannot be expressed via visual tools very well. Plus, you can then use the decades of tools that have been created to operate on text. (Why do you think the command-line will be so popular and be considered more powerful than the graphical alternative by many people even in the next 30-50 years? The CLI ain't going anywhere, and its not because its an ancient fossil and is there for historical purposes even if some would like you to believe that.)
Really, what this long post boils down to is this.
(1) closed source scripting languages that do not allow any kind of plug-in are extremely restrictive, no matter what form they're in. Open-source ones are usually the opposite, unless extending them is so hard that no one is willing to actually do it.
(2) Textual programming is the most comfortable form of expressiveness for most of the programmers on the planet because they are far more comfortable with it and are far more productive. They hate using the mouse, or are unable to use the mouse, and don't want to have to click buttons, use menu bars, and so on, just to get somethign simple done that could've been done in text in about 10 seconds.

@41, did you know? Python runs on microcontrollers. Also, check out Go. Can't be used for making audio games quite yet but still a fun language to use!

@Ethin. I fully agree with you that scripting languages are limiting, but it's their very nature that constricts users to those limitations, and that very nature I think makes certain limitations acceptable. In this case, for example, I'm only interested in creating a specific style or subsect of games, and so maybe I don't need the language to support multithreading to handle multiple objects doing multiple functions at once. More fitting to the example at hand, since the GDE is designed to make games expressly for the Sonus console, I don't need to worry about Windows RAM concerns etc, since I assume that these memory concerns won't exist in the console because of base code in the device to handle memory cleanup.
I think we have to remind ourselves of that fact first. The language isn't designed to make games for Windows computers. It's designed to make games for a self-contained gaming console, and we aren't talking about portability here -- it's meant for the Sonus console, which means that (to my knowledge) we're not really interested in porting to other platforms such as Playstation, Xbox, etc.
I sort of think of these scripting languages like grown-up legos. I get all the building blocks I need to make something awesome to play and work with, and yet I don't need a full-fledged wood shop, welding shop, or plastics shop -- I have panels and parts provided in varying sizes and configurations, enough for me to make things. sure it means I might not be able to make a car to my exact specifications, but I can put together a car from prefab parts that runs and does what I need it to do. Maybe my house that I build doesn't have custom stained glass windows or crystal chandeliers, but I can build a house from the prefab parts that I can live in and even show off to my friends, since I can build that house in different configurations and apply my own paint jobs, wall paper, decorations, furniture, etc.
I will never claim a game scripting language doesn't have limitations, but I do think any limitations it has are probably suitable for the nature of the beast -- I'm ok not being able to use the Sonus language to create another programming language, for example, because I know that isn't the intent of the language in the first place.

Kai

So guys, I'm not a very good programmer. Well, in a sense. I write or contribute to libraries sometimes, and then don't use what I write most of the time - for fear that it will limit me. When I first started in with Python, I wrote a menu class for audio games - and then what did I do? Turned around and wrote menu functions by hand because I encountered no more than 2 situations wherein very specific items needed very specific controls to manipulate them, or in fact very specific conditions to even exist in the first place. I also needed my menu to step aside and let another function call real quick, then step right back up and use that data, while saving the user's position.
Long winded example, but sufficient. I refused to use *my own* menu class because I felt it was too constrictive, for not letting me design a unique infrastructure each time. I have commitment issues. That is why I don't use the GDE to develop things like, say, Scramble, even though barring the operations that require saving/loading character data, it could be done. I messed with the GDE a bit and didn't find any file operations, but I may be wrong?
Not everyone's me though. I'm however also not CarterTemm or Sam.Tupy1 -- they don't just code games in a language, they get deep in that thing and mess with some real low level stuff. I don't expect to know all the intricate details of the Python packaging system, Cython, and Pyinstaller. The people using the GDE also don't expect to create and sell Scramble for Windows and hopefully Mac.
The other night, I wrote a function that took 5 minutes. Then, I saved the wrong version of my file because I didn't know I had two instances of it open, and lost that function. So in a fit of rage and annoyance, I got off my ass and learned how to use Git Hub and the command line Git, pausing a coding session right then and there. So especially right now I could lecture about the greatness of Python and oh my God Git, and it wouldn't be me trying to be elitist, just eager to show people what I feel and a lot of others do as well to be an extremely awesome way of doing things. Also that maybe I don't have commitment issues. However, if you're using the GDE and it works for you, right on my brudda. As long as you're not inserting carcinogens in my water supply, you have no quarrel with me. Best of luck, and I look forward to trying those games if possible!

I'm getting a lot with the GDE figured out with the help of Aaron. In fact. we have ways to make certain menu options disappear till they get unlocked. We're working on creating a quest system at the moment. So, I feel that the GDE does have quite a lot going for it and that you can do a lot with it even though it is just an interface system and not a language.