Re: [blind-gamers] bgt exclude components

[Justin Jones]

I would also be interested in knowing if there is a good briding
language away from BGT. BGT is working for our purposes at the moment,
but thinking/planning ahead, I can see where BGT will start to fail
us.

On 8/25/17, Damien Sykes-Lindley  wrote:
> Hi John,
> I will reply to you off list, as we are straying away from gaming here.
> Cheers.
> Damien.
>
>
> From: john
> Sent: Thursday, August 24, 2017 3:29 PM
> To: blind-gamers@groups.io
> Subject: Re: [blind-gamers] bgt exclude components
>
> Hi Damien,
> Well said on all counts.
> I'm in about the same position; I'd like to move to something with more
> features and support, but BGT does so many of the little things so easily
> its difficult to not look for ways around the engine's limitations (getting
> drive information via wmic and batchfiles rather than built-in calls, for
> example). I've also been struggling to find anything that compiles down to
> executables easily (java's special at best, python files are huge and have
> to decompress themselves, C is... C).
> Have you had any luck finding a language that can bridge the gap at all?
> Best,
> John
>
>
> From: Damien Sykes-Lindley
> Sent: Wednesday, August 23, 2017 16:22
> To: blind-gamers@groups.io
> Subject: Re: [blind-gamers] bgt exclude components
>
> Hi John,
> I’m afraid there are no public updates to BGT at the moment. To be honest
> until I hear any different I’m treating it more or less as a dying
> language.
>
> There has actually been an entire topic on Twitter today regarding the
> suitability of BGT, and I’ll say here, albeit more detailed, what I said
> there. BGT has its place. But it also has its limits.
>
> BGT is very good for creating 2d-based audiogames while being friendly for
> beginners in the process.
> BGT is not good for general purpose applications. Its speed isn’t optimised
> for it, neither is its size. Most importantly, its library support is
> extremely basic, meaning that in order to use a good 95% of available
> libraries with BGT, they would need separate wrapper libraries.
>
> When I first started to learn game programming, I started with VB6. While
> that was considered a programming language, it was still very much a limited
> environment. Tutorials were becoming scarce, examples low on the ground, and
> the language itself was dying out thanks to the introduction of the .NET
> platforms. Even DirectX needed it’s own VB-compatible DLL, hence the reason
> many users are struggling to play older games on Windows 7, 8, or 10.
>
> Believe it or not, my journey with VB6 came to an unceremonious finality
> during the beta testing phase of BGT. From that moment on, anything I wanted
> to do was done using BGT.
>
> So, to clarify. I started with VB6 (a COM/OLE/ActiveX environment), tinkered
> with AutoIt (a UI automation scripting language which also tried its best to
> serve a general-purpose environment but was far too specifically designed to
> do so efficiently), then moved house to BGT (a gaming platform).
>
> As much as some people may class these as programming, to me they are very
> much scripting. All sandbox environments, limited functionality, very
> specific purposes, and encouraging software development management skills
> which are not generally encouraged in general programming.
>
> It’s unfortunate, but a lot of people go through one of two phases: Either
> they switch to a general purpose language rather quickly, realise how much
> better it is, and come to despise the scripting languages they learned as
> introductory tools, or they treat it with unrestrained reverence, use them
> forever and a day, and become so reliant on these scripting alternatives
> that nothing else matters to them, to the point that they will even attempt
> to push these languages far beyond the boundaries of perhaps even twice
> their limits.
>
> I’m not saying that anyone on this list is at one phase or the other.
> Personally, I’m stuck sitting on the fence. I realise how much better
> general purpose programming languages are, in terms of speed and size
> optimisations. But the sheer size and the tasks that are either possible or
> mandatory with these languages I find all too overwhelming, to the point
> that sometimes finding libraries and compiling them can be a challenge in
> itself, without the extra coding and debugging.
>
> So while I appreciate some of the benefits of many general purpose
> languages, I have myself become all too reliant on the sandbox environment,
> having used it for the past 16 years. As a consequence, pointers, handles,
> data structures and callbacks on the coding end, and version control,
> package managers, bug trackers, unit testing, automated building and
> dedicated debuggers on the software engineering end, have only entered my
> programming world very recently – a sad situation for any application, games
> included.
>
> So, the upshot. If you know for an absolute 100% certainty that you only
> want to 

Re: [blind-gamers] bgt exclude components

[Damien Sykes-Lindley]

Hi John,
I will reply to you off list, as we are straying away from gaming here.
Cheers.
Damien.


From: john 
Sent: Thursday, August 24, 2017 3:29 PM
To: blind-gamers@groups.io 
Subject: Re: [blind-gamers] bgt exclude components

Hi Damien,
Well said on all counts.
I'm in about the same position; I'd like to move to something with more 
features and support, but BGT does so many of the little things so easily its 
difficult to not look for ways around the engine's limitations (getting drive 
information via wmic and batchfiles rather than built-in calls, for example). 
I've also been struggling to find anything that compiles down to executables 
easily (java's special at best, python files are huge and have to decompress 
themselves, C is... C).
Have you had any luck finding a language that can bridge the gap at all?
Best,
John


From: Damien Sykes-Lindley 
Sent: Wednesday, August 23, 2017 16:22
To: blind-gamers@groups.io 
Subject: Re: [blind-gamers] bgt exclude components

Hi John,
I’m afraid there are no public updates to BGT at the moment. To be honest until 
I hear any different I’m treating it more or less as a dying language.

There has actually been an entire topic on Twitter today regarding the 
suitability of BGT, and I’ll say here, albeit more detailed, what I said there. 
BGT has its place. But it also has its limits.

BGT is very good for creating 2d-based audiogames while being friendly for 
beginners in the process.
BGT is not good for general purpose applications. Its speed isn’t optimised for 
it, neither is its size. Most importantly, its library support is extremely 
basic, meaning that in order to use a good 95% of available libraries with BGT, 
they would need separate wrapper libraries.

When I first started to learn game programming, I started with VB6. While that 
was considered a programming language, it was still very much a limited 
environment. Tutorials were becoming scarce, examples low on the ground, and 
the language itself was dying out thanks to the introduction of the .NET 
platforms. Even DirectX needed it’s own VB-compatible DLL, hence the reason 
many users are struggling to play older games on Windows 7, 8, or 10.

Believe it or not, my journey with VB6 came to an unceremonious finality during 
the beta testing phase of BGT. From that moment on, anything I wanted to do was 
done using BGT.

So, to clarify. I started with VB6 (a COM/OLE/ActiveX environment), tinkered 
with AutoIt (a UI automation scripting language which also tried its best to 
serve a general-purpose environment but was far too specifically designed to do 
so efficiently), then moved house to BGT (a gaming platform).

As much as some people may class these as programming, to me they are very much 
scripting. All sandbox environments, limited functionality, very specific 
purposes, and encouraging software development management skills which are not 
generally encouraged in general programming.

It’s unfortunate, but a lot of people go through one of two phases: Either they 
switch to a general purpose language rather quickly, realise how much better it 
is, and come to despise the scripting languages they learned as introductory 
tools, or they treat it with unrestrained reverence, use them forever and a 
day, and become so reliant on these scripting alternatives that nothing else 
matters to them, to the point that they will even attempt to push these 
languages far beyond the boundaries of perhaps even twice their limits.

I’m not saying that anyone on this list is at one phase or the other. 
Personally, I’m stuck sitting on the fence. I realise how much better general 
purpose programming languages are, in terms of speed and size optimisations. 
But the sheer size and the tasks that are either possible or mandatory with 
these languages I find all too overwhelming, to the point that sometimes 
finding libraries and compiling them can be a challenge in itself, without the 
extra coding and debugging.

So while I appreciate some of the benefits of many general purpose languages, I 
have myself become all too reliant on the sandbox environment, having used it 
for the past 16 years. As a consequence, pointers, handles, data structures and 
callbacks on the coding end, and version control, package managers, bug 
trackers, unit testing, automated building and dedicated debuggers on the 
software engineering end, have only entered my programming world very recently 
– a sad situation for any application, games included.

So, the upshot. If you know for an absolute 100% certainty that you only want 
to concentrate on audiogames, and 2d-based audiogames at that, BGT is a good 
option. However if you feel you also want to branch out into end product 
optimisation, 3d-based audio, environmental effects, general purpose 
applications etc, I would give the advice to skip the scripting stage and go 
straight to learning general programming and software engineering concepts.
As far as I’m concerned, scripting 

Re: [blind-gamers] bgt exclude components

[john]

Hi Aaron,
They're only  megabyte, sure. That adds up when you're like me and have about 
30 different one-purpose projects, and create new ones weekly.
For example, I wrote a program to count up and display some statistics about 
sourcecode files, and since I wanted it on my explorer context menu, it needs 
to be compiled. This causes about a 400 fold increase in size, and while I'd 
love to port it to C (which would drop the file to about 40 or 50kb and let it 
run on all systems), I can't find a way to track the program's calculation time 
or display a simple message box (C noob here).
Thus my question here, since I really don't like having loads of redundant data 
everywhere.

Best,
John


From: valiant8086 
Sent: Wednesday, August 23, 2017 13:41
To: blind-gamers@groups.io 
Subject: Re: [blind-gamers] bgt exclude components


Hi.




Not that I know of, but one thought that does come to mind is that the 
executables are only a megabyte or so anyway, does that actually pose a problem 
at all?







Cheers:
Aaron Spears, A.K.A. valiant8086. General Partner - Valiant Galaxy Associates 
"We make Very Good Audiogames for the blind community - 
http://valiantGalaxy.com;

On 8/23/2017 12:54 PM, john wrote:

  Hi list,
  I've recently been trying to find ways to reduce the size of BGT executables. 
Specifically, I'm looking to exclude unused sections of the engine during 
compiletime; for example, if I'm writing a program to work entirely offline, 
then there's no need to include the network subsystem. Does anybody know if 
something like this is possible?
  I write a lot of small, single-purpose applications that don't need many 
features, so it'd be really useful to trim them down to size, per say.

  Best,
  John

Re: [blind-gamers] bgt exclude components

[john]

Hi Damien,
Well said on all counts.
I'm in about the same position; I'd like to move to something with more 
features and support, but BGT does so many of the little things so easily its 
difficult to not look for ways around the engine's limitations (getting drive 
information via wmic and batchfiles rather than built-in calls, for example). 
I've also been struggling to find anything that compiles down to executables 
easily (java's special at best, python files are huge and have to decompress 
themselves, C is... C).
Have you had any luck finding a language that can bridge the gap at all?

Best,
John


From: Damien Sykes-Lindley 
Sent: Wednesday, August 23, 2017 16:22
To: blind-gamers@groups.io 
Subject: Re: [blind-gamers] bgt exclude components


Hi John,
I’m afraid there are no public updates to BGT at the moment. To be honest until 
I hear any different I’m treating it more or less as a dying language.

There has actually been an entire topic on Twitter today regarding the 
suitability of BGT, and I’ll say here, albeit more detailed, what I said there. 
BGT has its place. But it also has its limits.

BGT is very good for creating 2d-based audiogames while being friendly for 
beginners in the process.
BGT is not good for general purpose applications. Its speed isn’t optimised for 
it, neither is its size. Most importantly, its library support is extremely 
basic, meaning that in order to use a good 95% of available libraries with BGT, 
they would need separate wrapper libraries.

When I first started to learn game programming, I started with VB6. While that 
was considered a programming language, it was still very much a limited 
environment. Tutorials were becoming scarce, examples low on the ground, and 
the language itself was dying out thanks to the introduction of the .NET 
platforms. Even DirectX needed it’s own VB-compatible DLL, hence the reason 
many users are struggling to play older games on Windows 7, 8, or 10.

Believe it or not, my journey with VB6 came to an unceremonious finality during 
the beta testing phase of BGT. From that moment on, anything I wanted to do was 
done using BGT.

So, to clarify. I started with VB6 (a COM/OLE/ActiveX environment), tinkered 
with AutoIt (a UI automation scripting language which also tried its best to 
serve a general-purpose environment but was far too specifically designed to do 
so efficiently), then moved house to BGT (a gaming platform).

As much as some people may class these as programming, to me they are very much 
scripting. All sandbox environments, limited functionality, very specific 
purposes, and encouraging software development management skills which are not 
generally encouraged in general programming.

It’s unfortunate, but a lot of people go through one of two phases: Either they 
switch to a general purpose language rather quickly, realise how much better it 
is, and come to despise the scripting languages they learned as introductory 
tools, or they treat it with unrestrained reverence, use them forever and a 
day, and become so reliant on these scripting alternatives that nothing else 
matters to them, to the point that they will even attempt to push these 
languages far beyond the boundaries of perhaps even twice their limits.

I’m not saying that anyone on this list is at one phase or the other. 
Personally, I’m stuck sitting on the fence. I realise how much better general 
purpose programming languages are, in terms of speed and size optimisations. 
But the sheer size and the tasks that are either possible or mandatory with 
these languages I find all too overwhelming, to the point that sometimes 
finding libraries and compiling them can be a challenge in itself, without the 
extra coding and debugging.

So while I appreciate some of the benefits of many general purpose languages, I 
have myself become all too reliant on the sandbox environment, having used it 
for the past 16 years. As a consequence, pointers, handles, data structures and 
callbacks on the coding end, and version control, package managers, bug 
trackers, unit testing, automated building and dedicated debuggers on the 
software engineering end, have only entered my programming world very recently 
– a sad situation for any application, games included.

So, the upshot. If you know for an absolute 100% certainty that you only want 
to concentrate on audiogames, and 2d-based audiogames at that, BGT is a good 
option. However if you feel you also want to branch out into end product 
optimisation, 3d-based audio, environmental effects, general purpose 
applications etc, I would give the advice to skip the scripting stage and go 
straight to learning general programming and software engineering concepts.
As far as I’m concerned, scripting languages are hinkypunks. They lure you into 
a false sense of security and then watch heartlessly while you’re dragged down 
by the realisation that programming isn’t as simple as scripting makes it out 
to be.
Cheers.
Damien.