My priorities, vis-a-vis programming languages are very simple: ease-of-use/accessibility for programming games and text-to-speech support. All other considerations fall by the wayside.
I guess what I am trying to say is if there is something out there better than BGT that does those things, I'd love to hear about it. On 8/26/17, Damien Sykes-Lindley <dam...@dcpendleton.plus.com> wrote: > Hi Paul, > While it is possible to implement 3d functionality into the soundpool, > there’s a huge limit to what you can do with 2d audio. We’re already having > to shift pitch to represent the difference between in front and behind, the > last thing you really want to do is to use the same technique to represent > above versus below. > Also, the BGT pathfinder only works on a 2d grid, presumably for this reason > along with memory considerations, meaning that 3D AI is impossible unless > the pathfinder is completely rewritten as a BGT script, again adding an > unnecessary layer of abstraction. > Cheers. > Damien. > > > From: Paul Lemm > Sent: Friday, August 25, 2017 5:52 PM > To: blind-gamers@groups.io > Subject: Re: [blind-gamers] bgt exclude components > > Hi Damien , > > > > So I’ve only ever coded/scripted using BGT and not used an actual programing > language for coding , but in your email you mention that BGT is only good > for 2D audio games, although I completely understand the BGT includes for > things like the sound pool are only based on 2D audio games, since BGT > supports 3 dimensional arrays there is nothing that stops people writing > their own sound pool class which could support the third axis point which > allows people to create 3d maps using BGT if they wish. All the above being > said I still fully agree with you though that working with a full on > programming language will always give you more control than working with a > scripting language. > > > > Paul > > > > From: blind-gamers@groups.io [mailto:blind-gamers@groups.io] On Behalf Of > Damien Sykes-Lindley > Sent: 23 August 2017 21: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. > > > > From: john > > Sent: Wednesday, August 23, 2017 7:48 PM > > To: blind-gamers@groups.io > > Subject: Re: [blind-gamers] bgt exclude components > > > > Hi Damien, > > Thanks for such a detailed response, that gives me exactly the info I was > looking for. > > Unfortunately it is the base size of BGT I'm looking to reduce (an 850kb > executable is a lot more than needed for 2kb of code). > > Do you happen to know if there's any development being done on it at all? I > remember Philip had said a while ago he had some updates in the works, but > that time to work on them was limited. > > Again, thank you for such a clear and helpful response. I can't say how > refreshing it was to get this email, especially since I've been dealing with > Microsoft support recently. > > Best, > > John > > > > From: Damien Sykes-Lindley > > Sent: Wednesday, August 23, 2017 13:05 > > To: blind-gamers@groups.io > > Subject: Re: [blind-gamers] bgt exclude components > > > > Hi, > > Unfortunately this isn’t possible. These components are part of the BGT > engine rather than included scripts. Of course since BGT itself is a > compiled executable, you can’t tell it to reduce its own size. If it were a > C or C++ library that would be different. > > Also, BGT’s version of AngelScript doesn’t do any size optimisation > techniques like removing code that isn’t used. For instance including the > sound_pool library and not using it would still include the sound_pool code > to your final executable. AngelScript is updated much more regularly than > BGT is, however, so later versions of AngelScript may or may not utilise > these optimisations. This is one of the reasons I don’t use BGT half as > often as I used to. > > Literally the only way to optimise BGT executable size, is to use less code, > and compile in release rather than debug mode. > > Cheers. > Damien. > > > > From: john > > Sent: Wednesday, August 23, 2017 5:54 PM > > To: blind-gamers@groups.io > > Subject: [blind-gamers] bgt exclude components > > > > 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 > > > -- Justin M. Jones, M.A. atreides...@gmail.com (254) 624-9155 701 Ewing St. #509-C, Ft. Wayne IN, 46802 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117674): https://groups.io/g/blind-gamers/message/117674 View All Messages In Topic (15): https://groups.io/g/blind-gamers/topic/5867914 Mute This Topic: https://groups.io/mt/5867914/21656 New Topic: https://groups.io/g/blind-gamers/post Change Your Subscription: https://groups.io/g/blind-gamers/editsub/21656 Group Home: https://groups.io/g/blind-gamers Contact Group Owner: blind-gamers+ow...@groups.io Terms of Service: https://groups.io/static/tos Unsubscribe: https://groups.io/g/blind-gamers/leave/607459/1071380848/xyzzy -=-=-=-=-=-=-=-=-=-=-=-
