Topics

accessible game engine

Marvin Hunkin
 

Hi. Well doing my course interactive gaming and digital media from http://www.upskilled.edu.au, and now. Any tips, tricks for unity, unreal, stensil, construct, and harmony. Any tips, tricks, work arounds. Accessibility settings.

Thanks.

Ps: also for the unreal game engine as well. Or can I use the unity project templates in visual studio 2017 community. Well might have to google and see if there’s any unreal game project templates for visual studio.

Thanks.

Marvin from Adelaide, Australia.


Virus-free. www.avast.com

Josh Kennedy
 

You could use BGT blind game maker toolkit, from BlastBay studios. It's free. 

Damien Garwood
 

Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn’t indicative of real world programming. Once you realise BGT’s limitations and want to move away from it, it’s much harder to do so because you end up relying on it. Especially if you’re a programming newbie and don’t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won’t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.
 

Sent: Sunday, February 18, 2018 2:54 PM
Subject: Re: [blind-gamers] accessible game engine
 
You could use BGT blind game maker toolkit, from BlastBay studios. It's free. 

john
 

Agreed here, with sadness.
I've written a lot more software in bgt than I have games, and I hit those limits a lot. Its frustrating, because the engine is so amazingly good at what it does do that you really want to keep using it. The problem is that it works in a sort of walled garden; anything outside its limits is entirely unreachable to the programmer (multithreading, binary file support, other sound formats, libraries, braille support and worst of all advanced data structures).

Sent: Sunday, February 18, 2018 10:11
Subject: Re: [blind-gamers] accessible game engine

Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn’t indicative of real world programming. Once you realise BGT’s limitations and want to move away from it, it’s much harder to do so because you end up relying on it. Especially if you’re a programming newbie and don’t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won’t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.
 
Sent: Sunday, February 18, 2018 2:54 PM
Subject: Re: [blind-gamers] accessible game engine
 
You could use BGT blind game maker toolkit, from BlastBay studios. It's free. 

 

Yeah, and because of how its written its detected by antivirus as a problem.

I mean the antivirus makers do target the blind anyway because they want us to suffer but bgt well its old and the the way it handles stuff aint supposed to be that good at least if the file is compiled.

On 19/02/2018 4:11 a.m., Damien Garwood wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn’t indicative of real world programming. Once you realise BGT’s limitations and want to move away from it, it’s much harder to do so because you end up relying on it. Especially if you’re a programming newbie and don’t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won’t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's free.

Rynhardt Kruger
 

The BGT argument is one I have scene a few times on this list now. It seams what we need then is all the functions of BGT wrapped up in a nice platform independent library. It could be written in something like portable C, with all the platform dependent stuff in platform specific modules, and bindings for different languages generated with Swig or something. Swig is quite good at generating bindings for many programming languages.

Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt

On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood <damien@...> wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn’t indicative of real world programming. Once you realise BGT’s limitations and want to move away from it, it’s much harder to do so because you end up relying on it. Especially if you’re a programming newbie and don’t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won’t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.
 
Sent: Sunday, February 18, 2018 2:54 PM
Subject: Re: [blind-gamers] accessible game engine
 
You could use BGT blind game maker toolkit, from BlastBay studios. It's free. 

Damien Garwood
 

Hi,
Even if that were the case, it would still have its audio limitations, HTTPS crashes and UDP-only networking. So we would still end up having to ransack the internet just to find something decent. But yeah. I could certainly use the pathfinder, calendar, timer, tone synth, input-related functions etc as a library. That would be neat indeed. I mean, programmers often stress the brilliance of code reuse, right?
Cheers.
Damien.
 

Sent: Monday, February 19, 2018 11:00 AM
Subject: Re: [blind-gamers] accessible game engine
 
The BGT argument is one I have scene a few times on this list now. It seams what we need then is all the functions of BGT wrapped up in a nice platform independent library. It could be written in something like portable C, with all the platform dependent stuff in platform specific modules, and bindings for different languages generated with Swig or something. Swig is quite good at generating bindings for many programming languages.
 
Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt
 
On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood <damien@...> wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn’t indicative of real world programming. Once you realise BGT’s limitations and want to move away from it, it’s much harder to do so because you end up relying on it. Especially if you’re a programming newbie and don’t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won’t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.
 
Sent: Sunday, February 18, 2018 2:54 PM
Subject: Re: [blind-gamers] accessible game engine
 
You could use BGT blind game maker toolkit, from BlastBay studios. It's free. 
 

Oriol Gómez
 

Hi.
You can look around on the network for a pathfinder, there are tons.

as for input, 2d and 3d audio, we have javascript libraries that might
help with all this. They can of course be ported to other languages.

Cheers.

On 2/19/18, Damien Garwood <damien@...> wrote:
Hi,
Even if that were the case, it would still have its audio limitations, HTTPS
crashes and UDP-only networking. So we would still end up having to ransack
the internet just to find something decent. But yeah. I could certainly use
the pathfinder, calendar, timer, tone synth, input-related functions etc as
a library. That would be neat indeed. I mean, programmers often stress the
brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It seams
what we need then is all the functions of BGT wrapped up in a nice platform
independent library. It could be written in something like portable C, with
all the platform dependent stuff in platform specific modules, and bindings
for different languages generated with Swig or something. Swig is quite good
at generating bindings for many programming languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn’t indicative of real world programming. Once you realise BGT’s
limitations and want to move away from it, it’s much harder to do so because
you end up relying on it. Especially if you’re a programming newbie and
don’t have a clue how to write audio engines, let alone audio engines that
can play multiple file types, whether packed or on disk, whether encrypted
or open. Not to mention keyboard, mouse, joystick support, screenreader and
SAPI support, timers, pathfinders, combination generators and calendars. The
way I see it, scripting with something like BGT is like having an
overprotective clingy parent that just won’t let go, whereas programming
something like C++ or Python wants you to bend down and kiss its furry rosy
smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.

Jude DaShiell
 

No you wouldn't, just add stuff to the library that clear the crashes and make the whole library better over time. The stuff from bgt could be a sbase then build on that base. Sounds like a long-term project for a team of programmers totaling more than one. Best not put a team like that together until all candidates have done a few fishing trips together to figure out who is and is not compatible enough to work together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:
Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine
Hi,
Even if that were the case, it would still have its audio limitations, HTTPS crashes and UDP-only networking. So we would still end up having to ransack the internet just to find something decent. But yeah. I could certainly use the pathfinder, calendar, timer, tone synth, input-related functions etc as a library. That would be neat indeed. I mean, programmers often stress the brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It seams what we need then is all the functions of BGT wrapped up in a nice platform independent library. It could be written in something like portable C, with all the platform dependent stuff in platform specific modules, and bindings for different languages generated with Swig or something. Swig is quite good at generating bindings for many programming languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood <damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn?t indicative of real world programming. Once you realise BGT?s limitations and want to move away from it, it?s much harder to do so because you end up relying on it. Especially if you?re a programming newbie and don?t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won?t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's free.

--

Damien Garwood
 

Hi,
Oh, I thought you meant have BGT as a library. If you're talking about building a whole new library from scratch, obviously that would take a lot of time, effort, and advanced programming expertise. Given that I've made a resolution to try to switch to C++ and I can't even do a basic timer yet...Let's just say that I'm currently feeling way beyond my depths when it comes to managing memory and threads, so I'm a complete alien when it comes to writing audio engines and looking for pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you think, since JavaScripts does a lot of the deep memory process for you to start with. There also seems to be a few different JS dialects, like Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming languages than BGT, either because of work or programming classes etc, will more or less know everything they need to to learn any language and get along well with it.
Considering I spent the better part of five years parroting from VB6 and AutoIt code to get something workable without actually understanding anything, then actually being able to understand BGT to such a point that I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can write a library that can do that for me. Hello multithreading, streams and buffers, dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons. Run blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh, and we're not going to tell you how to do this in Windows because we're Unix geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all its resources in one application and could compile in a similar manner, including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and writing a C++ wrapper, there is no chance of porting my literally dozens of BGT modules straight over to C++ and have it work. That would just be too much to ask.
So. Looks like I have a twenty year headache sentence ahead of me while I learn, or at least attempt to learn, as much technical crap as I can possibly retain in what I currently feel is a rather small and inadequate brain, and then try to somehow port this mess over.
Cheers.
Damien.

-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project for
a team of programmers totaling more than one. Best not put a team like
that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:

Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi,
Even if that were the case, it would still have its audio limitations, HTTPS crashes and UDP-only networking. So we would still end up having to ransack the internet just to find something decent. But yeah. I could certainly use the pathfinder, calendar, timer, tone synth, input-related functions etc as a library. That would be neat indeed. I mean, programmers often stress the brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It seams what we need then is all the functions of BGT wrapped up in a nice platform independent library. It could be written in something like portable C, with all the platform dependent stuff in platform specific modules, and bindings for different languages generated with Swig or something. Swig is quite good at generating bindings for many programming languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood <damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It also isn?t indicative of real world programming. Once you realise BGT?s limitations and want to move away from it, it?s much harder to do so because you end up relying on it. Especially if you?re a programming newbie and don?t have a clue how to write audio engines, let alone audio engines that can play multiple file types, whether packed or on disk, whether encrypted or open. Not to mention keyboard, mouse, joystick support, screenreader and SAPI support, timers, pathfinders, combination generators and calendars. The way I see it, scripting with something like BGT is like having an overprotective clingy parent that just won?t let go, whereas programming something like C++ or Python wants you to bend down and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's free.

--

john
 

Our other hope is that an update to BGT comes out.
We know (because of VG storm) that some work has been done on it. Maybe
we'll get lucky.

--------------------------------------------------

From: "Damien Garwood" <damien@...>
Sent: Monday, February 19, 2018 10:59
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

Hi,
Oh, I thought you meant have BGT as a library. If you're talking about
building a whole new library from scratch, obviously that would take a lot
of time, effort, and advanced programming expertise. Given that I've made a
resolution to try to switch to C++ and I can't even do a basic timer
yet...Let's just say that I'm currently feeling way beyond my depths when it
comes to managing memory and threads, so I'm a complete alien when it comes
to writing audio engines and looking for pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you
think, since JavaScripts does a lot of the deep memory process for you to
start with. There also seems to be a few different JS dialects, like
Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming languages
than BGT, either because of work or programming classes etc, will more or
less know everything they need to to learn any language and get along well
with it.
Considering I spent the better part of five years parroting from VB6 and
AutoIt code to get something workable without actually understanding
anything, then actually being able to understand BGT to such a point that
I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can write a
library that can do that for me. Hello multithreading, streams and buffers,
dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons. Run
blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh, and
we're not going to tell you how to do this in Windows because we're Unix
geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all its
resources in one application and could compile in a similar manner,
including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and
writing a C++ wrapper, there is no chance of porting my literally dozens of
BGT modules straight over to C++ and have it work. That would just be too
much to ask.
So. Looks like I have a twenty year headache sentence ahead of me while I
learn, or at least attempt to learn, as much technical crap as I can
possibly retain in what I currently feel is a rather small and inadequate
brain, and then try to somehow port this mess over.
Cheers.
Damien.
-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project for
a team of programmers totaling more than one. Best not put a team like
that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:

Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi,
Even if that were the case, it would still have its audio limitations,
HTTPS crashes and UDP-only networking. So we would still end up having to
ransack the internet just to find something decent. But yeah. I could
certainly use the pathfinder, calendar, timer, tone synth, input-related
functions etc as a library. That would be neat indeed. I mean, programmers
often stress the brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It
seams what we need then is all the functions of BGT wrapped up in a nice
platform independent library. It could be written in something like
portable C, with all the platform dependent stuff in platform specific
modules, and bindings for different languages generated with Swig or
something. Swig is quite good at generating bindings for many programming
languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn?t indicative of real world programming. Once you realise BGT?s
limitations and want to move away from it, it?s much harder to do so
because you end up relying on it. Especially if you?re a programming
newbie and don?t have a clue how to write audio engines, let alone audio
engines that can play multiple file types, whether packed or on disk,
whether encrypted or open. Not to mention keyboard, mouse, joystick
support, screenreader and SAPI support, timers, pathfinders, combination
generators and calendars. The way I see it, scripting with something like
BGT is like having an overprotective clingy parent that just won?t let go,
whereas programming something like C++ or Python wants you to bend down
and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.

--

Damien Garwood
 

Hi John,
Even if that were to be the case, BGT is a game engine on top of an interpreted scripting engine. So if, all of a sudden you wanted to be able to make applications as well as games, or large games that need more resources than BGT/AngelScript can handle, or need a lot more speed accuracy than BGT can provide (especially thanks to AngelScript's garbage collector which seems to steal most of a BGT game's valuable time and energy), then you'd be facing the same situation. Trying to switch away from BGT without a clue on how or where to start only to find that you feel tied to it.
While BGT takes 27 seconds to create a 500 by 500 by 500 array, C can do the same thing in less than a second because it's running machine code and you're telling it to directly access memory. Of course it would be a memory hogger, especially if you added sounds with that, and I'm sure there are a lot more optimised ways of making game worlds, but I'm using it as an example of just how much faster alternatives can be. That is of course assuming you know how to use them.
Just goes to show just how much abstract layers can end up slowing something down. I'm nowhere near an expert so don't feel qualified to talk about whether BGT or AngelScript are designed well or have gaping holes and flaws, but assuming AngelScript and BGT are well designed, if a well designed abstract can slow you down, then just imagine how much a poorly designed abstract will worsen it. At least if you work in a compiled language like C or C++, you have a lot more control over that and can fix any design issues with your code if you know what's wrong with them.
Cheers.
Damien.

-----Original Message-----
From: john
Sent: Monday, February 19, 2018 4:28 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Our other hope is that an update to BGT comes out.
We know (because of VG storm) that some work has been done on it. Maybe
we'll get lucky.

--------------------------------------------------
From: "Damien Garwood" <damien@...>
Sent: Monday, February 19, 2018 10:59
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

Hi,
Oh, I thought you meant have BGT as a library. If you're talking about
building a whole new library from scratch, obviously that would take a lot
of time, effort, and advanced programming expertise. Given that I've made a
resolution to try to switch to C++ and I can't even do a basic timer
yet...Let's just say that I'm currently feeling way beyond my depths when it
comes to managing memory and threads, so I'm a complete alien when it comes
to writing audio engines and looking for pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you
think, since JavaScripts does a lot of the deep memory process for you to
start with. There also seems to be a few different JS dialects, like
Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming languages
than BGT, either because of work or programming classes etc, will more or
less know everything they need to to learn any language and get along well
with it.
Considering I spent the better part of five years parroting from VB6 and
AutoIt code to get something workable without actually understanding
anything, then actually being able to understand BGT to such a point that
I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can write a
library that can do that for me. Hello multithreading, streams and buffers,
dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons. Run
blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh, and
we're not going to tell you how to do this in Windows because we're Unix
geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all its
resources in one application and could compile in a similar manner,
including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and
writing a C++ wrapper, there is no chance of porting my literally dozens of
BGT modules straight over to C++ and have it work. That would just be too
much to ask.
So. Looks like I have a twenty year headache sentence ahead of me while I
learn, or at least attempt to learn, as much technical crap as I can
possibly retain in what I currently feel is a rather small and inadequate
brain, and then try to somehow port this mess over.
Cheers.
Damien.
-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project for
a team of programmers totaling more than one. Best not put a team like
that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:

Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi,
Even if that were the case, it would still have its audio limitations,
HTTPS crashes and UDP-only networking. So we would still end up having to
ransack the internet just to find something decent. But yeah. I could
certainly use the pathfinder, calendar, timer, tone synth, input-related
functions etc as a library. That would be neat indeed. I mean, programmers
often stress the brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It
seams what we need then is all the functions of BGT wrapped up in a nice
platform independent library. It could be written in something like
portable C, with all the platform dependent stuff in platform specific
modules, and bindings for different languages generated with Swig or
something. Swig is quite good at generating bindings for many programming
languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn?t indicative of real world programming. Once you realise BGT?s
limitations and want to move away from it, it?s much harder to do so
because you end up relying on it. Especially if you?re a programming
newbie and don?t have a clue how to write audio engines, let alone audio
engines that can play multiple file types, whether packed or on disk,
whether encrypted or open. Not to mention keyboard, mouse, joystick
support, screenreader and SAPI support, timers, pathfinders, combination
generators and calendars. The way I see it, scripting with something like
BGT is like having an overprotective clingy parent that just won?t let go,
whereas programming something like C++ or Python wants you to bend down
and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.

--

 

The bgt concepts are quite old made with directx 8 tech.

Python seems to be the bgt of the future at least it could be, nvda is after all a python 2 application, and it maybe a python3 one.

So if python2 can manage something like a screen reader or python itself then a game should be no problem.

On 20/02/2018 12:00 a.m., Rynhardt Kruger wrote:
The BGT argument is one I have scene a few times on this list now. It seams
what we need then is all the functions of BGT wrapped up in a nice platform
independent library. It could be written in something like portable C, with
all the platform dependent stuff in platform specific modules, and bindings
for different languages generated with Swig or something. Swig is quite
good at generating bindings for many programming languages.

Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt

On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood <damien@...
wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn’t indicative of real world programming. Once you realise BGT’s
limitations and want to move away from it, it’s much harder to do so
because you end up relying on it. Especially if you’re a programming newbie
and don’t have a clue how to write audio engines, let alone audio engines
that can play multiple file types, whether packed or on disk, whether
encrypted or open. Not to mention keyboard, mouse, joystick support,
screenreader and SAPI support, timers, pathfinders, combination generators
and calendars. The way I see it, scripting with something like BGT is like
having an overprotective clingy parent that just won’t let go, whereas
programming something like C++ or Python wants you to bend down and kiss
its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.

*From:* Josh Kennedy <joshknnd1982@...>
*Sent:* Sunday, February 18, 2018 2:54 PM
*To:* blind-gamers@groups.io
*Subject:* Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.


john
 

Python has numerous issues, not the least of which is its huge amount of
overhead and performance.
An example: Sound RTS is written in python. Its an awesome game, but
anything stressful (large maps) bogs down badly.

--------------------------------------------------

From: "Shaun Everiss" <@smeveriss>
Sent: Monday, February 19, 2018 21:09
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

The bgt concepts are quite old made with directx 8 tech.

Python seems to be the bgt of the future at least it could be, nvda is
after all a python 2 application, and it maybe a python3 one.

So if python2 can manage something like a screen reader or python itself
then a game should be no problem.




On 20/02/2018 12:00 a.m., Rynhardt Kruger wrote:
The BGT argument is one I have scene a few times on this list now. It
seams
what we need then is all the functions of BGT wrapped up in a nice
platform
independent library. It could be written in something like portable C,
with
all the platform dependent stuff in platform specific modules, and
bindings
for different languages generated with Swig or something. Swig is quite
good at generating bindings for many programming languages.

Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt

On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...
wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn’t indicative of real world programming. Once you realise BGT’s
limitations and want to move away from it, it’s much harder to do so
because you end up relying on it. Especially if you’re a programming
newbie
and don’t have a clue how to write audio engines, let alone audio engines
that can play multiple file types, whether packed or on disk, whether
encrypted or open. Not to mention keyboard, mouse, joystick support,
screenreader and SAPI support, timers, pathfinders, combination
generators
and calendars. The way I see it, scripting with something like BGT is
like
having an overprotective clingy parent that just won’t let go, whereas
programming something like C++ or Python wants you to bend down and kiss
its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.

*From:* Josh Kennedy <joshknnd1982@...>
*Sent:* Sunday, February 18, 2018 2:54 PM
*To:* blind-gamers@groups.io
*Subject:* Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.


Damien Garwood
 

Hi John,
I initially thought that about Python, until I used NVDA.
Granted, there is a part of NVDA that is programmed in C++, but a good 90% of it is Python-driven, and I don't find it slow in the slightest.
While I do agree that Python programs will naturally be slower due to it being an interpreted language, the majority of slowdowns in applications is your implementation, and I'm sure I remember the SoundRTS developer saying that the implementation could do with a bit of tidying up.
Some interpreters do better than others. AutoIt is slower than BGT, BGT is slower than Python, and Python is apparently 15% slower than straight Assembly.
Cheers.
Damien.

-----Original Message-----
From: john
Sent: Tuesday, February 20, 2018 2:17 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Python has numerous issues, not the least of which is its huge amount of
overhead and performance.
An example: Sound RTS is written in python. Its an awesome game, but
anything stressful (large maps) bogs down badly.

--------------------------------------------------
From: "Shaun Everiss" <@smeveriss>
Sent: Monday, February 19, 2018 21:09
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

The bgt concepts are quite old made with directx 8 tech.

Python seems to be the bgt of the future at least it could be, nvda is
after all a python 2 application, and it maybe a python3 one.

So if python2 can manage something like a screen reader or python itself
then a game should be no problem.




On 20/02/2018 12:00 a.m., Rynhardt Kruger wrote:
The BGT argument is one I have scene a few times on this list now. It
seams
what we need then is all the functions of BGT wrapped up in a nice
platform
independent library. It could be written in something like portable C,
with
all the platform dependent stuff in platform specific modules, and
bindings
for different languages generated with Swig or something. Swig is quite
good at generating bindings for many programming languages.

Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt

On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...
wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn’t indicative of real world programming. Once you realise BGT’s
limitations and want to move away from it, it’s much harder to do so
because you end up relying on it. Especially if you’re a programming
newbie
and don’t have a clue how to write audio engines, let alone audio engines
that can play multiple file types, whether packed or on disk, whether
encrypted or open. Not to mention keyboard, mouse, joystick support,
screenreader and SAPI support, timers, pathfinders, combination
generators
and calendars. The way I see it, scripting with something like BGT is
like
having an overprotective clingy parent that just won’t let go, whereas
programming something like C++ or Python wants you to bend down and kiss
its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.

*From:* Josh Kennedy <joshknnd1982@...>
*Sent:* Sunday, February 18, 2018 2:54 PM
*To:* blind-gamers@groups.io
*Subject:* Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.


 

<grin>

one thing autoit and bgt are both detected as viruses python isn't.

On 20/02/2018 6:57 p.m., Damien Garwood wrote:
Hi John,
I initially thought that about Python, until I used NVDA.
Granted, there is a part of NVDA that is programmed in C++, but a good 90% of it is Python-driven, and I don't find it slow in the slightest.
While I do agree that Python programs will naturally be slower due to it being an interpreted language, the majority of slowdowns in applications is your implementation, and I'm sure I remember the SoundRTS developer saying that the implementation could do with a bit of tidying up.
Some interpreters do better than others. AutoIt is slower than BGT, BGT is slower than Python, and Python is apparently 15% slower than straight Assembly.
Cheers.
Damien.
-----Original Message----- From: john
Sent: Tuesday, February 20, 2018 2:17 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Python has numerous issues, not the least of which is its huge amount of
overhead and performance.
An example: Sound RTS is written in python. Its an awesome game, but
anything stressful (large maps) bogs down badly.

--------------------------------------------------
From: "Shaun Everiss" <@smeveriss>
Sent: Monday, February 19, 2018 21:09
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

The bgt concepts are quite old made with directx 8 tech.

Python seems to be the bgt of the future at least it could be, nvda is
after all a python 2 application, and it maybe a python3 one.

So if python2 can manage something like a screen reader or python itself
then a game should be no problem.




On 20/02/2018 12:00 a.m., Rynhardt Kruger wrote:
The BGT argument is one I have scene a few times on this list now. It
seams
what we need then is all the functions of BGT wrapped up in a nice
platform
independent library. It could be written in something like portable C,
with
all the platform dependent stuff in platform specific modules, and
bindings
for different languages generated with Swig or something. Swig is quite
good at generating bindings for many programming languages.

Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt

On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...
wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn’t indicative of real world programming. Once you realise BGT’s
limitations and want to move away from it, it’s much harder to do so
because you end up relying on it. Especially if you’re a programming
newbie
and don’t have a clue how to write audio engines, let alone audio engines
that can play multiple file types, whether packed or on disk, whether
encrypted or open. Not to mention keyboard, mouse, joystick support,
screenreader and SAPI support, timers, pathfinders, combination
generators
and calendars. The way I see it, scripting with something like BGT is
like
having an overprotective clingy parent that just won’t let go, whereas
programming something like C++ or Python wants you to bend down and kiss
its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.

*From:* Josh Kennedy <joshknnd1982@...>
*Sent:* Sunday, February 18, 2018 2:54 PM
*To:* blind-gamers@groups.io
*Subject:* Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.










john
 

I haven't benchmarked python extensively due to the simple fact I was never
able to get it to easily compile an executable (bgt, hi there).
That said, it really does have a huge amount of overhead, and those python
programmers I've heard discuss it mention that a lot as the major
disadvantage.

--------------------------------------------------

From: "Damien Garwood" <damien@...>
Sent: Tuesday, February 20, 2018 0:57
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

Hi John,
I initially thought that about Python, until I used NVDA.
Granted, there is a part of NVDA that is programmed in C++, but a good 90%
of it is Python-driven, and I don't find it slow in the slightest.
While I do agree that Python programs will naturally be slower due to it
being an interpreted language, the majority of slowdowns in applications is
your implementation, and I'm sure I remember the SoundRTS developer saying
that the implementation could do with a bit of tidying up.
Some interpreters do better than others. AutoIt is slower than BGT, BGT is
slower than Python, and Python is apparently 15% slower than straight
Assembly.
Cheers.
Damien.
-----Original Message-----
From: john
Sent: Tuesday, February 20, 2018 2:17 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Python has numerous issues, not the least of which is its huge amount of
overhead and performance.
An example: Sound RTS is written in python. Its an awesome game, but
anything stressful (large maps) bogs down badly.

--------------------------------------------------
From: "Shaun Everiss" <@smeveriss>
Sent: Monday, February 19, 2018 21:09
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

The bgt concepts are quite old made with directx 8 tech.

Python seems to be the bgt of the future at least it could be, nvda is
after all a python 2 application, and it maybe a python3 one.

So if python2 can manage something like a screen reader or python itself
then a game should be no problem.




On 20/02/2018 12:00 a.m., Rynhardt Kruger wrote:
The BGT argument is one I have scene a few times on this list now. It
seams
what we need then is all the functions of BGT wrapped up in a nice
platform
independent library. It could be written in something like portable C,
with
all the platform dependent stuff in platform specific modules, and
bindings
for different languages generated with Swig or something. Swig is quite
good at generating bindings for many programming languages.

Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?

Rynhardt

On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...
wrote:
Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn’t indicative of real world programming. Once you realise BGT’s
limitations and want to move away from it, it’s much harder to do so
because you end up relying on it. Especially if you’re a programming
newbie
and don’t have a clue how to write audio engines, let alone audio engines
that can play multiple file types, whether packed or on disk, whether
encrypted or open. Not to mention keyboard, mouse, joystick support,
screenreader and SAPI support, timers, pathfinders, combination
generators
and calendars. The way I see it, scripting with something like BGT is
like
having an overprotective clingy parent that just won’t let go, whereas
programming something like C++ or Python wants you to bend down and kiss
its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.

*From:* Josh Kennedy <joshknnd1982@...>
*Sent:* Sunday, February 18, 2018 2:54 PM
*To:* blind-gamers@groups.io
*Subject:* Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.


Zaire Johnson
 

Hay blind-gamers, I’ve been quietly listening to game engine talk for the last two or three days. I think my brain’s gonna explode Lol. All this talk about the guts of building a game. I’m just a gamer who’s surprised that Liam’s not in any of these conversations Lol. Keep creating and could you please make this stuff easier to understand Lol. Laughing at all the technical stuff going on. In closing, I wonder how A heroes Call can be so good and yet you have to remember all that stuff. I was lost long after the first message of this thread.

On Feb 19, 2018, at 11:28 AM, john <jpcarnemolla@...> wrote:

Our other hope is that an update to BGT comes out.
We know (because of VG storm) that some work has been done on it. Maybe
we'll get lucky.

--------------------------------------------------
From: "Damien Garwood" <damien@...>
Sent: Monday, February 19, 2018 10:59
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

Hi,
Oh, I thought you meant have BGT as a library. If you're talking about
building a whole new library from scratch, obviously that would take a lot
of time, effort, and advanced programming expertise. Given that I've made a
resolution to try to switch to C++ and I can't even do a basic timer
yet...Let's just say that I'm currently feeling way beyond my depths when it
comes to managing memory and threads, so I'm a complete alien when it comes
to writing audio engines and looking for pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you
think, since JavaScripts does a lot of the deep memory process for you to
start with. There also seems to be a few different JS dialects, like
Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming languages
than BGT, either because of work or programming classes etc, will more or
less know everything they need to to learn any language and get along well
with it.
Considering I spent the better part of five years parroting from VB6 and
AutoIt code to get something workable without actually understanding
anything, then actually being able to understand BGT to such a point that
I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can write a
library that can do that for me. Hello multithreading, streams and buffers,
dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons. Run
blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh, and
we're not going to tell you how to do this in Windows because we're Unix
geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all its
resources in one application and could compile in a similar manner,
including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and
writing a C++ wrapper, there is no chance of porting my literally dozens of
BGT modules straight over to C++ and have it work. That would just be too
much to ask.
So. Looks like I have a twenty year headache sentence ahead of me while I
learn, or at least attempt to learn, as much technical crap as I can
possibly retain in what I currently feel is a rather small and inadequate
brain, and then try to somehow port this mess over.
Cheers.
Damien.
-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project for
a team of programmers totaling more than one. Best not put a team like
that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:

Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi,
Even if that were the case, it would still have its audio limitations,
HTTPS crashes and UDP-only networking. So we would still end up having to
ransack the internet just to find something decent. But yeah. I could
certainly use the pathfinder, calendar, timer, tone synth, input-related
functions etc as a library. That would be neat indeed. I mean, programmers
often stress the brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It
seams what we need then is all the functions of BGT wrapped up in a nice
platform independent library. It could be written in something like
portable C, with all the platform dependent stuff in platform specific
modules, and bindings for different languages generated with Swig or
something. Swig is quite good at generating bindings for many programming
languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn?t indicative of real world programming. Once you realise BGT?s
limitations and want to move away from it, it?s much harder to do so
because you end up relying on it. Especially if you?re a programming
newbie and don?t have a clue how to write audio engines, let alone audio
engines that can play multiple file types, whether packed or on disk,
whether encrypted or open. Not to mention keyboard, mouse, joystick
support, screenreader and SAPI support, timers, pathfinders, combination
generators and calendars. The way I see it, scripting with something like
BGT is like having an overprotective clingy parent that just won?t let go,
whereas programming something like C++ or Python wants you to bend down
and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.

--









Damien Garwood
 

Hi there,
You're right. My apologies. While game engines are used for making games it is also important to realise that some technical knowledge of programming, or at the very least game building, is required for discussions like that.
For those interested in technical discussions of creating games, I set up the DAG (Development of Accessible Games) list (groups.io/g/dag). I propose we keep technical discussions on that list and use this list simply for game play discussions. Obviously that's up to Shane and whoever else moderates this list, but I think that will help to separate the heavy and intense from the light and breezy.
Cheers.
Damien.

-----Original Message-----
From: Zaire Johnson
Sent: Tuesday, February 20, 2018 3:20 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hay blind-gamers, I’ve been quietly listening to game engine talk for the last two or three days. I think my brain’s gonna explode Lol. All this talk about the guts of building a game. I’m just a gamer who’s surprised that Liam’s not in any of these conversations Lol. Keep creating and could you please make this stuff easier to understand Lol. Laughing at all the technical stuff going on. In closing, I wonder how A heroes Call can be so good and yet you have to remember all that stuff. I was lost long after the first message of this thread.
On Feb 19, 2018, at 11:28 AM, john <jpcarnemolla@...> wrote:

Our other hope is that an update to BGT comes out.
We know (because of VG storm) that some work has been done on it. Maybe
we'll get lucky.

--------------------------------------------------
From: "Damien Garwood" <damien@...>
Sent: Monday, February 19, 2018 10:59
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

Hi,
Oh, I thought you meant have BGT as a library. If you're talking about
building a whole new library from scratch, obviously that would take a lot
of time, effort, and advanced programming expertise. Given that I've made a
resolution to try to switch to C++ and I can't even do a basic timer
yet...Let's just say that I'm currently feeling way beyond my depths when it
comes to managing memory and threads, so I'm a complete alien when it comes
to writing audio engines and looking for pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you
think, since JavaScripts does a lot of the deep memory process for you to
start with. There also seems to be a few different JS dialects, like
Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming languages
than BGT, either because of work or programming classes etc, will more or
less know everything they need to to learn any language and get along well
with it.
Considering I spent the better part of five years parroting from VB6 and
AutoIt code to get something workable without actually understanding
anything, then actually being able to understand BGT to such a point that
I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can write a
library that can do that for me. Hello multithreading, streams and buffers,
dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons. Run
blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh, and
we're not going to tell you how to do this in Windows because we're Unix
geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all its
resources in one application and could compile in a similar manner,
including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and
writing a C++ wrapper, there is no chance of porting my literally dozens of
BGT modules straight over to C++ and have it work. That would just be too
much to ask.
So. Looks like I have a twenty year headache sentence ahead of me while I
learn, or at least attempt to learn, as much technical crap as I can
possibly retain in what I currently feel is a rather small and inadequate
brain, and then try to somehow port this mess over.
Cheers.
Damien.
-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project for
a team of programmers totaling more than one. Best not put a team like
that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:

Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi,
Even if that were the case, it would still have its audio limitations,
HTTPS crashes and UDP-only networking. So we would still end up having to
ransack the internet just to find something decent. But yeah. I could
certainly use the pathfinder, calendar, timer, tone synth, input-related
functions etc as a library. That would be neat indeed. I mean, programmers
often stress the brilliance of code reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It
seams what we need then is all the functions of BGT wrapped up in a nice
platform independent library. It could be written in something like
portable C, with all the platform dependent stuff in platform specific
modules, and bindings for different languages generated with Swig or
something. Swig is quite good at generating bindings for many programming
languages.


Note: I'm not volunteering to write it, just want to get the debate going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others. It
also isn?t indicative of real world programming. Once you realise BGT?s
limitations and want to move away from it, it?s much harder to do so
because you end up relying on it. Especially if you?re a programming
newbie and don?t have a clue how to write audio engines, let alone audio
engines that can play multiple file types, whether packed or on disk,
whether encrypted or open. Not to mention keyboard, mouse, joystick
support, screenreader and SAPI support, timers, pathfinders, combination
generators and calendars. The way I see it, scripting with something like
BGT is like having an overprotective clingy parent that just won?t let go,
whereas programming something like C++ or Python wants you to bend down
and kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios. It's
free.

--









Paul Lemm
 

Hi,


I didn't realise there was a group for developing audio games, thanks for the link.

Paul

-----Original Message-----
From: blind-gamers@groups.io [mailto:blind-gamers@groups.io] On Behalf Of Damien Garwood
Sent: 20 February 2018 16:38
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi there,
You're right. My apologies. While game engines are used for making games it is also important to realise that some technical knowledge of programming, or at the very least game building, is required for discussions like that.
For those interested in technical discussions of creating games, I set up the DAG (Development of Accessible Games) list (groups.io/g/dag). I propose we keep technical discussions on that list and use this list simply for game play discussions. Obviously that's up to Shane and whoever else moderates this list, but I think that will help to separate the heavy and intense from the light and breezy.
Cheers.
Damien.
-----Original Message-----
From: Zaire Johnson
Sent: Tuesday, February 20, 2018 3:20 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hay blind-gamers, I’ve been quietly listening to game engine talk for the last two or three days. I think my brain’s gonna explode Lol. All this talk about the guts of building a game. I’m just a gamer who’s surprised that Liam’s not in any of these conversations Lol. Keep creating and could you please make this stuff easier to understand Lol. Laughing at all the technical stuff going on. In closing, I wonder how A heroes Call can be so good and yet you have to remember all that stuff. I was lost long after the first message of this thread.
On Feb 19, 2018, at 11:28 AM, john <jpcarnemolla@...> wrote:

Our other hope is that an update to BGT comes out.
We know (because of VG storm) that some work has been done on it.
Maybe we'll get lucky.

--------------------------------------------------
From: "Damien Garwood" <damien@...>
Sent: Monday, February 19, 2018 10:59
To: <blind-gamers@groups.io>
Subject: Re: [blind-gamers] accessible game engine

Hi,
Oh, I thought you meant have BGT as a library. If you're talking about
building a whole new library from scratch, obviously that would take a
lot of time, effort, and advanced programming expertise. Given that
I've made a resolution to try to switch to C++ and I can't even do a
basic timer yet...Let's just say that I'm currently feeling way beyond
my depths when it comes to managing memory and threads, so I'm a
complete alien when it comes to writing audio engines and looking for
pathfinders.
As for porting JavaScript libraries to C++. That'll be harder than you
think, since JavaScripts does a lot of the deep memory process for you
to start with. There also seems to be a few different JS dialects,
like Vanilla, Node, Typescript etc.
Those who have had much more experience with other programming
languages than BGT, either because of work or programming classes etc,
will more or less know everything they need to to learn any language
and get along well with it.
Considering I spent the better part of five years parroting from VB6
and AutoIt code to get something workable without actually
understanding anything, then actually being able to understand BGT to
such a point that I've been relying on that for about five years, it's a lot harder.
1. High level to low level. No more music.play() for me until I can
write a library that can do that for me. Hello multithreading, streams
and buffers, dynamic memory allocation...Ugh. Already I feel queasy...
2. Single click compilation to heavy build manuals. Run Make. Run Scons.
Run
blah blah blah. Install this. Delete that. Move /blah to /bleh. Oh,
and we're not going to tell you how to do this in Windows because
we're Unix geeks. If it doesn't work, tough luck squire.
3. Self contained to resolving dependencies. The fact that BGT had all
its resources in one application and could compile in a similar
manner, including pack files, is just astounding. None of that with C++.
4. Difficulty porting. Short of literally getting BGT as a library and
writing a C++ wrapper, there is no chance of porting my literally
dozens of BGT modules straight over to C++ and have it work. That
would just be too much to ask.
So. Looks like I have a twenty year headache sentence ahead of me
while I learn, or at least attempt to learn, as much technical crap as
I can possibly retain in what I currently feel is a rather small and
inadequate brain, and then try to somehow port this mess over.
Cheers.
Damien.
-----Original Message-----
From: Jude DaShiell
Sent: Monday, February 19, 2018 3:37 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

No you wouldn't, just add stuff to the library that clear the crashes
and make the whole library better over time. The stuff from bgt could
be a sbase then build on that base. Sounds like a long-term project
for a team of programmers totaling more than one. Best not put a team
like that together until all candidates have done a few fishing trips
together to figure out who is and is not compatible enough to work
together though.

On Mon, 19 Feb 2018, Damien Garwood wrote:

Date: Mon, 19 Feb 2018 08:34:39
From: Damien Garwood <damien@...>
Reply-To: blind-gamers@groups.io
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

Hi,
Even if that were the case, it would still have its audio
limitations, HTTPS crashes and UDP-only networking. So we would still
end up having to ransack the internet just to find something decent.
But yeah. I could certainly use the pathfinder, calendar, timer, tone
synth, input-related functions etc as a library. That would be neat
indeed. I mean, programmers often stress the brilliance of code
reuse, right?
Cheers.
Damien.


From: Rynhardt Kruger
Sent: Monday, February 19, 2018 11:00 AM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

The BGT argument is one I have scene a few times on this list now. It
seams what we need then is all the functions of BGT wrapped up in a
nice platform independent library. It could be written in something
like portable C, with all the platform dependent stuff in platform
specific modules, and bindings for different languages generated with
Swig or something. Swig is quite good at generating bindings for many
programming languages.


Note: I'm not volunteering to write it, just want to get the debate
going.
Thoughts?


Rynhardt


On Sun, Feb 18, 2018 at 5:11 PM, Damien Garwood
<damien@...> wrote:

Hi,
BGT might come with many conveniences. But it also lacks many others.
It also isn?t indicative of real world programming. Once you realise
BGT?s limitations and want to move away from it, it?s much harder to
do so because you end up relying on it. Especially if you?re a
programming newbie and don?t have a clue how to write audio engines,
let alone audio engines that can play multiple file types, whether
packed or on disk, whether encrypted or open. Not to mention
keyboard, mouse, joystick support, screenreader and SAPI support,
timers, pathfinders, combination generators and calendars. The way I
see it, scripting with something like BGT is like having an
overprotective clingy parent that just won?t let go, whereas
programming something like C++ or Python wants you to bend down and
kiss its furry rosy smelling derriere before you can get it to work.
Talking from experience here.
Cheers.
Damien.


From: Josh Kennedy
Sent: Sunday, February 18, 2018 2:54 PM
To: blind-gamers@groups.io
Subject: Re: [blind-gamers] accessible game engine

You could use BGT blind game maker toolkit, from BlastBay studios.
It's free.

--