Re: Earwax
I find this thread really interesting because it closely relates to a project at my current work. I am working at a new company that is preparing to conducting research experiments and I've been developing a web app for them that essentially allows one of the scientists to write a structured spec for an experiment and then the web app interprets the spec and provides a dynamic single page app that the leads the user through the experiment, collects their answers/ measurements, and sends it to backend.
based on the experiment spec, the web app renders specified questions, fetches the right assets from the server to play and uses settings like whether to play things automatically, what delay, etc.
When I first came in the specs were json files that conform to a schema and I had to evolve the schema to be more flexible and allow people who use them to have more diverse features they can use, etc.
Currently at the end of the day the schema still is encoded as json, since it needs to be sent from the server to the web app anyway, but I noticed in making the schema more flexible that it became much more verbose and repetitive, which made i so that people had to copy and paste all the time, which makes it easy to create mistakes and also if you want to change one thing that repeats then it can be difficult to update everywhere.
I thought of creating declarativ little python functions for the different parts of the schema that fit neatly together and can be used to define the spec with code that gets turned programmatically into json, instead of writing json manually.
for example the basic parts look sort of like this:
def experiment(name: str, questions: list[Question]): Experiment
def rating_question(label: str, values: list[int]): Question
def text_question(label: str)
and you would then just define an experiment declaratively something like this:
my_experiment = experiment(
name = "My Great Experiment",
questions = [
rating_question(
"How pleasent is this experiment",
values = list(range(1,6))
),
...
)
The immediate advantages for even very new python programmers is that they could factor out repetition for example if the same question repeats in different parts that they could define a variable and declare it in different parts. so also then if you want to make an update to all the places it is used then you need only update its definition.
e.g.:
standard_questions = [
text_question("how are you?"),
...
]
exp1 = experiment(
name = "exp1",
questions = standard_questions + text_question("what is special about exp1?")
)
also I am thinking of completing the type hints more if I can prioritize it, because I think running a spec through mypy and having it catch silly type errors would be useful. honestly I would prefer writing this in something more strongly typed like at east Typescript, but the backend uses python.
and then the slightly more advanced thing that this opens up is using the basic building block functions to define your own higher level functions where you just provide a couple parameters and then all the repetitive stuff is taken care of and your spec is much easier to read since you can focus on what is important and hide the boiler plate.
In your case I am thinking that at the end of the day, your maps have some data representatin anyway, so it should be not too difficult to maybe play around with just defining the basic parts of it. then noticing repetitive things or things that are made up of other things and defining higher level composite functions/classes and then seeing if you can do something useful with it. i.e. judge the quality of your API (or in this case technically an embedded domain specific language (EDSL) by if it actually makes your life easier and you find yourself expanding it and having those aha moments, where you realize that you came up with a a neat abstraction that allows you to design a map that normally took a couple hours and now takes 20 minutes.
it might be worth taking a bottom up approach, thinking what is the fundamental unit of your map and going up to composite structures. or in my case in thinking about my experiment spec EDSL, top down approach.
like, what is my end goal?
an experiment spec.
okay, what does it consist of?
well... a name, one or more questions.
okay, name is a string, what is a question?
a question is either a numeric rating question or a text question
what parameters does a rating question have?
and so on...
I like Camlorn's idea. it is really going in the right direction. also your idea about directly attaching events to parts of the map is really thinking right about the possibilities that this approach would open up.
I don't want to give the impression that this is easy. it definitely isn't. It mainly requires a lot of time making some initial EDSL design ideas and testing them out, then throwing them away and going back to the drawing board so to speak.
also you will find that there will eventually emerge several different designs that are mutually incompatible and each have their tradeoffs and you will need to make a choice.
the thing with no design being the best for every circumstance is ultimately why we have a bunch of different programming languages and within those languages, tons of different frameworks and libraries that do the same thing, because there are different approaches you can take and each have pros/cons.
the tile editor is not a bad idea as well as it would allow non-programmers to citizen program themselves a game. this is the approach Sable uses and complete non-programmers have managed to create some really cool things with it during its short alpha this spring. I think it is going to be harder to make and be able to provide less power and versatility compared to an EDSL, but could make a lot of the basic stuff easier.
there is a really nice quote one of my uni professors said when he was introducing linux to us:
"a GUI makes easy things easier, the command line makes hard things possible."
replace commandline with programming and I think it hold up in this situation as well.
So I say go for the tile eitor, but personally I would focus on the programmatic side first and then build a GUI editor on top of those features.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
