Lambda is both a long keyword and the argument list is its own list. You can write a much more concise lambda that looks like this:
(// a b c -> (+ a b c))
With a syntax-transformer like:
(define-syntax //
(lambda (expr)
(define bracket-helper
(lambda (expr) (syntax-case expr ()
[((arg ...) () body0 body ...)
#'(lambda (arg ...) body0 body ...)]
[((arg ...) (hd rst ...) body ...)
(eq? '-> (syntax->datum #'hd))
(bracket-helper #'((arg ...) () rst ... body ...))]
[((arg ...) (hd rst ...) body ...)
(bracket-helper #'((arg ... hd) (rst ...) body ...))])))
(syntax-case expr ()
[(_ body0 body ...)
(bracket-helper #'(() (body0 body ...)))])))
In some lisps I’ve written, I prefer to use the syntax:
(| x y z | (+ x y z))
In vague sympathy with block syntax in smalltalk, but unfortunately in Scheme | is not a valid symbol, since | operates as a sort of quotation mark if you want to create symbols with, for example, spaces in them.
Is valid in Chez, at least. But you can’t export an identifier ‘||’ from an R6RS library.
Chez is really good, though - it provides a lot of extensions to R6RS but in the documentation it always provides a reasonable implementation of each non-standard function if you need to port to another Scheme. It seems like Chez can compile everything these days but I suspect that if, in some fantasy land, I need to port a game to the Switch or iOS, I’ll do better with Gambit, which generates C as an intermediate language.
Think this looks ok now! It was really hard to figure out how to display the jammer area because I only have 16 colors total (no color blending, transparency, etc) but I think this is finally pretty legible: a combination of drawing a border and some palette swapping.
Probably one of the more difficult levels I’ve made, and look how concise it is!
I do think the jammer is a little fiddly occasionally – I might reconsider some of the specifics as I make more levels but I think it’s really powerful and expressive.
I’m also getting a lot better at using geometry to limit what the player can do. I find that’s a pretty important facet in creating a good puzzle in this game.
feels like every time problems happen it relates to trying to move dynamic objects around on the 3d table i use to represent the map. one way or another removing stuff from the table keeps creating some new unpredictable problem.
am considering just divorcing dynamic objects from it, but then i no longer have a fast method for drawing sprites in the correct order
Someone finally put together a little template project using Kawa (a JVM based Scheme) with Libgdx. This is very appealing to me for portability reasons. So I thought why not try and get mecs running in it?
Except Kawa’s record-types (roughly analogous to structs/objects in C) are R7RS record types while Chez Scheme implements R6RS record types. Paradoxically and frustratingly, R7RS record types are actually a small subset of R6RS record types - missing most of the important functionality of R6RS!
More or less the same story is true for syntax transformations. syntax-case is standard in R6RS. While syntax-case is a little unwieldy upon first contact it is a “complete” hygienic macro system in the sense that you can write any sort of goofball hygienic and non-hygienic macro you want with it, freely using the full capabilities of Scheme to write syntax transformers.
R7RS gave up on this system and provides a simpler system called syntax-rules which you cannot use to write non-hygienic macros. This is frustrating to me more on principal than in practice - nonhygienic macros are kind of dumb. But there are things which are a little tricky to express in syntax-rules which are easier to express in syntax-case. Its frustrating that syntax-case is no longer portable!
If I had to guess, it probably has something to do with how you’re iterating over it and when you’re moving/removing items. Be very careful how you’re iterating over a collection if you’re also modifying it at the same time. e.g. if you’re going through sequentially and swap the places of two items, you might process an item twice, or not at all.
yeah, the problems tend to come from timing. i swap the places of items, and if multiple items move at the same time they can mess up and swap places in ways that separate them from their internal coordinates. once that happens things tend to get bad.
i think i’m gonna try dropping the swapping by removing all moving things from the 3d table. i think i just solved the drawing stuff too. my idea isn’t very efficient, but i don’t think pico-8 will take that huge of a hit from it with how few moving objects i’m gonna have.
This is what 38 finished levels looks like (with some unfinished trash in the bottom right)! Have 10 more levels ideas in my Google doc that I need to try still, plus I need to explore a couple mechanics I know are deeper.
I should probably have a testing round at some point, but that requires me to make a sequence for these levels that actually teaches you things. 1-20 are pretty solid but it gets a little eclectic after that.
It’s tricky to just make a bunch of levels in order, because sometimes the idea you had ends up being much more complicated than you expected. And it’s tricky to get a smooth curve when you reorder them, because some levels assume you already know certain mechanics and you need to make sure there’s an level that forces the player to learn that mechanic before that.
Right now it’s just a linear sequence of levels. My mechanics are built so they work really well in tandem, so that sort of layering one mechanic at at time approach makes sense in a linear progression I think. But it can be ambiguous to the player whether the level they want to skip is trying to teach them a core skill or not.
Maybe I just need to make a few unskippable levels that block progress to all the levels after them. Or at least mark them as being important in some way.
game seems to behave somewhat solidly again now that moving objects are divorced from the map grid. next two things are working on the attack effect and making this enemy do its fighting behaviors.
feeling kinda proud cause this is already the most elaborate game i’ve worked
The looming deadline is as good a reason to clamp down on my scope spread as any. Gonna try to sew up the unfinished edges this weekend so that you all can play something that resembles a finished game.
I’m trying to get to 10 different waves of monsters
I’ve got several ideas I just don’t have time to work on, and probably they are more interesting than what i’m making, but it’s only thru the process of working that i seem to get ideas at all.
i am not finishing anything in time but i have an idea of the exact amount of work i’ll need to do to finish this which means i scoped it correctly and might have something by the end of march if i focus more than i have been (which is like, 1 hour a week)
