I'm looking at this thread with interest. After spending a lot of time on web games I wanted to do something in native code again, and shopped around newer languages(Rust, Go, Nim, D) but ultimately decided that these factors were important to me:
- Fast compile times
- No, or opt-in, garbage collection(some reference counting is OK)
- Smaller, rational language design
- Good existing tooling and libraries
And FPC's Pascal fits all of these neatly. It's always beat C and C++ handily on compilation speed and ergonomics. There are "nice to haves" that are in newer languages, there are examples of stronger tooling elsewhere, and there's plenty of old cruft in the landscape, but the legacy of Delphi + FPC has actually been very good to the language since it's enabled a strong focus without much fragmentation. In comparison, if I want to do something in Rust, a lot would still have to be done "from scratch" - few or no projects to sample code from, rough libraries, a lot of stuff still being bindings to a C library.
I'm mostly agnostic now to the idea of "all Pascal everywhere", or building a top-notch engine from scratch, or other grand designs. They aren't motivating projects, to me. I think the language is a good choice for the same reasons it was originally good(small, structured, logically organized, easy to compile, some common conveniences and protections). What I mainly want to champion in this thread is the idea that you can make very cool, hip gaming software without chasing after AAA-scale projects.
My own plan for right now is to do some "Crt-only" stuff. Textmode gaming has a perennial fanbase and I can probably build up some libraries out of that. I want to produce libraries in the stb libs fashion: One file, you drop it in the project, and it works. This is actually way more straightforward with Pascal units, but the fact that this has become a trendy idea in C, an environment that is hostile to the concept, speaks to its appeal.
Then I would progress to graphics systems that are API-independent. The trick to that is, the application can address graphics with a high-level custom state machine. That state machine pushes commands on a stack or sets registers, and then outputs lower level API calls to your GL, DX, Vulkan, etc. This is exactly how old-school immediate mode GL talked to the graphics driver, and why it remains so convenient. It's totally valid to build that abstraction yourself when you have a design in mind and you're aiming towards a purposeful method of rendering("make games not engines").
And you can have a series of such state machines that translate a very high level source representation. Think of how canvas graphics APIs often provide a "Pen" or similar kind of state-driven drawing method: You can build your own pen and make it capable of whatever conveniences you want for whatever type of scene you want to draw. You can feed the results of that into a second system and have it process the results, and emit that to the low-level API.
If you extrapolate from this strategy, you can also take the approach of targeting an existing engine with a DLL, and then gradually strangle all the features out of it by moving more and more of them into your own code and eliminating the dependencies. The abstractions you make might not always be the nuts and bolts, but they are great seasoning, and go with anything.
Building up from prototypes is also feasible. This is why I'm starting with the "Crt-only" approach: it will get me to feedback quickly. Feedback is crucial to making progress with anything big, and it's easier to get feedback when you don't take on too much.
Lastly, I'm drawing on examples from other communities. There's the examples of Handmade Network and the PICO-8 community. This former is a dev community that's very focused on "back to basics" coding for efficiency - mostly in C, but not particularly language-focused. The second is about a "fantasy console" with an intentionally retro aesthetic and harsh limits on resources, programmable in Lua, and it's been promoted as a learning tool. I'm also very inspired by analog hardware projects such as the special stage systems Ming Mecca - game-like qualities taken out of the packaging of gaming and turned into a synthesizer instrument programmed with patch cables. These qualities deviate strongly from the accepted norms of what coding - game coding or otherwise - is or should be, and should be taken as examples of the possibility space.
There is lots of potential for "can-do". It's just a matter of finding a good leverage point and leaning on it.
Reply With Quote
Bookmarks