I was just meaning, that if you think you can't do it in the timeframe, then you are making it too big for yourself. The rules are so loose that you could literally make a programming language that has a single command `run_my_awesome_game()` and fully impliment the logic etc in your language and library of choice. Obviously a trivial/useless example, but take it up a few notches and you could have something interesting. A DSL inside JSON can be very powerful.
the time frame matches too, 14 to 20 gives you one day of rest after the last AoC, and then three more days to buy presents before Christmas that you forgot to co :)
What is a minimal-ish programming language that could be used to express some interesting class of games?
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).
Let D be the language used to express the gameplay, C be an implementation of a compiler for D in a language L. You want to minimise the length of D + C across all languages L. This gives you a unique language D (a DSL) for each game which is the most semantically dense and expresses the essence of the problem domain the best.
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
I think building an interpreted language with a basic but usable feature set - arrays, structs, expressions, control flow, functions etc. - is totally doable in a couple of days if you dont spend a lot of time ruminating on syntax and semantics.
If I had a spare week that I wanted to spend on this game jam, I would be making a dynamically typed language and an interactive fiction game.
Dynamic types make it much easier to whip up a little language and interpreter. Interactive fiction doesn't have any difficult performance requirements so even a very slow interpreter is still probably fast enough. And IF doesn't require graphics or any kind of tricky bindings. Just printing to a terminal.
I think you can make it as challenging or not challenging as you want. Just implement a simple Forth or Lisp in Lua and make a cute little game with Love2d or even just a simple text game.
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.
The crossover of language design/implementation and game development made me assume this was either a Jonathon Blow (Jai, Braid, The Witness) or Bob Nystrom project (Game Programming Patterns, Crafting Interpreters, 'Is There More to Game Architecture than ECS?' [1]).
Either way, given the time constraints and requirements I'm expecting a lot of text adventures and rogue-likes.
Easy, create a DSL that represents dialogue in a visual novel style game. Add some branching, looping, and variables, maybe some labels for jumping to and you’re good. Tada! You’ve basically reinvented Ren’Py.
A programming language could be as simple as a domain-specific-language done in a JSON format. It could just abstract away a bunch of thing, and most of the logic would just be in your "game engine".
I have been doing something minor - not full language - but I am working on a couple DSLs for my game engine. The games themselves are interpreted by my engine console - then transpiled to webgl and JavaScript.
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
Any recommendations on books / resources to read in order to participate as a beginner (language creator that is..., not beginner with programming games)?
Racket for sure, it goes straight to the heart of everything. You want simple macro compilers so you can see how simple it all is, not being confused by complex interpreters which totally obscure what is being done here.
Jack Crenshaw's 1988-1995 series Let's Build a Compiler [1]
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.
I would say the spirit of a jam is to start from scratch, but using parts and techniques you're used to is fine. e.g. repurpose your number parser but not the entire grammar and runtime. A lot of being successful at a jam is doing the right prep work so you're not making decisions and figuring things out at jam time.
It's even easier if you implement your Forth or Lisp interpreter in Forth or Lisp (both map to each other surprisingly well). Metacircular evaluator and be there.
I've been wondering about this for some time, that how there really isn't a language that's made from the ground up just for coding gameplay logic.
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 :')
I've actually spent the past 3 years making Easel (https://easel.games) specifically for gameplay logic. It's got behaviors as a first-class language construct, ownership and context is implied hierarchically, it's concurrent and event-driven to match how game worlds work, and the multiplayer is automatic because it's built into the fabric of the programming 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!
tldr I plan to make the singleplayer at least source available, but keep all parts related to multiplayer/persistence/hosting (anything that requires a server) closed for a few practical reasons:
1. Cheating: There has to be some security by obscurity because in Easel, multiplayer and persistence are actually client authoritative. Why client authoritative? We don't simulate on the server to keep costs down. Why keep server costs down? Easel will never run ads because it is aimed at teenagers/children and we want to be able to vet all content shown on Easel. Without ads, combined with the fact that we want Easel to be free for teenagers, the budget is extremely tight. I would rather die than get VC funding because they would force Easel to put profit before principles, so we have to keep the costs low.
2. Development speed: Easel has changed a lot over the past 3 years, and been constantly refactored over and over again. If you look at Easel now, you might think "I could make that" but when I made it, I didn't have any reference points, so I had to iterate and iterate on a lot of things from first principles and take a lot of wrong turns. My GitHub history shows me adding about 2 million lines of code even though the project is about 150000 lines, which shows how much it has been written and re-written. Anyone who tried to contribute would just get in the way at this point. I want to spend my days coding rather than arguing with people on GitHub.
3. Survival: I don't want someone else to take all the code to make a competing platform which does not have the same principles (like putting profit ahead of child safety and showing ads). My dream is for Easel to be a place where most players are makers, like Scratch, except with more actual real games on it because the engine has built-in game features like a physics engine, particle systems and multiplayer. Like Roblox except actually beginner-friendly coding. I have a vision quest and I want Easel to fund Easel so I can make Easel.
I am looking to open source Easel but only in a way which solves the above 3 problems. The way that I have come up with is that open sourcing the singleplayer parts is the best compromise between everything. It just requires stopping development to splitting it all out, and having all the code split out will mean development would be slower, and I am prioritising development speed at the moment. The engine is not complete enough yet and missing a bunch of key features which would stop numerous games from being made. So maybe in a couple of years I will have the bandwidth to look into this. But I actually want to open source Easel, but I just need those problems solved.
Haha I wish I knew how to reach more people like you!
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.
> I know that I am unable to single-handedly compete with Godot
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.
For Magic the gathering, sure. Not for Eve-Online. Not for Counter-Strike. Not for World of Warcraft. Not for Minecraft. Games are too diverse to limit yourself to a DDL.
Oh my God, someone has discovered my kryptonite.
Your book is awesome!
Challenge accepted, but no way I can finish this in 7 days even with a head start of a few months.
So you are not accepting the challenge then. Sounds like you are over thinking or over scoping the problem.
or just keenly aware of their own strengths, weaknesses, and time budget for this? the leap to “over scoping” is wild.
I was just meaning, that if you think you can't do it in the timeframe, then you are making it too big for yourself. The rules are so loose that you could literally make a programming language that has a single command `run_my_awesome_game()` and fully impliment the logic etc in your language and library of choice. Obviously a trivial/useless example, but take it up a few notches and you could have something interesting. A DSL inside JSON can be very powerful.
Seems ideal for those grumbling about Advent of Code’s shortened schedule this year.
the time frame matches too, 14 to 20 gives you one day of rest after the last AoC, and then three more days to buy presents before Christmas that you forgot to co :)
What is a minimal-ish programming language that could be used to express some interesting class of games?
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).
Let D be the language used to express the gameplay, C be an implementation of a compiler for D in a language L. You want to minimise the length of D + C across all languages L. This gives you a unique language D (a DSL) for each game which is the most semantically dense and expresses the essence of the problem domain the best.
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
I’m hearing FORTH, but surely that’s not what you meant to say. :)
I like to lisp but it might be time to finally learn FORTH :)
I think building an interpreted language with a basic but usable feature set - arrays, structs, expressions, control flow, functions etc. - is totally doable in a couple of days if you dont spend a lot of time ruminating on syntax and semantics.
If I had a spare week that I wanted to spend on this game jam, I would be making a dynamically typed language and an interactive fiction game.
Dynamic types make it much easier to whip up a little language and interpreter. Interactive fiction doesn't have any difficult performance requirements so even a very slow interpreter is still probably fast enough. And IF doesn't require graphics or any kind of tricky bindings. Just printing to a terminal.
a variation of lisp is SUPER easy to do, give it some primitives to graphics/sounds/inputs and away you go
Holy cow the diversity of skill sets required to do this is insane. I'll be very impressed at any Devs who takes this on solo.
I think you can make it as challenging or not challenging as you want. Just implement a simple Forth or Lisp in Lua and make a cute little game with Love2d or even just a simple text game.
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.
I think I might be the one to expect too much on second thought.
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.
The crossover of language design/implementation and game development made me assume this was either a Jonathon Blow (Jai, Braid, The Witness) or Bob Nystrom project (Game Programming Patterns, Crafting Interpreters, 'Is There More to Game Architecture than ECS?' [1]).
Either way, given the time constraints and requirements I'm expecting a lot of text adventures and rogue-likes.
[1] https://www.youtube.com/watch?v=JxI3Eu5DPwE
Easy, create a DSL that represents dialogue in a visual novel style game. Add some branching, looping, and variables, maybe some labels for jumping to and you’re good. Tada! You’ve basically reinvented Ren’Py.
A programming language could be as simple as a domain-specific-language done in a JSON format. It could just abstract away a bunch of thing, and most of the logic would just be in your "game engine".
I have been doing something minor - not full language - but I am working on a couple DSLs for my game engine. The games themselves are interpreted by my engine console - then transpiled to webgl and JavaScript.
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
Ok would like to learn more about what you have been building, can we talk? I have thought of similar ideas.
Any recommendations on books / resources to read in order to participate as a beginner (language creator that is..., not beginner with programming games)?
Racket for sure, it goes straight to the heart of everything. You want simple macro compilers so you can see how simple it all is, not being confused by complex interpreters which totally obscure what is being done here.
Heh, I guess you could read my two books, "Crafting Interpreters", and "Game Programming Patterns". :)
Well this is certainly cool! Your first book has been on my reading list. I'm cracking it open tomorrow!
Jack Crenshaw's 1988-1995 series Let's Build a Compiler [1]
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.
[1] https://compilers.iecc.com/crenshaw/
[2] https://www.venge.net/graydon/talks/
Crafting Interpreters!
What if you've already been working on a language for a while and want to use it instead of making a new one just for this?
I would say the spirit of a jam is to start from scratch, but using parts and techniques you're used to is fine. e.g. repurpose your number parser but not the entire grammar and runtime. A lot of being successful at a jam is doing the right prep work so you're not making decisions and figuring things out at jam time.
This is not as hard as it sounds as long as Forth and Lisp variants qualify.
You can write a basic Forth or Lisp interpreter in a day.
It's even easier if you implement your Forth or Lisp interpreter in Forth or Lisp (both map to each other surprisingly well). Metacircular evaluator and be there.
I've been wondering about this for some time, that how there really isn't a language that's made from the ground up just for coding gameplay logic.
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 :')
I've actually spent the past 3 years making Easel (https://easel.games) specifically for gameplay logic. It's got behaviors as a first-class language construct, ownership and context is implied hierarchically, it's concurrent and event-driven to match how game worlds work, and the multiplayer is automatic because it's built into the fabric of the programming 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!
If I understand correctly, the language is not open source, right? Not even the interpreter?
That's a hard sell
tldr I plan to make the singleplayer at least source available, but keep all parts related to multiplayer/persistence/hosting (anything that requires a server) closed for a few practical reasons:
1. Cheating: There has to be some security by obscurity because in Easel, multiplayer and persistence are actually client authoritative. Why client authoritative? We don't simulate on the server to keep costs down. Why keep server costs down? Easel will never run ads because it is aimed at teenagers/children and we want to be able to vet all content shown on Easel. Without ads, combined with the fact that we want Easel to be free for teenagers, the budget is extremely tight. I would rather die than get VC funding because they would force Easel to put profit before principles, so we have to keep the costs low.
2. Development speed: Easel has changed a lot over the past 3 years, and been constantly refactored over and over again. If you look at Easel now, you might think "I could make that" but when I made it, I didn't have any reference points, so I had to iterate and iterate on a lot of things from first principles and take a lot of wrong turns. My GitHub history shows me adding about 2 million lines of code even though the project is about 150000 lines, which shows how much it has been written and re-written. Anyone who tried to contribute would just get in the way at this point. I want to spend my days coding rather than arguing with people on GitHub.
3. Survival: I don't want someone else to take all the code to make a competing platform which does not have the same principles (like putting profit ahead of child safety and showing ads). My dream is for Easel to be a place where most players are makers, like Scratch, except with more actual real games on it because the engine has built-in game features like a physics engine, particle systems and multiplayer. Like Roblox except actually beginner-friendly coding. I have a vision quest and I want Easel to fund Easel so I can make Easel.
I am looking to open source Easel but only in a way which solves the above 3 problems. The way that I have come up with is that open sourcing the singleplayer parts is the best compromise between everything. It just requires stopping development to splitting it all out, and having all the code split out will mean development would be slower, and I am prioritising development speed at the moment. The engine is not complete enough yet and missing a bunch of key features which would stop numerous games from being made. So maybe in a couple of years I will have the bandwidth to look into this. But I actually want to open source Easel, but I just need those problems solved.
This looks promising. How come I hadn't heard of it??
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!
Haha I wish I knew how to reach more people like you!
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.
> I know that I am unable to single-handedly compete with Godot
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.
Yep, it's definitely a possibility down the line.
Maybe a 7-day gamejam is a great way to explore your ideas!
There are many that are specialized for different uses in games, such as:
- 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.
Don't forget: SCUMM
Well, if you’re interested in text-based games, there have been custom languages for a long time.
https://www.linusakesson.net/dialog/craverly/craverly_side_b...
Also LPC for muds, although that definitely wasn’t built from the ground up.
There is OpenGOAL[1]. A re-implementation of the language that Naughty Dog used to created Jak and Daxter.
[1] https://opengoal.dev/
Check out Jai, apparently if you ask nicely its author will let you use it. Unofficial docs here: https://pixeldroid.com/jailang/
Jai is just a C-like with manual memory management etc.
I mean something that is divorced from hardware and just focuses on gameplay logic; let the engine continue to be in C++/Rust/whatever.
PuzzleScript is the closest to this I can think of. Hyper specialised though.
https://www.puzzlescript.net/
In my opinion, Free Hero Mesh is better, although each has its own advantages and disadvantages compared with the other(s).
(There are also some variants of PuzzleScript, which add a few extra functions.)
SQL is deterministic. Julia is deterministic. Gameplay is not deterministic. Constraints are arbitrary and there are no rules.
I think magic the gathering set a pretty good standard.
For Magic the gathering, sure. Not for Eve-Online. Not for Counter-Strike. Not for World of Warcraft. Not for Minecraft. Games are too diverse to limit yourself to a DDL.
Use Logo! Straight-forward parser. Turtles make game elements easy. Write it in Go for simple multi-threaded agents.
I’m going to blog about whatever I end up building. I hope some of you will join me :)
If only it wasn't finals week
lol, I spent 3 years coding a game programming language...