SyntaxBomb - Indie Coders

What is good about Blitz?

Well it has to be ease of use, right? It's very easy to do what you want without having to worry about the deep technical side of stuff; this is especially true for 3D graphics.

What is bad about Blitz*? It's outdated; it's old and it has a lot of features that would be great nowadays. It's not easily configurable and there's no templates for game data.

Well, why not Unity? Unity is modern, but it just feels so overbearing; you can't use basic C# language features such as partial classes and they've replaced the entire API seemingly for shits and giggles.

I've pondered this problem for a good few years now; I eventually decided that - as I have more time than sense and a natural habit for overengineering - to just tell the established solutions to go fuck themselves and write my own engine.

Say hello to Emerald and the ESX scripting language.

Everything is XML. All of a game is defined in XML; from objects to AI definitions to audio and video (although the latter two are mostly unimplemented in the current builds). The ESX scripting language combines C-like syntax with the ease of use of Blitz's command system. Rendering is powered by SDL2 (the engine actually started as a research game for WPF, but is currently being substantially retrofitted to use a sane renderer).

Currently only the commands are implemented, but this is what the language will look like when complete:


ObjIdToInsert = 0;

ValidObjIds = GetGlobalObjCount;

if (ObjIdToInsert > ValidObjIds)
{
   ThrowRuntimeError id:71 text:"Attempted to insert invalid object"
}


Images





Plans
Once the engine is fully ported to SDL2 rendering, refactoring has been done, the full ESX feature set implemented, deprecated features removed, and generally cleaned up a lot, a version 0.1 release will be pushed. This will include preliminary documentation and a limited feature set of the engine, and will be designed for testing only. This release is currently scheduled for some time in mid-2021. Features will be added gradually from then on.

Feedback is welcome! I would especially like feedback on the syntax of the language; a more detailed document will be published when I write it. Should it be more BASIC-like?

node names are UpperCamelCase/PascalCase. Attributes are... "alllowercase".
I would use "lowerCamelCase" for attributes/elements ...


<Player>
  <Image pathRelative="true" />
</Player>



Maybe also show how interaction is done ... so how do your scripts load eg an XML as template to instantiate objects or so.


How do you plan to support developers creating the XML files ...

bye
Ron

> Attributes are... "alllowercase".
The attribute stuff is from an earlier revision; everything is going to be replaced with PascalCase stuff as that's .NET standard practice. What would be the benefit of camelCase in your view?

> Maybe also show how interaction is done ... so how do your scripts load eg an XML as template to instantiate objects or so.
XML files aren't loaded by the scripts themselves. The engine loads the XML at init.

When you do, for example:
InsertObject id:1 x:100 y:100
the engine simply inserts the object (that was previously loaded from the game-specific object XML) from a global object list. No loading is done by the XML.

> How do you plan to support developers creating the XML files ...
Eventually there will be an IDE. This will allow creation of objects. The XML file elements will be represented in a propertygrid.

camelCase - personal preference.
MyPlayer.MyAttribute
vs
MyPlayer.myAttribute

This often comes in conjunction with "methods/functions" being PascalCase too. Especially if getters/setters can have the same name as the variable (so case sensitive languages).


bye
Ron

Currently working on the scripting system and removing the old WPF code. I recently got a messagebox API working and am going to expose it to scripts. Also keyboard input stuff and refactoring the scripting system to remove duplicate code.

Also, I see Derron.

Quote from: Cosmo on February 27, 2021, 13:07:40
What is good about Blitz?

Well it has to be ease of use, right? It's very easy to do what you want without having to worry about the deep technical side of stuff; this is especially true for 3D graphics.

What is bad about Blitz*? It's outdated; it's old and it has a lot of features that would be great nowadays. It's not easily configurable and there's no templates for game data.

Feedback is welcome! I would especially like feedback on the syntax of the language; a more detailed document will be published when I write it. Should it be more BASIC-like?

Hi,

I hope your Emerald game Engine is aimed at beginners as well.

Im a Hobby programmer and would like to write games. I have written a Zx Spectrum Emulator in Blitmax 1.5 95% working.

I use BlitzMax 1.5 Because it has one .ExE file to install it and get working. Using any kind of modules and other linked librarys should be in the ExE with nothing else to do.

There must be lot's of Example's on how to use the Syntax. Good worked example's are a must for a beginner learner.

Stick with a BasicMax 1.5 syntax as closely as possible, it's kinda easy to read and understand C Just isn't. Keeping away from sqiggly brackets and symbols is a must. It make's code easy to read after being away from your code for a while. Let the compiler add these when compiled or needed.

The Blitzmax forum is still popular with coders so it's still being used as it's easy to use and more easily to read and understand.
May be make your game engine into an Exe that load's into Blitmax. So it can be used straight away.

Ive tried Love, Unity, Purebasic, AGK, Monkey and use Blitmax.

Blitzmax 1.5 is also compiled to a very fast speed.

Quote
Keeping away from sqiggly brackets and symbols is a must. It make's code easy to read after being away from your code for a while.

As long as you don't go mad with symbols, personally I prefer a 1 character symbol to begin and end a block of code.  Because when you don't use words for those things too (you use a symbol) your code 'pops', blocks of code stand out from the other language words so you can see the make up of a program more clearly IMO.

Braces or keywords, makes no difference if you ask me, horses for courses... Though, in a "bracket" language, I do tend to create little scope blocks with them, get the result of whatever I'm doing in there, and when it gets to the end of the block, any variables I've made up drop out of scope and gone, thus, in my opinion, keeps the code a bit cleaner as you havent got redundant variables floating about... when I do that, I sorta think about that as a little container, something that doesnt warrant a jump to a function... Yes, I could use inline, which is fine when your compiling, but in source, the execution is there in front of me, so... Saves going back and forth too.

But, like I said, horses for courses innit!

Dabz

Quote
Though, in a "bracket" language, I do tend to create little scope blocks with them, get the result of whatever I'm doing in there, and when it gets to the end of the block, any variables I've made up drop out of scope and gone, thus, in my opinion, keeps the code a bit cleaner as you havent got redundant variables floating about.

Ooo not sure about that mate, maybe I'm misunderstanding what you're doing.  Having variables all over the place can be a nightmare to return too later.  Variables at the beginning of a class seems fine, variables at the beginning of each function within that class fine, you can see what's about to be used (each class and function shouldn't be massive though, that's so important).  But just producing scope blocks all over the place then you can be too clever for your own good and make debugging a nightmare.

Quote
But just producing scope blocks all over the place then you can be too clever for your own good and make debugging a nightmare.

Not really, you cannot have variables all over if they are contained in a scope block, no different then creating a function to test a bit of algo, they are created in there, and die once execution is finished, so any reference to them below shouldn't happen, the compiler will point to anything "unjust" so to speak... I just get a result out of it that's all and if the block is big enough, and I'm happy, then it will be shuffled over to a function/class member anyway... It's just for source code level handiness most part.

But it's a feature, a tool and I choose to use it sometimes, and, well... I've never had a problem, so there is no problem.

Dabz

Hello.
When will you have the first version ready to test?
Will it be supported by software and direct 3d or only by opengl?
Will there be online documentation ?, I ask because if it is online it can be translated with the google translator.