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.
Readit News
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
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.
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.
[1] https://www.youtube.com/watch?v=JxI3Eu5DPwE
Deleted Comment
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
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/