itch.io

Was it by chance the eval results clearing behavior that threw you off? Because that bites me constantly and I'm not sure how to solve it. I wanted to have the results be copyable with the mouse but to disappear on any keypress, but when I'm working quickly it always results in me accidentally trying to do something before it is cleared and it messes me up every time.

Oh, and this is a good introductory video explaining the NES audio channels:

(Actually, I think I'll link this in the actual project page!)

Thanks! Yeah I suppose I just like dove right in there... The first and most important part of copying a song is just to be able to hear it well... I use a program called NSFPlay that lets you mute tracks and slow them way down while preserving the quality, and it even shows a little keyboard with colored dots showing you where all the notes are.

I had actually made the Lisp previously because I had a specific need for it - I wanted a more slimmed down version of Clojure that was native to the browser for educational purposes. But when I heard about the game jam I suddenly got really excited at the thought of "testing" it to see if it could actually work! To be honest, I might not have even bothered otherwise.

I want to address an elephant in the room, just to provide an acknowledgement that this project is, well, a Lisp only on the surface. Underneath, it's JavaScript, and it's not always obvious where JavaScript ends and Lisp begins.

Could you say the same thing about Clojure? Elana Hashman calls Clojure her "favorite Java program". In my defense, Python is in C. Does that mean you're programming in C?

But no... it's kind of more than that. The entire audio engine is in JavaScript. And the Lisp is implemented as a poorly optimized tree-walk interpreter made for educational purposes, so sometimes things are painfully slow, and... well fine! Just compile it to JavaScript code and run it from there! I spend a certain amount of time wondering if it's cheating.

I wouldn't expect anyone to say, "Wait a minute... this isn't really a Lisp, you phony! It's an interpreter running in JavaScript! Faker!". But I just figure I should be transparent about what this really is. At times I admittedly wonder if I'm just writing JavaScript via a Lisp front end.

Is there really a difference? It could simply be a result of the fact that I'm developing the language at the same time as the game, which is rather unusual but gives a certain advantage. Perhaps I'm just inviting you to ponder, because it's a unique stack of technology that hasn't really been used before.

I just implemented vibrato in the music engine and it sounds amazing! If things keep going like this, there really won't be any game, just a kickass NES audio emulator.

Here is a demo I just made of what will be the intro music: https://functional.cafe/@BTowersCoding/111293828453032032

The funny part of the experience was how naively I went into it. This is a running theme with me... there's usually a "right" way, which is way beyond my grasp, and then there's what the South Park creators used to call "dummy mode".

I knew that the idea was to use a sine wave to adjust the frequency of the note. But I didn't have any idea how much to adjust it, so when I played the first attempt, it sounded like... FM distortion. Surely I wasn't even on the right track.

Out of curiosity, I started changing the values. It sounded even weirder! Almost like the "Blaster Beam" used in the Star Trek movie for the Klingon/V'ger theme. Totally sick, but unfortunately not what I was intending at all. I was going for a beautiful flute-like sound like in the Legend of Zelda title theme.

Then I entered in a completely different value (for the same parameter), and... WHAT?!? It sounded sort of like vibrato! Could it be I was just off by a factor of 1000?

You be the judge (whoever you are...), listen to the demo above and tell me if I succeeded.

To return to the actual game mechanics for just a moment... I kind of realized that roads are not so essential to my gameplay. Sure, we associate much of the city-simulator experience with building roads - but that's what I would like to challenge (just as I would if designing a real city)!

That's another interesting area where the time limit influences the creative thrust of the project - it forces me to think, "what can I get away with skipping, that will give me a better chance of expressing my idea?". I could spend the rest of the week making a program that lets you build roads, or I could get to the heart of my mechanics, which begins with building a factory:

(Yes, I took the icon from SimCity 2000. But maybe it could produce fewer emissions?)

There, fixed it. Green production! Because if we want the next generation to even have a chance, we've got to stop destroying everything in our path.

So we have a decidedly road-free city. I'll just say that the buildings are individually solar powered, so there will be no power plants necessary, or power lines.

So just to reiterate - the game is not meant to be about creatively designing the city and its infrastructure. The city building aspect is purely about choosing how many of each of the categories of buildings are present in order to facilitate your production strategy. Where they happen to be placed is irrelevant... for now, anyway. I can revisit this aspect once I have a game... and fortunately, development does not need to end when the Jam ends.

Wow! I did a ton of work on the audio engine, and it's working much better than I expected - in fact, I'm kind of in disbelief that it actually works! Here's a brief summary.

At the start of the Jam, I had implemented the triangle wave and the noise channel and done some basic sequencing in a rather strange way, by creating an audio buffer for each note and passing them to the Web Audio API each with its appropriate start time. It actually works, and plays coherent audio just by stuffing the entire score through like that.

But then, say I want to render an audio file... Since it's in several hundred buffers the only way would be to capture everything as a separate media source and I didn't want to do that. Moreover, the NES doesn't work that way, and having each note as its own buffer resulted in them overlapping and producing an inauthentic sound. What I wanted to do was have a single buffer for each channel, so they could be mixed and rendered appropriately. I also hadn't even started the pulse channels for the leads.

This was all implemented in the last couple of days, and I'm quite surprised how well it came together!

I'm so pleased with it that I'm not at all concerned that this is all orthogonal to the development of a game. But is it? Mario Paint is arguably a game. Sure, it also contains art and animation elements as well as music creation, but how about Little Sound DJ? Is that not a game? I'm not even sure whether I care. I'm riding the wave, and so far have exceeded my expectations.

Ultimately, I think I'll avoid being disingenuous by trying to stretch the definition of a game, and instead just take the position that a music engine is an essential part of developing a game, and if that does turn out to be all that I get to, so be it. The point of a game jam is that there is limited time and limitless areas of potential focus, so in a sense it represents a no-win scenario. What the developer chooses to emphasize and neglect becomes one of the primary forms of expression.

I have a map! I also got to take advantage of another application I have called mecca-pix, which I used to create the floor tiles (I guess that would be considered the crust?). It's a thing I made that takes a bitmap image and converts it to SVG, and lets you quantize the colors so that it can be expressed in a small number of paths.

So now we need some kind of toolbox, and I'll start by making a button for placing roads. But before I get too far, I have to implement the interactivity.

The way I've done this before is to add a second layer of SVG squares that is *invisible* and just acts as click/hover targets.

Edit: This may not be necessary... I think the reason it was needed for my interactive graph was because I needed the mouse  targets to be *offset* from the actual grid lines, since the targets were the *intersections*. But in this situation the targets line up to the actual squares.

I'm going to follow SimCity BuildIt's way of dealing with infrastructure, which is much simpler than SimCity 2000. Basically, the roads also carry power and water, making it so you don't have to mess with pipes or power lines (which always need to go along the roads anyway). All you need to do is put your buildings along a road.

Now, if this were my ideal city, it wouldn't have any roads... only bike paths.

It's awfully pretentious, but I got tired of calling it "my Lisp interpreter" and wanted to name the repo something else. Why is it that programming languages are so often given names that have nothing to do with anything?

I never intended my language to be used in production, in any sense of the word. It was made for doing coding exercises to learn Clojure, kind of what BSL (Beginning Student Language) is to Racket. But when I heard about this game jam a couple months ago, I suddenly got really excited and decided to change course. And there's still a good chance that this won't succeed... but I immediately realized that by going through the process of getting my Lisp ready to make a game with, it would put me on a very productive course in many ways.

For one thing, I would need to think about how my language would be packaged and used in another project. Because I wouldn't want to have to copy the entire contents of the project into another project... no, that would be silly. But unfortunately that's what I'm still gonna do unless I can figure out JavaScript's module systems. I managed to create an NPM package of the core language, but certain things don't seem to work. I had to disable ratio support (the project uses Fraction-js but for some reason it would not build with that included presumably because of some discrepancy in the way modules work in Vite and whatever else I tried to use), and it ended up causing other issues which I'm having trouble remembering because it was really frustrating so I just said "Fine, I'll just copy over the entire interpreter and build the game on top of it". So there we are. Maybe somebody smarter than me will help me figure it out some day. In the meantime, it's probably fine, because I'll still be able to build and deploy the game when it's done. I think.

The first thing I wanted to do was create a music engine. Too many people go to make games without giving any thought to the music, and in my mind, the music is the best part, so I'm going to do the opposite and focus on that first. If worst comes to worst, there will be no game... but at least there will be something fun to listen to!

And I'm not talking about playing an mp3. No.... that would be cheating (much like using an existing programming language, or an existing game engine)! And I'm not even talking about building a sample sequencer (which was the first thing I did), because I will not be happy unless I'm actually synthesizing the notes myself, using nothing but mathematics describing pure sound waves.

Specifically, I'm emulating the 4 channels of the NES, which lives in a little plugin called bobbi-lisp-audio. Since my Lisp runs on top of JavaScript, it has native access to the Web Audio API, which I can just pass an audio buffer to, along with the time the note is to play, and voilà! A retro music engine for the web.

The other big thing I would need to think of is graphics. I'm most familiar with SVG, so I decided to make yet another plugin library, bobbi-lisp-svg. The benefit of this is interactivity - by having the ability to add click events, etc. to SVG elements, I don't need to implement any other kind of cursor tracking. I've done this before, implementing fairly complex interactive graphs entirely in SVG with good results.

So why am I still feeling unprepared? Well, it turns out, I've never really thought of making a game before. Well, that's kind of a total lie... I've thought about it ever since I was a kid and my parents let me have a PC but not a Nintendo, and dreamed of making my own version of Super Mario Bros. that I could run on the computer. But the truth is... and to some this may seem like heresy... but I don't really like games. There, I said it. I like boring things, like making programming languages, composing music, and making pixel art, and game dev just happens to require a synthesis of these things.

But there is one game franchise that got quite a bit of my attention over the years. And it happens to be something that even my pedagogical, slow-ass interpreted programming language could handle. I'm talking about SimCity. But not even the good ones...

Ok, here's where this idea starts to get really weird. Which might end up being a mistake, because making something like SimCity 2000 would actually be really cool. But I'm not going to do that (I think). I'm going to make a game based on the game that killed the SimCity franchise, the mobile, timer-based, FarmVille inspired title, SimCity BuildIt. Just because I'm curious what a game with those disgusting freemium mechanics designed to exploit your psychology would be like if it, you know... wasn't evil. To learn more about this, you can read my introductory pitch.

The city-building aspect of the game is downplayed in this paradigm. The real "action" and challenge of the game comes down to time management. I liked that part of the game - basically, time is the actual capital, the currency used to develop your city. Unlike previous versions, where you have a certain budget from taxes that you use to purchase buildings, the buildings are actually free to produce - but to upgrade them, you have to produce materials in your factories, and use the materials to produce items for your stores. I found that aspect refreshing. The trick is having a sufficiently complex and finely tuned mathematical model, much like a slot machine, to be sustainably engaging. To this end, I have documented and studied the data model of SimCity BuildIt and may borrow from it heavily, though I do not plan on using any actual assets from the game, as pretty as they are.

So there we have it. So what are the next steps? While I've done significant work already in preparation, I've taken pains not to cheat by doing any work on the game itself, because I want the final product to be representative of the work done within the time period of the Jam. But I need to make a map. Specifically, an isometric map. This should be fun... I hope. Even if I only get as far as creating a thing where you can build things by plopping roads and buildings down on the map, I'll feel like I accomplished something.

As long as it has a kickass music score, that is.

Project repo: https://codeberg.org/bobbicodes/SimLispy