I would say this is massively subjective, although there are some valid points in there I guess.
It also completely glosses over a few major facts. Namely: 1. Speed is less and less of a problem these days. 2. It's much easier to read than either C or C++. 3. It's much more maintainable than either C or C++. 4. While you lose a lot of speed, you also lose the chance that memory bugs will creep in. Also, if you need parts of your game sped up, you can always use external libraries written in C, C++, or Rust. Finally, indentation is not a problem for anyone in 2021, and it's ridiculous how often this is presented as a reason for not using Python. Even in languages where indentation is not mandatory, it's highly recommended because of the increased readability, for everyone, not just people who can see. Anyways, I don't want to start a programmers' pissing contest, just wanted to point out that if a new developer read your email, they would reasonably assume that Python was pure evil, and should be avoided like a fart in a confined space. Take care, Chris Norman On Sun, 14 Feb 2021 at 13:24, Damien Garwood <dam...@daygar.plus.com> wrote: > Hi, > Personally, I don't see what all the fuss is about Python. > For what my opinion's worth, I would suggest C or C++, all the way, 100%. > The one advantage I can see with Python, apart from the fact that it is > regularly maintained (always a plus), is its inherent ability to package > scripts together and interact with them separately but cooperatively. In > all fairness, I absolutely love that feature. > Other than that: > 1. Python is far slower than C and C++ (to be expected with an > interpreted language using so many higher-level wrapper layers). You > might not think that's a problem for games, but it depends on how big > your games are, and how much you care about speed. As a developer, I'd > much rather plan for the worst case, that is to say a massive open-world > game which might have thousands of objects, and try and optimise it in a > way that allows it to take three seconds to open in a solid language > than having to stick with the limitations of it taking over 30 seconds > in an interpreted environment, simply because you have no control over > how memory is allocated or accessed. > 2. Python is far too bloated. Again, so many moving parts, having to > ship the interpreter with the code, any DLLs (or indeed PYDs) that might > be being wrapped etc. None of this can be linked statically. There are > complicated workarounds that would trigger the alarm of certain virus > scanners, but they're not ideal by any means. With C or C++, as long as > you have the source code to what you're linking, you could link > everything statically and safely into one executable. As an example, if > SoundRTS was rewritten in C++, chances are the distribution directory > could easily contain 600 files less than the Python distribution does. > We already saw an example on list the other day of what can happen if > you just happen to be missing one DLL! > 3. Python is far too vulnerable to reverse engineering, only making it > viable for open-source products. Experienced closed-source Python users > know how to get around that, either by using obfuscation, or even by > modifying the interpreter. But again, that's using complicated methods > that Python wasn't technically designed for, possibly making it even > slower at runtime, and definitely making Python more complicated for the > learner. On the other hand, try to decompile a release binary in C and > C++, and you get nothing but hex and assembly. > 4. In some cases, Python seems a lot more complicated. I'm not sure > whether that's because of the tutorials or the philosophy behind it, but > start talking to me about virtual environments, pip, the processes for > building executables, or the process for trapping exceptions in pyw, > it's enough to send my head in a spin. In C++, you don't need packages > and environments, and its ways of exceptions and executables are a lot > more elegant. > 5. On a more personal pet hate of mine, Python is far too visual with > its indentation requirements. I guess that's OK for people using braille > or partials that can see a screen, but mere mortals using speech don't > need it, and for my part I could spend the rest of my life without it. I > find it much easier to read code with deliberate boundary symbols. Of > course that is simply a matter of preference and setup. > The way I see it, Python wasn't designed for programming at all. In > fact, I wouldn't be surprised if Python is slightly like AutoIt. That is > to say, it started out as an automated or possibly shell scripting > environment, and has since evolved to try to be like any other > programming language, and for that reason, it suffers from many defects > and deficiencies. I believe even the Python documentation refers to a > few situations that arise as a result of previous bugs or design > oversights. > Cheers, > Damien. > > On 14/02/2021 11:20 am, Chris Norman via groups.io wrote: > > Hi, > > There are a few different audio game engines for Python, these include > > Earwax <https://earwax.readthedocs.io/> (beta), Lucia > > <https://github.com/luciasoftware/lucia> (which is supposed to be more > > familiar to those coming from BGT, Framework > > < > https://forum.audiogames.net/topic/38239/framework-my-new-set-of-tools-for-audiogame-creation-in-python3/> > (for > > > want of a better name), and pyAGE > > < > https://forum.audiogames.net/topic/38941/pyage-yet-another-python-audio-game-engine/> > (which > > > is still very much in its early stages). > > > > If you'd rather go the mainstream route, and don't mind a little more > > work, there's Godot Accessibility > > < > https://forum.audiogames.net/topic/33909/migrated-godot-accessibility-to-github/ > >. > > > > Finally, for some subjective comparisons, see this thread > > <https://forum.audiogames.net/topic/38995/python-and-audiogame/> on the > > audiogames.net <http://audiogames.net> forum. > > > > There are others, namely MonoGame <https://www.monogame.net/>, and > > probably some other stuff in C# too. > > > > Other than that, please just do everyone a favour (mainly yourself), and > > don't use BGT. It's like deciding to dig yourself a swimming pool, using > > a plastic bucket and spade for digging, wattle and dorb for lining, and > > stiff prayer for water purification. > > > > HTH, > > > > Take care, > > > > Chris Norman > > > > > > > > On Sun, 14 Feb 2021 at 02:42, Immigrant via groups.io <http://groups.io> > > > <immigrant328=verizon....@groups.io <mailto:verizon....@groups.io>> > wrote: > > > > Hello, everyone. I have just joined the group, and I hope the > > distinguished > > gamers and writers in this gaming community understand that I am > > very much a > > beginner, trying to write perhaps a couple of simple dice or card > > games. I > > wrote a dice game script in BGT, and the script doesn't generate any > > compilation errors. However, the game window stays open only for a > > couple of > > seconds, and then disappears, so none of the program's keystrokes > can be > > executed. I realize that BGT is no longer supported, but it does > > work under > > Windows 10, and it is the only engine where I know how to implement > > keystrokes and add and manipulate sounds. I checked basic tutorials > > for a > > few programming languages, and realized that game logic can be > > programmed in > > any of the languages but none of these tutorials addresses > > keystroke-driven > > implementation, or addition of sound. And even in the BGT tutorial, > > I have > > not found answers to some of my questions. The game I am currently > > trying to > > write is a dice roller, but if one tries to create, for example, a > card > > game, how do you make a card playable? If cards exist as strings, or > > parts > > of an array, or even instances of their own class, they are just > > abstract > > logical structures. But cards need to be manipulated - picked up, > > discarded, > > etc. If I have a hand with 5 cards, how do I program a way to > > navigate the > > list of cards and then perform an action on a card currently in > > focus? How > > to make it an element of interface so it can be selected? I hope I > > clearly > > expressed my questions, and I am grateful in advance for any > > clarifications. > > > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#123331): https://groups.io/g/blind-gamers/message/123331 Mute This Topic: https://groups.io/mt/80623843/21656 Group Owner: blind-gamers+ow...@groups.io Unsubscribe: https://groups.io/g/blind-gamers/leave/607459/1071380848/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
