It's easy to think of pathologically trivially useless "languages" that could "make a game". E.g. the single instruction language where the instruction P is defined to mean "execute a game of pong". Or a zero instruction language where the empty program is defined to mean "execute a game of pong".
Also easy to think of existing minimal programming languages that could technically be used to implement games. E.g. brainfuck is a beautifully minimal language with only 8 instructions, supporting character IO - so you could make a text based adventure game with it, but this would be unpleasant and there isn't anything about brainfuck that makes it suited to game dev.
Another idea could be to have a non Turing complete language where you declare data for entities etc to be executed by some game engine/runtime. E.g. it might be possible to define a language for declaring data & entities to express a few different but similar games (e.g. spanning pong --- breakout, or one specialised for simple card games, or so on).
The language or languages D is discovered (not designed) and is the essence of the problem, will never change and is true in all universes. Any general purpose programming language solving the same problem (a solution using L) will have a structure of D with a bunch of boilerplate and design patterns (design pattern = boilerplate = hints at a special form in D).
Using a hierarchy of these minimal languages D with one compiling into another for each little problem is the only way to get ‘clean code’ free of boilerplate.
Software engineering is minimising D + C for all L
Maybe I expect too much from people but like at least being able to write a simple tree-walking interpreter is basic computer science education and who hasn't tried to make a game at least once?
The problem is more that some people just like sharpening the saw and some people like cutting down trees. Both are valid. Some people get really into programming languages and tooling but never ship any product or vice versa. But people need to be skilled enough to do both.
Making a language and a game is one thing, making a good language and a good game is something else entirely.
Very few people can do either of those on their own, let alone both.
Either way, given the time constraints and requirements I'm expecting a lot of text adventures and rogue-likes.
Graydon Hoare's 2002 talk `"One Day Compilers" or how I learned to stop worrying and love static metaprogramming` [2] (implements a compiler for a DSL that's a subset of makefile syntax in < 400 lines of code using ocaml toolchain)
edit: on second thoughts, aiming to ship a game in a novel _compiled_ language in a 7 day language+game jam is probably a lot more optimistic than aiming for an interpreted language.
The DSL is for cutscenes and scripting dialogues and movements and transitions.
The idea was to have a screenplay like language that would run in my game engine so I can write the scenes like a script instead of like code.
—
Then I am using a LUA like subset for the core game logic.
I don’t think I would want to have the entire thing written in a custom language though, as that seems unnecessary
You can write a basic Forth or Lisp interpreter in a day.
Like we have SQL for databases, Julia etc for maths etc, but gamedevs still have to plod along in general-purpose languages with archaic conventions established 50 years ago by people who had nothing to do with games.
I'd love something with the syntax of GDScript and the features of Swift, with special constructs just for gameplay logic, which is often a hybrid between inheritance and composition, static and dynamic, declarative and imperative.
I've been toying with what would be the ideal syntax (for me), but I don't have the brains to actually make a language :')
It also feels like a declarative language because of the high-level constructs, but it is actually imperative because (in general) things get executed in the step-by-step order you specify, which I think is important because games are full of sequences.
It's been a lot of work but also a lot of fun! My aim is for this to be a great next step after Scratch for people learning to code but also a good model for how a more advanced game-making programming language could work in the future!
My own ideas for an ideal syntax included keywords like "on" instead of "func" etc. (i.e. be totally event/signal driven)
Taking a look!
Yeah exactly! I think the event-driven/signal-driven way of coding is the high-level way of coding a game, and so with Easel I was trying to make a game programming language where that is first class. It's different from the frame-by-frame state machine kind of model that is used by a lot of other game engines, and I find it's super productive.
I know that I am unable to single-handedly compete with Godot or Unity so to make the scope achievable it's aimed at being a good 2D programming language for learners at this point. There's a surprising amount of similarity between Scratch and Easel because Scratch is also event-driven and concurrent like Easel. We often send our learners to Python or JavaScript and I've seen that they just lose engagement. The difference is bigger than just going from visual to text-based coding. Easel makes the gap closer and so I am hoping it'll be a great next step from Scratch into text-based coding.
But I also hope Easel can add to the conversation and interest people like you as a example of how game programming languages could be made. One day I hope to actually bring Easel to more serious games, maybe bringing it to other engines or with its own 3D engine. One reason why I am leaning on making my own 3D engine (long term goal) is that in Easel, the multiplayer is automatic and it would be difficult to bring that to another engine.
In either case it's great to meet someone who has been thinking about this kind of problem like I have.
You could package your language as a GDExtension for Godot.
I'm planning my fantasy language from the top-down, syntax first: how it would look like to users/developers to use it, then think about how to implement that language if ever :')
Right now I'm just fiddling with a extension for VSCode/ium to syntax highlight the hypothetical language, then I'll put it up on a brainstorming repository on GitHub.
- ZZT-OOP
- MegaZeux Robotic
- ZIL
- MESH:Hero
- Free Hero Mesh
- Super ZZ Zero
- OHRRPGCE HamsterSpeak
(There are probably a lot more that I had missed)
All of these are specific to the specific kind of games being made with them, though; different kind of games will require a different kind of logic.
MESH:Hero is specific to a specific kind of puzzle games, and Free Hero Mesh is a FOSS clone of MESH:Hero with a different syntax and more features.
https://www.linusakesson.net/dialog/craverly/craverly_side_b...
Also LPC for muds, although that definitely wasn’t built from the ground up.
I mean something that is divorced from hardware and just focuses on gameplay logic; let the engine continue to be in C++/Rust/whatever.