ann-arcana

Queen of Burgers 🍔

Writer, game designer, engineer, bisexual tranthing, FFXIV addict

OC: Anna Verde - Primal/Excalibur, Empyreum W12 P14

Mare: E6M76HDMVU
. . .



vectorpoem
@vectorpoem

at the beginning of last year, i found myself building a little 3D game engine called Cuberealm. it was the first time i'd done a full 3D engine and it was very enjoyable and educational. i had my world rendering and a lot of the basics figured out, and then i hit a wall getting grid tracing to be super reliable. and then life stuff intervened and i haven't touched it since.

i imagined the usage scenario for this engine being essentially, it's small and simple and it's all in python, so just fork the code and start building what you need for your own game in a subdirectory apart from the main engine code. and if you make a game and want to distribute it to people, just turn it into an EXE the way you would any other python program: using one of a few different programs that *sigh* are not built into python itself, the output of all of which now get flagged by default as viruses by windows defender (and the vaguely-to-openly-scummy underworld of other AV suites) nearly 100% of the time, because they can't or don't bother to distinguish between a harmless lil game written in python and one of the malwares out there that run with a bundled python interpreter.

this is what i did with Playscii releases for many years. and each time, when windows defender almost inevitably detected my latest build as a virus, i'd dutifully submit it to this page on MS's site as a false positive, and then in the next signatures file update it would no longer be flagged, and my users would stop getting a scary message. until the next build i did, rinse lather repeat etc.

needless to say, this was wearying. every reassuring reply i had to send to every concerned email i got from playscii users worried they'd been infected with malware made me feel like a bad software developer. and my ability to continue distributing builds of my software to windows users was contingent on MS believing me when i said, no see my pyinstaller-produced EXE is just a harmless weird art program / game engine hybrid, not one of those viruses. and as we've seen with things like recent years of macOS compat policy, and twitter's recent API policy change, there are contexts in which you can be writing software where your ability to keep doing that can vanish overnight just because some executive shrugged. that is not an environment i ever want to be working in.

i took basically all of last year off from working on personal projects, partly because this situation was bumming me out so much. in the back of my mind i kept wondering, should i just move new projects like cuberealm to a new programming environment where i wouldn't have to worry about this? i learned python in 2004-5 or so, and it's been an extremely comfy old pair of shoes for so long. but maybe that hole in the sole that keeps letting cold rain in isn't actually fixable.

(quick aside: there are definitely projects i use existing engines/tools for - gzdoom, unreal 4/5, quake, twine, pico-8, etc. this post is about stuff that isn't that. i also have a whole separate rant that elucidates my desire for more engines and tools besides the big few industrialized game dev ones, the dreamed-of "small tool renaissance". suffice to say, i respect and learn from what the big kids are doing but have strong ideological reasons for wanting to be active in this smaller, more experimental space - and i think it's better for the medium in the long term if more people are.)

there are a billion programming environments, languages, stacks etc out there, and i look into almost every one that comes across my radar. and most of them stress me the fuck out even reading about them. i never want to stop learning how to write better code, but unlike a lot of perfectly cool people i know, i do not write code for the sake of writing code - i want to make creative things, and make tools to help other people make creative things. so i'm not sure how to improve my luck at finding and narrowing down alternatives that meet my specific needs. but maybe enumerating those needs is a start:

  • end-user distributables never trigger windows antivirus warnings. seems basic but this is the biggest single reason i'm looking for alternatives to belovéd python.
  • absolutely no C++, or anything that uses makefiles. C-lineage build systems are a deep pit that drains my will to live.
  • "low level" / "high performance" not a major requirement. computers are so damn fast now and the kind of stuff i am interested in making requires <=2003-vintage visual fidelity. the primary benefit of high perf in this domain IMO is to provide more overhead to make everything (launching, iterating, hot-reloading, etc) happen instantly.
  • "high level" language like agility for rapid prototyping and productivity, whether the whole thing is written in a HLL or it's embedded in some other substrate. i want an environment where i can write code that gets an idea on-screen as fast as possible, without having to worry about shit like memory management, but lets me gradually turn it into robust fully shippable code.
  • cross-platform. linux is my main OS and support for that should be a first-class citizen. windows should work fine, mac should work though i won't commit to being responsible for doing builds on that.
  • reasonably easy to make and distribute builds to people. bonus: distributable file size is non-piggish (python was actually decent for this; playscii win32 builds were about 20MB zipped).
  • doesn't require a big bullshit IDE, or a particular text editing setup.
  • open source, obviously, in keeping with the larger theme of only building atop tech that no corporation can take away or ruin.
  • decent project governance - non-asshole leadership and community, functioning code of conduct, etc.

possibilities:

  • rust + some kind of embedded scripting? rust seems like a very solid systems language with sane build and module systems, and i'd like to learn more of it. but it doesn't seem like the ideal lang for writing quick game code in. i see there are lua bindings for rust, but i'm not clear on what the interface between such a loosey-goosey scripting language and super safety-conscious engine code would feel like to both build or use.
  • browser-based? beyond a few simple "HTML page that does a bit of interactive stuff with js" experiments, i've always kinda avoided building on the web for a few reasons: the shifting sands nature of it as a platform, the fact that it seems to inhabit a totally different world from the files-and-directories world of game development. but if i found the right set of tools, i could imagine taking the plunge. and it's hard to argue with the approachability of running from a web browser.
  • something C#-based? C# seems like a nice language to work with in many ways but using it from linux i've always felt like i'm getting some watered down version of the real fully-supported thing, that the dev experience has uneasily ported to a hostile foreign environment. please tell me how this is outdated or flat wrong!
  • something else? suggest away!
  • or i could just give up and stop trying to make stuff and enjoy the rest of my life! ha ha ha

You must log in to comment.

in reply to @vectorpoem's post:

[context: My day job is working on the dotnet/runtime repository, and I do this exclusively in a Debian VM using VS Code]

There might be some modern options for doing Python on top of .NET? I haven't tried IronPython in a long time so I don't know if that's realistic, but I know it used to work pretty good.

I personally use C# for almost everything but I don't know that you would find it comfortable/empowering in the way that Python is. Self-contained .NET app builds (all dependencies included, etc) are finally somewhat small if you enable trimming and the linker, but probably still bigger than they should be. You could also try F# which is from what I know a pretty great functional language on top of .NET, but it's kind of a second class citizen.

Rust and browser based both seem like good options to me, with the caveat that everything I know about Rust suggests you will be less productive than it in Python; perhaps much less productive. Browser is a decent way to distribute stuff as long as you aren't going to get cut by sharp edges like "I'm using an API with inconsistent support across vendors" or "Google has decided that what I want to do isn't allowed".

I also don't know what your odds are of getting flagged by anti-virus software when using .NET Core or Rust. I feel like it might not actually be much better, especially for exe files unless you're using a signing certificate. I had to get one the last time I was distributing Windows software.

I'm annoyed arbitrarily and perhaps unreasonably by C#, but as of C# 7, the code trimming/single file distributions and now NativeAOT is a pretty compelling tool to have in the toolbox. The dotnet command-line tool works well from Mac, and VSCode integration works great. Console support may even be in the near future of NativeAOT.

Hey bud, sorry to hear about your rough time with things. :(

My suggestion would be to use Typescript with something like Three.js. Typescript is a beautiful language where Microsoft took all the good parts of C# and applied them to the worst language in the world that happens to also run it (JavaScript). There's an incredibly rich ecosystem of tools, widgets, and snippets just waiting for you to pick up. And to package executables, you could use something like Electron.

Or you could do what I did, which is to run a C++ backend for your game and render it using Chromium Embedded Framework. (Don't do what I did.)

Or you could do what I did, which is to run a C++ backend for your game and render it using Chromium Embedded Framework. (Don't do what I did.)

there are actually frameworks for doing something similar to that, essentially electron with other "backends" like tauri for rust! its really nice to work with because you can write stuff like fs access where you don't want to use JS in rust which is pretty neat

also can confirm that typescript is nice. its performance due to it compiling down to JS isnt the best, but its incredibly portable and just. nice to use

i'm making a game in rust right now, and i can confirm it's not great for writing quick game code in. what i do really like, and what i've developed the majority of my other games, is Haxe... here is what i like about it:

  • it can target windows/mac/linux as well as HTML5 from the same codebase (and supposedly phones as well, although i haven't tried that)
  • intuitive C#-like syntax
  • hits a sweetspot (for me) of "high level" to "low level"; more rigid than say, lua, so the compiler can actually catch stuff, but it has a garbage collector and is still pretty flexible and quick to code in
  • high performance because it builds by transcompiling to C++. you can also target its virtual machine, HashLink, for really quick build times during development
  • open source, can code outside of IDE (i use vim for all my development)

it's a little niche but it's been around since 2005 so it's pretty mature. i'd also recommend checking out HaxeFlixel and Heaps if you're looking for decent gamedev libraries to build on top of.

i looked at several rust scripting languages a few years ago and was very impressed with Rhai, which it looks like is still actively maintained. it's possible to have a pretty tight idea-to-implementation loop in Rust once you're used to it, unless your project is large enough that compile times start to cause problems.

if you want something browser-based, i'd recommend against doing everything in JS. it's just not a very good language, and typescript does not go far enough to make it good. (i've been writing typescript at my day job for over a year now and it regularly makes me sad.) Pyodide is a browser-based build of Python, and it should be possible to put enough glue together to be able to use it for game development, and it's technically conceivable that someone already has.

suggestion! (just because I've thought a little about this myself)

If I was making a tool like this (maybe someday I will be), I would make the tool export zip files with a custom extension, e.g. a .cube file, or whatever. And then I would make and maintain emulator-like runtimes for desktop and browsers. This is obviously never gonna be as performant as making native builds, but sounds like that's not a priority anyway?

i definitely really like the "single file distribution" + portable runtime thing that PICO-8 et al are doing! i think i started Playscii about 6 months too early (late 2014) to have known how cool it was and committed to it being a core part of it. but now i'd definitely do it.

building a runtime that runs on both desktop and browser without too much pain seems like it'd largely be a matter of language + stack - some seem to make it reasonably easy. another cool thing that was around but not nearly as prevalent ~8 years ago.

Downpour is different from the thing JP wants to build in a lot of ways... but yeah, this is what I'm doing. Actually, the strategy I'm using involves including the "browser runtime" (aka "index.html") in the zip file itself, and also coding it carefully so you can just unzip it and click on index.html and it runs! or you can upload it to neocities, itch, etc v easily.

I'm writing the editor in Flutter (would recommend, if you're doing stuff that looks like a normal application UI & nothing that requires fun custom rendering or 3D - which I don't think if your situation, but still), so it's a bit annoying to have to implement stuff twice & match behaviour across Flutter editor & browser.... but honestly not too bad.

rust + some kind of embedded scripting? rust seems like a very solid systems language with sane build and module systems, and i'd like to learn more of it. but it doesn't seem like the ideal lang for writing quick game code in. i see there are lua bindings for rust, but i'm not clear on what the interface between such a loosey-goosey scripting language and super safety-conscious engine code would feel like to both build or use.

ive used rust in combination with JS a few times, including embedding a runtime into rust and doing scripting in JS, and it is pretty nice! there are a couple of libraries for rust to embed JS, and just using JSON + serde to send packets works like a charm :)

One thought is that WASM would be a pretty good target for gameplay code. So some kind of thin-ish driver app in Rust or whatever and then code in some scripting language with WASM support. Though there's probably a lot of work on getting something like that up and running.

It might be worth having a look at Bevy. It's written in Rust, and it's a full game engine (albeit still under development) but it's very flexible, customizable, and "code first" so I don't think you'd find it limiting because of that. It has a number of nice properties that I think align well with your needs. Among other things:

  • It's open source, and has a very welcoming community.
  • Game logic is written in Rust, but Bevy works very hard to make that experience as ergonomic as possible and I think it's pretty successful. There are also plugins available that add support for various scripting languages, though I haven't used them and I don't know what that experience is like.
  • It can target Linux, Windows, Mac, browsers via WASM, and mobile.

I went through the same hell as you distributing a python project packaged into exes. It's miserable and demotivating being falsely accused over and over.

I certainly understand wanting to replace python for future projects, but in the meantime, if your python stuff is open source I'd consider distributing it as source. i.e. package up the python source, the CPython embeddable interpreter and a batch script to start the interpreter on the source and call the batch file RUN ME or something.

My program is exactly the same, but having done that, Windows Defender and everybody else on virustotal is happy with it. I guess the interpreter is a signed exe now, but this seems extremely arbitrary. Never could get rid of the batch script's terminal window blinking in for a second though, so that's a bit jankier. Anyway, an option perhaps for the old projects.

My approach was to write a build script to copy them into subdirectories of the source directory, then in the program, manually add the source directory to the module search path. For tidiness I was actually zipping up all the source (deps included) then adding the zip to the search path. i.e.

sys.path.insert(0, "playscii.wad")

Python 3 is smart enough to unzip the file into memory and preferentially look for modules there. I don't recall if I had to screw with any import statements, but I recall everything pretty much worked the same as did out of site-packages. And I had some checks to not do any search path fuckery in the dev setup, so I could still use pip normally.