On June 14, we celebrate my wife’s birthday. And even though we have no sentiment towards fireworks, I somehow knew the night won’t be quiet, and we’ll get our dose of flashes over our heads. Last year, there was an air strike on Kyiv right on her birthday. This year, I felt it would be just the same, since more than a week had passed since the last major strike on the city. And russians have already accumulated a stockpile of drones and missiles.

In retrospect, I understand that the strike that night was inevitable. Putin called Trump to congratulate him on his birthday. By striking earlier, he could compromise the call. But at the same time, he had to strike before the start of the G7 the next day as a show of strength. The oil refineries and storage facilities deep inside russia burn daily, occupied territories and the south are facing fuel shortages, which is not a good agenda for the start of G7.

So he decided that a powerful drone and missile strike on the capital, targeting prominent cultural locations including a UNESCO heritage site, would be a good idea. Something to change the agenda, so to speak.

Half-expecting the strike, we decided to skip the restaurant and opted for food delivery. We still had the aftertaste of our experience of a sudden air raid alert in the middle of a restaurant visit. The establishment was closed in an emergency, and we hurried home carrying boxes with our unfinished meal while listening to explosions and drones flying above our heads. (It was only a 10-minute walk home, but these 10 minutes felt like eternity.)

This time, we can enjoy the food in the relative safety of our home. I saved the bottle of wine for the night, so when the first missiles all of a sudden started to rain on the city, at least we could have a glass of wine to relieve the stress a little.

The hypersonic missiles were accompanied by the ballistic missiles, followed by cruise missiles and hundreds of drones.

So here I am, standing on my balcony with a glass of wine and opening windows wide (to reduce the chance of shattering in case of a nearby explosion). And I see a russian cruise missile flying over my city.

Well, the missile itself is not really visible in the night sky. It reveals itself by dispersing flares when it enters a potential air defence sector. So I see the blackness of the missile cruising low and spreading bright flares in pairs left and right every second or so. It glides out of my view behind apartment blocks.

At the same time, I hear a roaring sound of an approaching jet engine. It was another cruise missile entering the city from a different angle.

The roar is suddenly abridged after a short burst from a nearby point defence flak (could be a Skynex, a Gepard, or maybe even a Tunguska). The missile ended up in an explosion, painting the sky red.

I felt a powerful shockwave hitting my skin like a sudden blow of hot desert wind. And for a moment I was afraid for the glassware I was holding in my hand - so powerful was the explosion. Now was the perfect time to refill the glass.

The explosions continued through the night, and only at dawn the cacophony contracted, with only a few drones still buzzing over the city.

Finally, we can put the kid to bed.

By that time, it was clear that it was a show-off terror attack targeting primarily civilian objects - multiple apartment blocks, houses, markets, and a school…

But this time the emphasis was on cultural sites - museums, books, one of the oldest film studios in Ukraine… But the most prominent was Kyiv-Pechersk Lavra monastery, a historic site dating back almost a 1000 years. The roof of one of the buildings of the complex was set ablaze by a Shahed drone.

Moscovites are neobarbarians of the 21st century.

Not only have they appropriated our history, but they have also taken enormous effort in wiping out anything that contradicts their canonical view of events, perverted by centuries of khans, tsars, general secretaries, and now putin. And a cave complex with churches and libraries created by monks in the 11th century, when there was nothing but a swamp in place of moscow, is a standing reminder that the core myth of the russian empire is hollow and lacks any substance.

Without Lavra they have no myth. And without myth they have no empire.

But all empires come to an end sooner or later. Maybe we are witnessing the last struggle to resurrect a failing myth of a fading empire - an empire that already crashed several times and yet refuses to die in history, grabbing all it can with its bloody hands while sinking into the abyss. An undead zombie with rotten flesh is trying to show the world that it is still alive and full of energy.

And as a true zombie, russia has no vision of the future, only the glimmers of the “glorious” bloody past. That is why putin always talks about years long gone, as if he tries to find some stable ground in the smelly swamp of contradictory myths that russian history has become.

The real moscovite history starts with Andrey Bogolubsky, who sacked Kyiv in 12th century, killing many inhabitants, stealing gold and icons from churches, burning books… The vandal is canonized by the russian orthodox church now, a true russian hero.

Then moscovites swore allegiance to the Mongols while the latter burned Kyiv and Lavra to the ground.

Centuries later, there were russian orthodox church agents sent by Peter the Great to set Lavra library ablaze - to get rid of what’s left of the real history and what might contradict the myth of the empire he is about to build.

Then the commies, following their scorched-earth tactics, blew up Lavra in 1941 after the Germans occupied the city.

It is nothing new. Putin continues the proud lineage of barbarism that lasted for centuries. A true neobarbarian of the 21st century.

So in the timespan of 4 hours after midnight, we could hear hundreds of explosions, distant and close, from a wide range of munitions:

• a medium-range ballistic missile with MIRV

• Zircon hypersonic cruise missiles

• Kinzhal aeroballistic missiles

• land-based Iskander ballistic missiles

• sea-based Kalibr cruise missiles

• land-based Iskander-K cruise missiles

• air-launched Kh-101 and Kh-69 cruise missiles

• various long-range attack drones

These totaled to almost 100 various missiles and 600 drones. Hardly a precursor for a good night’s sleep. The kid lay down on the floor near the wall, listening to the lullabies of the last four years.

It is another tragic and grim morning here in Kyiv. Neither my wife nor I has any energy to cook a meal… But even in the darkest moments, life continues - at least for the ones of us who survived. The restaurants and cafes wipe the ash from the morning fires, some of them clear the broken glass and put plywood instead, and go on with their business.

Despite the devastation, the food delivery works still. You can always count on a fresh-cooked meal from a neighbourhood restaurant!

The resulting explosions could be heard through the night, so we didn’t get much sleep. Particularly close missile explosions created shockwaves, shaking windows and slamming doors inside our apartment. This time, our neighbourhood was not the lucky one - multiple buildings were damaged. One Kh-101 cruise missile hit an apartment block a couple of kilometers away and caused the collapse of a whole section, causing the death of 24 people (including 3 kids) and injury of 48 more.

By the time the dust settled over the rubble of fragmented bricks and concrete, more than 1500 drones and almost 60 missiles were detected. Maybe not the biggest attack in terms of missiles used - we’ve seen multiple attacks with 100+ missiles targeting only Kyiv. But certainly the biggest in terms of the quantity of munitions. And probably the biggest in terms of total explosives delivered in the package. Most of these drones have 50-100kg warheads, so the total might match the warheads of 200-300 missiles, if not their kinetic energy. That tells us a lot about the growing role of long-range suicide drones in modern warfare.

The war claimed more victims and continues to escalate. The “dictatorship club” is currently looking for ways to reassert itself and form the new multi-polar world order. And that means only more wars and misery in the future.

And as I predicted in my mid-winter post, the hits on Ukrainian Energy infrastructure will result in retaliatory strikes on RuZZias oil facilities and tankers. As we could see recently in Tuapse, Perm, Primorsk, Ust-Luga and other places.

As it turns out, oil products burn rather well.

This summer might be hotter than ruZZians ever wished for.

And a car battery. I pulled it out of my car and brought it into the apartment just before the arctic air and the following ruzzian attacks. Not an ideal solution, given the hazardous gases it can emit, but it is a potential backup option during long outages. I can connect that battery to the solar port of one of my power stations and recuperate some additional energy just in case.

Life right now is fully governed by the power availability… First, you save any energy you can while waiting for a random window of opportunity. Then, it is a fast-paced struggle to get the maximum out of whatever electricity you have.

Hold fast and keep your power banks charged!

Drones have passed right above our apartment block so many times that it was not something unusual. But this time the drone loitered especially low. The buzz got louder until it suddenly turned into a heavy explosion. The air was violently disturbed by the shockwave as I saw a sinister red glow right above my building. The sound of falling debris followed shortly afterward. I instantly realized that it was a hit - either at our apartment block or somewhere really close.

The kid was seriously startled this time, even though it was not his first explosion - he’s already experienced thousands by now. But there was certainly something different about this one that scared him so badly.

Reading the newsfeed, I realized that the drone hit the adjacent apartment block, and not only that, it hit the same floor as ours. So it was a near miss for us.

Our building was really lucky this time - ruzzians struck our neighbours from the opposite side, and we were spared from most of the shockwave. Even all the windows survived this time. That can’t be said about many buildings in the proximity that got glass and sometimes whole window frames knocked out by the explosion. And that is all amid dropping freezing temperatures.

My friend, who lives nearby, had his balcony windows shattered. He was getting some plywood and other materials from volunteers as I was chatting with him in the morning.

So now I can see a lot of plywood instead of glass in windows in our neighbourhood. Well… Better dark than cold. It drops below -20C at night these days. Winter is coming.

I can’t say it was unexpected. Ruzzians have been waiting for cold weather since the winter of 2022, and we were lucky to have relatively mild winters for 3 years in a row. But any luck eventually runs out, and even with a globally warming climate, we got the winter of all winters. With freezing temperatures we haven’t seen in decades. Something I vaguely remember from my childhood - a lot of ice, piles of snow, and excruciating freezing cold.

It might have been a beautiful sight and a perfect opportunity to finally get out the sleds rusting for many years in the warehouse. But the freezing arctic air is not the only thing that came from the north-east. What followed was a storm of ruzzian drones and missiles raining down on the city, targeting cogeneration stations, and plunging us into complete freezing darkness.

By the next morning we were in complete shutdown - no heat, no electricity, no water… Also icy roads and prospects of temperature droping below -20C already this night.

As I’m typing this on my typewriter, there is still no light or heating, and the temperature inside my apartment inescapably crawls down.

The Arctic Survival Challenge Begins!

But war never changes. It is exactly the same now.

We also refused to believe that the war is here, even while ruzzian forces were deploying all over Crimea, annexing the peninsula, and well-armed squads of “people of Donbas”, speaking with a suspiciously ruzzian accent, infiltrated from Crimea to the Donetsk region.

Maybe it is human nature to hope for the best. I thought the international order is strong enough and there could be no major war in Europe in 21th century. But the war is not based on hope; it follows its own twisted logic. And eventually bombs, missiles, and drones blew up your naive dreams in little pieces.

War never changes.

Yet, I still have that feeling that this is just a fever dream, and the explosions I see and hear are nothing but sparks of neurons in my brain. It has been almost 4 years, but my brain still refuses to accept the reality. The war really has that somnambulistic quality.

Just like in a dream, it is really hard to track time and place. Sometimes I struggle to pinpoint events on the timeline. There is a fault that splits it in half.

The world before the war is like memories of a movie I’d seen, but at least I can place them in order.

And the world after is just a soup of events without proper timing. It is like a random noise out of constant air raids, explosions, and blackouts, plunging me into a state of constant stress and insomnia, and engulfing reality into a fuzzy and strange dreamscape-like limbo. There is no yesterday or tomorrow. There are no plans, cause any plan I might have always breaks at another air raid or blackout. At some point, you just give up and leave all this planning to someone who actually has the future. I can’t catch a break. There is only grinding in short gaps between power outages and the next air raid on the city.

The time really feels out of joint.

Well… At least it felt like it.

Bring Me Bluetooth!

It all started with another power outage, which happens frequently these days.

Everything but the laptop went black - the lights, my second display, and a KVM switch.

In a moment, the studio lights fell back to the batteries, illuminating the room in an eerie red-blue glow. The second screen is something I can manage without, but with the KVM out, I lost my mouse and keyboard.

The mouse is an easy one, with a simple switch to the Bluetooth connection. But this is not an option with my wired mechanical keyboard. I had no desire to be lost in the cable jungle behind my table. How can I locate that particular USB cable in low-light conditions and then untangle it so it can reach the laptop directly?

Luckily, I had a wireless Varmilo Minilo VXT67 nearby and could connect it directly to the laptop, bypassing the KVM.

Here Comes Varmilo

So I connected the keyboard over Bluetooth. Everything was fine until I began using it.

The system started to act weird. In fact, it behaved somewhat like an unfortunate keyboard specimen I spilled my tea on back in 2003. It was producing random keystrokes even while I was not touching it. I was puzzled and confused - I couldn’t remember spilling anything on this one.

I disconnected and reconnected it again. Same result. I rebooted the system. No fix. The strange behavior continued. Every time I started to do something with the system, the screen went crazy, pulling the GNOME launcher, switching the apps, tabbing between active UI elements, and sometimes typing in some random numbers…

The Signals

Curious… Maybe I was hacked, and that is a practical joke someone is playing on me? But then, these strange things were happening only when the keyboard was connected and I was using it. So it is not about the system, but the keyboard.

Once in a while, the focus would travel all over the active window and end up on a text field. A second later, I can see numbers filling in - 12321123221… But not for long, faster than I can read them, it would switch the app, change the keyboard layout, and show the GNOME launch menu… Triggered three times in a row…

Hm… Is that an alien civilization trying to communicate with me in cryptic form? An intergalactic Aresibo message accidentally received by my keyboard and transmitted to me over Bluetooth?

I was at the point when my eye started to twitch, and I was ready to throw my expensive mechanical keyboard right into the wall, when I finally saw the pattern.

The numbers! They are not random! They are always the same - 12321123221… Following by the app switch, then a keyboard layout change… Then the GNOME launch menu… Three more times…

And then I caught a starting trigger for all of that. It always started the moment I touched the Windows button.

Wait a minute… It is a freaking MACRO that I’m triggering!

The Macro

It seems that the last time I’d been setting up the Bluetooth connection, I was confused about the actual keyboard controls. I was used to the full-size or 80% TKL layouts, but this particular Varmilo is a 67-key Exploded model.

Probably, I inadvertently enabled the macro recording while trying to establish a Bluetooth connection! These cryptic 12321123221 are nothing but my attempts to select a proper Bluetooth device with Fn+1/2/3… Only on this particular keyboard, it is Fn+Q/W/E instead (somehow, the selected Bluetooth device is highlighted by the glowing 1/2/3 keys, but selected with Q/W/E underneath).

Also, I recorded a bunch of shortcuts around it as well - like app switches, layout selection, some Tabs, launcher activations, cursor motions… Quite a few keystrokes, I would say!

And these were replayed every time I touched the Windows key, creating a poltergeist illusion and almost giving me a nervous breakdown.

Finally! The mystery is solved!

Also, I learned the special shortcuts for this Varmilo model.

RTFM.

We’ve been harassed by ruzzian Shaheds for more than 2 years, and by now these drones are so mundane that we almost pay no attention to them. Sometimes, these attacks occur daily, in multiple waves that start in the evening and continue throughout the night. And when you hear the buzzing of drones and shooting all the time, you almost stop noticing and pay attention only when explosions approach too close for comfort (usually right over the head).

A single drone might not be as dangerous as a cruise or ballistic missile. These things are really terrifying; they travel fast, hit hard, and carry a half-ton warhead. Shahed drones are relatively slow, but still carry a 90kg thermobaric warhead. The main problem is that there are so many more of them. When ruzzians launch 500 drones, they carry a punch of almost 100 cruise missiles. And drones are significantly cheaper.

Even a single unlucky hit by a drone can do a lot of damage.

Yesterday, the attack on the city was limited in scale. The night before, there were hundreds of drones and dozens of missiles. I couldn’t sleep because of the loud explosions happening all around.

Yesterday, a few drones sneaked into the city on extremely low altitude. I heard explosions, but they were rather distant. Nothing too close to get me worried. But the relative calmness was misleading, and that night, more people died in our city than the night before.

A ruzzian drone hit an apartment building, killing 3 people and injuring 26 more, including 7 kids. The resulting fire spreaded so fast, the inhabitants had to jump out of windows to escape the burning inferno.

The explosion happened just across my parents-in-law’s apartment, knocking out their windows. Now pieces of plywood occupy the places where glass used to be. And the folks say they are not even sure they have to install the glass back, expecting more strikes to come.

This is a sign of a city in the middle of a war - all over the place, you can see windows with plywood instead of glass.

Such is another ballistic missile strike on Kyiv. The second one this week.

The last one happened only 3 days prior and included a whole bunch of ballistic missiles, cruise missiles, and drones. Explosions illuminated the sky throughout the night and up to the next morning. Russians were hitting critical infrastructure all over the city, and by 9 AM, the electricity was gone, and the hot water soon followed.

And when the hot water supply was restored, they hit again. It was 4 in the morning.

This time, incoming missiles landed in my part of the city. That was loud. They left huge craters and caused significant damage in the neighborhoods.

One of the craters. Nearby apartment buildings are lucky to survive - it seems like the missile missed them by some 20 meters (photo by the National Police).

As of now, 2 people are dead, and a dozen more are injured. The city is recovering from another awful night.

They say “no battle plan survives contact with the enemy.” But as I know now, no single plan survives the touch of war.

As you know, I’m developing Collider.JAM Game Framework to bring back the joy of programming in the dependency-intoxicated JavaScript world and demonstrate that web-first game development is not only possible, but viable and might even be superior in game jamming, creative coding and indie development.

My plan for the framework was to make a series of Development Releases to shape and stabilize the APIs before rolling out any “stable” releases people can rely on. Initially, it went very well with releases DR1 through DR11. I even had the feeling that we are almost there. Early Development Releases were chaotic with a lot of breaking changes. Somewhere by DR9 or 10 I’d noticed almost no compatibility issues, and it was a pleasant revelation to see DR11 running a game developed for DR8 with no changes whatsoever. This was the stability I was looking for!

But the real world is not as stable as our APIs. And the war started.

Since the russian invasion, I’ve learned that a black swan is not a one-off event. Black swans could arrive in flocks. And that is not only black swans you have to worry about, but also black helicopters, black fighter jets, black missiles, and black drones buzzing at night.

The war jolted the city to its core. Missile strikes, drone strikes, burned houses, apartment buildings, stores and warehouses, disruption of payment systems, shortages of food and fuel, blackouts, disruptions of heating and water supply… A fighter jet hit by a missile and falling to the ground in myriad burning pieces (the explosion was so loud that I honestly thought a missile actually hit my apartment building). It is a rollercoaster of events happening 24/7. No day-offs, no holidays, no sick leaves…

So I’ve struggled to keep up with my plans. But I was restless to do something about it. A couple of months into the war, I’d finally found my balance and got an inspiration. While I was no longer able to do both indie development and make regular updates to the game framework, I still could produce working snapshots based on my game roadmaps. While not a dedicated effort to develop the framework, I can still improve it while creating my games.

At this point, I’ve got an idea to develop a series of games closely related to my war experience. It is a Z-Alert series (kind of a pun on Red Alert, only with a Z, which is a symbol of the invading ruzzian army), and the leading game is going to be Z-Alert: Anti-Ballistix, which I’m creating right now exclusively during air raid alerts (kind of a personal challenge).

War Release 1 was out earlier this year and accumulated all the changes I’ve made to Collider.JAM during the war. The changelog for this release is huge and diverse. It is quite obvious that there was no single roadmap I was following, just random changes, fixes, and improvements here and there.

War Release 2 ended up just the same. But with more breaking changes this time. I’ve figured that it is a good opportunity to streamline the APIs while I’m still in this havoc of events.

I’m planning to create a lot of documentation and video tutorials. And I want the contracts and conventions to be stable and reliable, so that the materials stay relevant for a long time. You can expect more breaking changes in the upcoming WR3 and WR4, but very stable APIs in later releases.

I believe we’ve captured the gist of it and could produce a platform that will be stable and compatible for years to come. Look for the upcoming releases. They will be truly awesome!

Sadly, it is just yet another kludge in the ivory tower of software bloat. It is like all software is gravitating towards a single point of singularity, with all existing platforms collapsing into an incomprehensible black hole, sucking in our entire civilization.

We might know well by now why the galaxy is silent. Maybe all other civilizations went extinct after growing their software into a giant planet-consuming spaghetti-code monster nobody knew how to deal with. An unmaintainable blob of bloatware consuming more power than even a Dyson swarm can provide.

I feel the Great Filter is inevitably approaching, and it is going to be binary.

There was no real point in Windows Subsystem for Linux in the first place, except for desperate attempts by Microsoft to stay relevant in the cloud age. To take two huge and very different systems with all their bugs and idiosyncrasies, merge them (creating even more bugs and idiosyncrasies along the way), and call it progress? I call it insanity. Now only with FreeBSD.

Suddenly, a bright flash illuminated the October sky over the city, and interceptor missiles lacerated the heavy clouds. The glistering balls of rocket fire were diving into the low-hanging cloud ceiling, briefly highlighting the overcast skies. The roar of ascending engines followed. Then all hell broke loose.

Enormous explosions were shaking the city. More ballistic missiles came in. They were met with more interceptors. Hundreds of drones were advancing into the city from all sides. All targeting critical infrastructure.

I saw multiple flashes in the area of the power station and water facilities. They were followed by blue glow twinkling above the skyline. A few moments later, the whole city plunged into complete darkness. It spread as far as I can see from my window, except for a lonely traffic light that somehow found the energy to blink into the darkest night.

Another total blackout started. No electricity. No water. No heating. Just like we had back in the Fall of 2022.

As I’m writing this post 16 hours later, we finally got electricity back. Tap water followed - a very welcome improvement, since all we had were 2 full toilet tanks, a 12-liter aqua filter tank, and whatever water I’d managed to accumulate in the tub after the strikes while it was still running. Hot water is still missing though…

Some parts of the city are still without power. The emergency repair crews are working around the clock to fix the damage and bring the electrical grid back to full coverage.

And that is just the first major strike on Kyiv’s energy infrastructure this season. I’m sure that many more dark nights and bleak days will follow, as it was back in 2022, 2023, and 2024.

Missile Summer turning into Ballistic Fall.

However, it is no longer 2022, when Ukraine didn’t have any means for long-range strikes, or 2024, when Ukraine refrained from striking deep into ruzzia.

Now, these strikes will not be left without a response. When your country is a gas station, it is unwise to start a fire at the neighbour’s house.

Wait and see the bright torches of burning oil illuminating dull and neglected blocks of Soviet-era concrete apartment buildings all up to the Ural Mountains and beyond.

Hold fast and keep your power banks charged.

However, in virtual life, as well as in the real one, monocultures are good only for the short-term profit, but could be very dangerous in the long run. The whole idea that there is a single unified way of computing is fundamentally flawed (yet, we keep inventing silver bullets over and over again).

There should be efforts to preserve and modernize alternative computing models - the likes of Forth and PostScript, Smalltalk and TCL.

ReBasic is my humble effort to keep the fire of the long-forgotten interactive line-by-line model of programming that powered the entire 8-bit microcomputers era. When there was no IDE, no dependency management, no build pipelines… Just you, the machine blinking the “READY…” message, and a universe of possibilities hidden behind that simple interactive model.

I finally pushed the version 0.4 that was baking the whole summer and most of September. I’m very proud of the result - we’ve playtested it with JetPakBoy and it really delivers the desired 80s retro-feel.

There are still features to be desired (like missing sound and documentation for some critical components). But overall, it is a solid BASIC reimplementation on the modern web that is usable and pretty extensively documented. You have online help on any command right in the console. There is also a bunch of pages available, describing particular aspects in great detail.

ReBasic, the way it is today, could already play a role in introduction to programming - it is very accessible, easy to use, and mostly compatible with a huge body of 8-bit era BASIC code available online and in the old books.

Now I switch my focus back to Collider.JAM and will be returning back to ReBasic only sporadically to introduce a small feature, provide sample code or extend documentation as we explore the BASIC universe further together with JetPakBoy.

Late evening, hundreds of drones started their attack on Kyiv in multiple waves. I could hear the annoying buzzing of drone engines accompanied by bursts of anti-aircraft fire and occasional explosions after lucky hits.

Then, the decibel level suddenly peaked.

One moment, it was a dark, moonless night, then a bright light from the outside filled the room.

I sneaked out through the window to gaze on a series of missiles launched one by one into the skies over the city. With their bright-shining engines leaving smoky trails, the missiles were rising high up to intercept the incoming targets.

I instantly realized that we are under ballistic attack.

The launch was followed by a characteristic chorus of rocket engines, which soon was accompanied by powerful explosions when the initial strike package was met high above.

The first wave of ballistic missiles was followed by another one. Then, yet another one. Soon, radars detected the supersonic MiG-31K launching aeroballistic missiles towards us.

The attack was very intense and well-coordinated. Powerful explosions swept throughout the city.

Then, as suddenly as it started, it was over. But not quite, since ruZZian strategic aviation has already launched a bunch of cruise missiles, which were soon expected to enter Ukrainian airspace.

A new wave of explosions came closer to 6 AM. Packs of cruise missiles were entering the city from multiple directions. They were met by interceptors, ascending into the dark blue morning sky.

I saw a cruise missile get intercepted and turned into a pile of burning debris falling in long fiery arcs.

But some of them got through.

We heard powerful blasts closing in, followed by the growing sound of jet engines. A bunch of cruise missiles passed low above towards the city center. The fading sound of jet engines was followed by even more explosions.

And still it was not over. The disturbing buzz of enemy drones could be heard over the city. There were shootings and detonations happening here and there.

It was already 7:30 AM, and yet another air raid alert was triggered by a new wave of drones entering the city. But I was too tired to wait for it to be lifted. The kid, woken by the deafening cruise and ballistic missile strikes, was back sleeping. So I followed suit and went to bed, even though the sleep was occasionally interrupted by nearby blasts.

The attack on the city was repelled only by 9:30 AM, lasting for more than 12 hours.

Today I feel totally exhausted and unable to focus even on the simplest tasks. The overall mood throughout the city is grim, as volunteers and emergency workers are clearing the rubble and digging out dead bodies.

25 people are dead so far, with some still missing.

Missile attacks this summer were especially atrocious - every single time a big apartment building or two are hit.

The bloodiest summer of this war in Kyiv so far.

I was oscillating between good, established options and one of my language experiments.

An established option gives a stable platform and a lot of materials to work with. Platforms like Scratch, Python, Lua, and JavaScript seem to have everything you need - stable implementation and well-documented APIs, a wealth of materials online, versatile tooling, and good support.

The problem is, none of those, except for Scratch, are well-suited in a pedagogical context. And Scratch for us is a done deal - JetPakBoy used it for several years at school and has a pretty good grasp of the platform. So, there was no point in reiterating over a well-studied and understood option.

Then I’ve dived deeper into possible alternatives that might be better suited for learning programming. I’ve looked at BASIC, LOGO, Smalltalk, Etoys, among others…

LOGO could have been a perfect language for programming introduction, but it sadly missed its mark and never gained any real traction in educational circles.

Smalltalk has modern implementations in the form of Squeak, but it is too complex and lacks entry-level examples and tutorials.

BASIC, on the other hand, seemed to be a perfect choice.

It is designed as an introductory programming language and, at some point, became the main language for 8-bit machines. That firmly established it as a perfect language to study first and formed a stable foundation in the form of books and magazine articles.

The main problem with BASIC is that with a variety of 8-bit platforms, it became too fragmented over time. Some archaic syntax idiosyncrasies also don’t help.

The modern dialects, like Blitz Basic and Visual Basic, on the other hand, have moved it too far away from its pedagogical origins into the realm of “professional” programming, thus defying the whole purpose of the original design.

Therefore, for this summer, I’ve resurrected ReBasic - my own effort in bringing the original BASIC retro-feel and direct interactivity into a modern web shell. And I’m happy that recent changes delivered a stable platform that can run examples from classic BASIC books (like the classic Usborne BASIC series) with minimal changes.

This summer, me with JetPakBoy were able to Return to BASIC!

Three hundred drones were attacking Kyiv through the night.

Then, at 4 AM, when the drone attack was mostly repelled, air raid alert lifted, and most people returned to their homes from bomb shelters, ruZZians launched ground-based Kalibr-K cruise missiles from Kursk region. Flying really low over swamps and rivers, the missiles converged on Kyiv from multiple directions and started to hit targets all over the city.

Once again, one missile hit just another apartment building, collapsing a whole section and burring people underneath the rubble.

The blast wave hurled a teenage girl sleeping in her bed and threw her out. She fell from the 9th floor and luckily survived with only a broken leg and minor injuries. Her parents were not that lucky and died under the collapsing concrete.

Many other apartment buildings were damaged by missiles and drones all over the city. But my neighbourhood was spared this time.

UPDATE: 31 dead bodies in total were found after clearing up the debris and rubble.

We had damage nearby before - from falling intercepted cruise missiles and drones. Just a few months before, the falling debris damaged an apartment building across the highway.

But this time it was much closer than before. The falling debris damaged an apartment building on my block, just a few hundred meters away.

A strange thing is that it was not the largest explosion happened recently in the area. We had drones intercepted just right overhead, and the resulting explosions were subjectively much louder. Then I was seeing bright flashes in the skies above and felt the resulting shockwaves passing through my body.

This time, the explosion was not that loud, probably because it happened on the opposite side of the damaged building, shielding me from the shockwave. Then it was followed by the secondary explosions of the falling debris.

5 people were injured by the explosions, with multiple apartments damaged. Luckily, the strike was not followed by a big fire. What started to burn was swiftly localized.

When I’d visited the site the next morning, most of the fallen debris and shattered glass were already cleared with sappers swiping nearby lawns for fallen explosives and submunitions. Workers of the ground-level store were busy clearing up shattered glass inside.

Another busy morning.

There was no other major contender. Smalltalk, which popularized the OO approach in the first place, had never seen general adoption and was confined to niche, self-contained, all-in-one systems. Early Smalltalk implementations by Xerox PARC clearly showed what pervasive object-orientation meant - the world of objects exchanging messages in a persistent environment. No primitive values, no pointers, no operating system… It is a different reality, never appreciated by the tech world, that went in the other direction, trying to superimpose object-oriented elements on top of the existing ecosystem. That is how we got C++, Objective-C, Object Pascal, Visual Basic, and other retro-objectified technologies.

However, the zeitgeist of the era was that OO was the future, and all other programming models were destined to be extinct, swept aside by the superior approach.

The core problem of that worldview was the existing operating systems. They were far from object-oriented. Smalltalk solved that issue by dropping the operating system concept altogether by providing the user with a completely enclosed environment with no need for an OS.

This approach will never work with the traditional computing model that was already built around the existing operating system-app dichotomy. The 90s saw multiple attempts in object-oriented operating system design. It is fascinating, that most of them had the Apple pedigree.

Struggling to revamp the existing Classic MacOS that was showing its age, Apple launched the Pink project later morphed into Taligent Inc. - a joint venture with IBM. It was meant to create an innovative object-oriented operating system and programming environment, but failed to produce a viable product.

Another object-oriented operating system attempt was made by NeXT. The resulting NextStep OS could be considered rather a lucky one, since it still exists, although in a heavily mutated form.

Steve Jobs was fascinated by OO-programming, stating in interviews, that he was so blinded by the GUI during the Xerox PARC demo, he missed other important parts - networking and object-oriented programming. A decade later, he decided to remediate that by taking Objective-C and building an object-oriented application environment.

Retrospectively, Objective-C looks like a weird choice, since we all know that the industry moved forward with C++. But back then, it was not so obvious, and Objective-C looked much more attractive in the NeXT context. Fully backward-compatible with C and with Smalltalk-like dynamic message dispatch, it seemed more suitable for NextStep object-oriented tools like Interface Builder.

But NextStep object-orientation was just a facade. Only API Kits were object-oriented. Beneath that layer lay a rather unusual breed of BSD UNIX running on top of the Mach microkernel with Display PostScript instead of X11 for graphics. It might not be a traditional System V, nonetheless still a UNIX, and hardly the next generation object-oriented OS everyone was talking about.

The third system was also built mostly by Apple refugees. It is BeOS from Be Inc.

They took a similar approach to NeXT, only with C++ instead of Objective-C and with a native graphics API instead of PostScript (although they initially played with Sun NeWS before deciding to go a separate way). On BeOS, you also have Kits creating an object-oriented facade around the mostly C-based kernel, drivers, and low-level services. Although one could argue it is more object-oriented than NextStep, since you don’t have a full-blown UNIX and PostScript infrastructure running underneath, just a POSIX API compatibility layer with bash and some regular UNIX tools.

What fascinates me is that in an interview for MacTECH, Erich Ringewald, the lead software architect at Be Inc. back then, was talking about the fragile base class problem and the approaches they tried at Be to avoid it while designing BeOS app kits.

It is a problem when changes to the base class can break functionality down the inheritance chain. And the fact that they are talking about it in the mid-90s clearly shows that problems with object-oriented programming, like the fragile base class problem, were already well understood back then (I bet the Smalltalk community had already known those back in the 80s, but who listened to them really?).

Despite that, the object-oriented fad lasted for decades, imposing the programming model that already showed rather fundamental flaws and giving us such technological “gems” like COM, DCOM, ActiveX, CORBA, Microsoft Foundation Classes, Enterprise Java Beans, and other examples of structural overengineering. And even though most of these “inventions” are long dead, their effect is still present throughout the industry - in overbloated legacy APIs, untangled dependencies, and fingerprints all over our modern cloud infrastructure.

Late afternoon, a chorus of air raid sirens was howling above the city. A harbinger of upcoming drones and missiles. A daily reminder that the war is going on, and you will never catch a break.

The first waves of buzzing drones started to sneak into the city, followed by hundreds of others — 500+ drones in total, not counting a dozen various missiles.

The attack lasted for more than 12 hours. I could see bullet traces and puffs of exploding flak shells all over the skies above. Powerful explosions were shaking the city, triggering car alarms all around.

By early morning, when most of it was over, dark smoke was clogging the sky above. Air quality sensors throughout the city turned red. The thick chemical smell prompted me to close all the windows and stay inside until the fires were put out and the wind dispersed the smoke.

Another grim and dusty morning.

The sky was sliced with tracing bullets, and firework-like puffs of delay-fuzed shells accompanied by occasional anti-aircraft missiles. Once in a while, a lucky shot would deliver a critical hit, resulting in a bright flash followed by a roaring thunder of an exploding 90kg warhead a few seconds later. When close enough, you can also feel the shockwave hitting your body.

Wave after wave, more suicide drones were coming in, overwhelming air defences and striking througout the city. It is a chilling experience to hear a drone suddenly changing the engine pitch while diving in, resulting in a screaming noise followed by an explosion. I guess it is reminiscent of WWII terrifying dive bomber attacks. My grandfather was listening to the screaming Stuka dives on the battlefields of WWII, and now I’m listening to Shahed dives 80+ years later. War never changes.

It was even more terrifying to hear dozens of drones diving in and striking one after another. Continuous explosions could be heard for hours.

And then enemy missiles arrived. Hypersonic aeroballistics got intercepted high above the city, sending powerful shockwaves down to earth. Then, the incoming cruise missile where met with a bunch of interceptors. Bright lights of ascending anti-missiles were illuminating my windows, followed by even more explosions.

Most of it was over by dawn, with only occasional explosions of remaining drones.

Ruzzians attacked Kyiv with more than 400 various projectiles - dozens of missiles and hundreds of drones.

One missile hit an apartment building, piercing it to the basement and causing it to collapse and bury inhabitants under the rubble.

In my neighbourhood, we got multiple hits with one drone hitting an apartment building (not that different from mine) and killing 3 people.

It is yet another grim morning. When instead of the smell of coffee from a nearby coffee shop, I can smell thick smoke of the burning city, instead of hearing the usual morning city buzz, I’m hearing sirens of firetrucks and ambulances rushing through the ash-covered streets and helicopters flying to the nearby lake to scoop more water. And instead of brightly green hills over Dnipro in my window, I see black smoke all over the horizon.

The fires over the city could be registered from space.

When the dust settled and the rubbles were cleared, 28 people were dead and 150+ more wounded.

The daily reality we live in.

The theme was Train. After a two-hour-long midnight brainstorm we with the team decided to create a little game about a steam train with a tricky pressure valve you have to operate to keep your boiler from blowing up.

The initial design called for a pixelated 2D side view of a steampunk-styled train moving through the desert. At the bottom of the screen, you have a panel with a bunch of controls and gauges showing your speed, boiler temperature and pressure, etc… The player uses that panel to feed fuel to the train and move. Finally, you arrive at a station where you can do repairs, get resupplies, and trade in various commodities.

It was a good plan, except for being overly optimistic. It looked good on paper but crumbled facing harsh jamming reality. In the end, we barely managed to make a playable prototype - Pressure Valve Madness.

What went right

In the end, we got a pretty good steam train simulation. The steam engine model is awesome and actually based on basic thermodynamic principles involved in the actual engine setup. You feed the fuel and the train starts moving. I sketched a sprite for the locomotive, a cart and rotating wheels. We even managed to add a pretty satisfying steam and smoke particles coming out of the boiler. And the final explosion when the boiler blows up is totally epic (even through I used a bunch of premade assets for that).

What went wrong

Besides the moving train, everything else was cut due to the time constraints. Yet another jam that suffered from overoptimistic estimates.

The final hours of the jam were brutal with crunch to make the project into a minimal playable prototype. Completed assets for the parallax background were abandoned, and the steampunk controls ended up as generic buttons and indicators.

Stations and shops were out of the question, but we’ve managed to introduce a simple destination meter and a resupply dialog to have some kind of progress. Which was almost pointless, since we didn’t have any supply indicators anyways.

Dissapointment

The whole economic subsystem was supposed to be the meta fun over simple train driving mechanics. It worked so well in 300 Hearts for Escape and we wanted to build on top of that successful experience and implement an extended version. But in the end, we haven’t implemented even a simplified one.

I especially puzzled by the fact, that I hadn’t spent much more time back then. In fact, for Down2Jam I’ve spent an average number of hours - 33.

For comparison:

• I spent 36h in a 3-person team on 300 Hearts for Escape (LD44, Spring 2019).
• 36h on Metro Gang (LD45, Fall 2019).
• 36h on Station Keeping (LD46, Spring 2020).
• Only 28h in a 3-person team on Master of Ritual (LD43, Fall 2018)
• 46h on Modus Catapultus (LD36, Summer 2016)
• And an incredible 57h in a 4-person team on Twin Jet Miner (LD38, 2017)

The stat shows a lot of 30+ hours, especially multiple 36h-sprints (which is relatively reasonable for a 3-day jam).

Why Failure?

Once again, we failed to prepare beforehand and spent much time setting up the project and getting familiar (once again) with the framework.

I have to get back to the basics of Collider.JAM project setup, update, and modernize it according to the recent experience. The whole setup should be done form a bunch of pre-made highly compatible patches. Currently, I still have to copy and adapt pieces of code from multiple projects. All these subsystems should be generalized and made available for easy reuse.

That epiphany allows me to create a roadmap for the next version of Collider.JAM - War Release 2. Keep tuned - new updates are coming!

It was not going well from the beginning. I decided to participate on the same day the jam started. So I hadn’t been able to gather a team and ended up participating solo. Sometimes it works, but it didn’t this time.

Moreover, I started the jam while doing major refactoring in the Collider.JAM event management subsystem. That meant I had to spend some time making the framework functional again. In the end, I spent about 40 hours over the course of a week working on the game prototype—all for a few working subsystems and no core gameloop.

I’d set overambitious goals, but failed to crystallize the vision soon enough to switch to the jam mode and deliver. I missed the initial momentum so necessary for any jam to succeed. And then just observed as the jam deadline was creeping in with no velocity behind me to meet the ambitious goals.

Inevitably, I’ve got another failed jam.

This failure closely resembles my failed Ludum Dare 33 in August 2015. Even the themes were very alike - “You are the weapon” for this one and “You are the monster” for LD33. Both ended very similarly - in spectacular failures with a few working systems and no gameplay in sight.

But the LD33 failure in the end turned out to be a huge success, since that triggered exploration of new tech horizons and eventually led to the creation of Collider.JAM.

Later, in Ludum Dare 38 on April 2017, I participated with a team and we already used a jam starter pack that later evolved into a full-featured framework for rapid prototyping and jamming.

I want this failure to be the same - a catalyst for positive changes in Collider.JAM. By analysing the time wasters, I can optimize the development pipeline so it would be even easier to start next time.

I think it was a slow bootstrap that caused me to lose the initial momentum. The bootstrapping should be straightforward and fun. It should establish all generic systems with little adaptation efforts. Don’t go into a jam creating unique systems unless you have a whole team of good developers on board.

That experience hints at the upcoming optimizations in Collider.JAM - all these subsystems must be delivered as ready-to-use, dropped-in patches, working with little-to-no customization. That follows the general Collider.JAM philosophy when we prefer to provide reasonable defaults out of the box.

So despite the obvious failure, I am still full of ideas on what to do next. The upcoming release of Collider.JAM will be more usable than ever.

It left 3 people dead. Even though the missiles were intercepted and it doesn’t look like the warheads have detonated, the huge kinetic energy of several tons of falling debris caused a lot of devastation.

I had a terrible headache the whole day, the same is true for my wife. So even though physically we were not hurt, these attacks are taking their toll emotionally.

Another bad day in Kyiv.

The Origin

Collider.JAM started with a very basic input system. All input events are captured by functions in /trap. So /trap/keyUp(e) captures all key up events, /trap/mouseMove(e) - all mouse movements. Or maybe you want to capture an R keypress by creating trap/rDown(e). It is simple, straightforward, and, more importantly, follows Collider.JAM opinionated conventions for names and placements.

Basically, you establish input handling by dropping a few .js files in the /trap folder. Very good for a simple prototype. But not good enough for more complex scenarios.

Handling Controllers

To address challenges of bigger games I’ve created a controller subsystem that builds upon the existing Collider.JAM foundation and handles more sophisticated cases, including input remapping and gamepads.

That system included a concept of “actions” and a way to map incoming gamepad/keyboard events into those actions. Then, there is a way to “bind” controls to a particular entity in the /lab. All you have to do is to implement an act(action) function with a switch to react to each particular event.

The Limitations

This system worked fine, but many games later I discovered its limitations. It is not easy to customize the mappings to gamepads (a bit easier for the keyboard though). Also, the idea of processing actions as integers turned out to be somehow limiting and in some places confusing. To improve readability, I always introduced global constants (e.g. UP = 1, LEFT = 2, DOWN = 3…). It is cumbersome and not flexible. Plus, there are cases when you would prefer to use human-readable strings for actions instead of constant numbers.

For a long time, I hesitated between two approaches - what must my actions be, constant-defined numbers like LEFT=2 or human-readable string literals like “left”?

Recently, I finally realized that the best approach is to merge those two in an input event object. That would allow us to use numeric values where convenient and string ones where clarity is the priority. Also, we can keep additional metadata there, like timings and the origin event objects.

So it is time to refactor the controller handling for Collider.JAM!

The Plan

We will introduce a new binding system with human-readable labels and the ability to remap. We will represent actions as objects. We will design for more complex scenarios, like the ability to store and restore entity bindings when switching between states.

And finally, the whole controller subsystem will be available as a collider patch within a standard Collider.JAM package.

Ballistic missile attacks are sudden, swift, and brutal. No compromise, no remorse. Ballistic missiles are fast. Usually, you have only a minute or two between the alert and the incoming.

You don’t have time to look for a shelter. If caught outside, just hide inside the nearest building. You are in luck if there is a subsurface facility nearby - an underground pedestrian crossing, an underground parking lot, or a subway. The best of them, of course, is a subway, designed in the Cold War to be a nuclear shelter.

If the alarm catches you at home or in an office, it is better to stay inside. It is the best option since the strike might happen while you are outside still looking for shelter. Actually, we had fatalities in the city when the falling debris of an intercepted missile killed someone who was looking for shelter. So it is better to stay inside within the location you are currently in and look for the most reinforced place away from windows. Try to have at least two walls between you and the outside. If your building has an underground parking lot, it is a good idea to move there ASAP.

It can also be that a ballistic attack caught you in transit. The worst-case scenario I can think of is when you are stuck in traffic on one of the bridges over the river. There is nothing you can do then but hope that this strike is not targeting this particular bridge.

Cruise missiles are different. Russians launch them from standoff distances way inside their territory to keep strategic bombers away from danger. Often somewhere over the Caspian Sea. It takes at least an hour for a relatively slow subsonic missile to reach Ukraine. When the launch is detected, you have plenty of time to plan your shelter arrangements.

Drones are the slowest of the explosives delivery bunch. So the drone attacks are the most exhausting ones.

When the city is hit by ballistics, you hear the air raid alerts, then explosions in a few minutes. You still have to wait until the air raid alert is over as a safeguard for additional attack waves.

Windows are shaking, and adrenaline is spiking, but after the burst of explosions, it usually is over pretty soon. If you hear ballistic missiles hitting or being intercepted, that means these are not meant for you. You will never hear a ballistic missile hitting you since they are supersonic. First comes the explosion, then the sound (though there are still very dangerous debris and shrapnel afterward).

Drones are a different beast. Ruzzians launch Iranian Shaheds in batches late in the evening and wave after wave, these drones are flying and circling all over Ukraine for hours.

Last night, the initial air raid alert was declared at 10 PM. That means the drones are closing in on Kyiv. And they continue to come in multiple waves during the night. Almost 100 drones in total, 30+ of them targeting Kyiv. Each time another pack of drones enters Kyiv we have an additional “Increased Air Threat” alert. We had like 11 or 12 of these throughout the night mixed with shooting and explosions when these drones were intercepted here and there.

No drone passed through the air defense deep into the city last night, but bad sleep for millions of Ukrainians was ensured. Another attack is repealed. And once again I’m consuming copious amounts of coffee in the morning to compensate for the sleepless night.

Just another sleepy day.

Today, our side of the city didn’t get much rain. It happens sometimes when you live on a big river - one bank could have a different weather from the other.

So it rained on the other side. We got a lot of thunder, though. Heavy, powerful rumbles could be heard for hours.

Closer to midnight, the thunder was long gone, but it was everything, but quiet. Ruzzian drones were closing in on Kyiv from the east - seems like I’m on a vector of attack… Again.

Then, there was an explosion. Most certainly caused by an anti-aircraft missile intercepting a nearby drone. It was so forceful that I jumped out of my chair. The blast was followed by smaller prolonged secondary explosions and sounds of falling debris.

It was a stealthy drone that managed to penetrate the city undetected and was engaged when already inside the city limits.

Well, I can confidently say that the sound is different. There was no doubt in my mind, even for a second, that the explosion was caused by thunder.

We were lucky this evening, and nobody was hurt by the falling debris. So, it’s a good day after all.

You never know when the next attack is coming.

It was a typical Monday morning. The city was buzzing with activity. There was a limited drone attack during the night, but it was long over.

Suddenly, all hell breaks loose. 40+ missiles from all directions converged on Kyiv almost simultaneously.

The combined attack included various types of missiles. Ship and submarine-launched Kalibr cruise missiles, Kh-101 cruise missiles launched by strategic aviation, land-based ballistic Iskanders, air-launched aeroballistic Kinzhals, and even a hypersonic Zircon.

Explosions shook my apartment building. I briefly glanced outside to see a couple of anti-aircraft missiles rising to the sky to intercept another ballistic threat.

When the explosions were over, I saw black smoke over the city. This Monday is harder than usual.

Today, a ruzzian missile hit the biggest child hospital in Ukraine. The surfaced video clearly shows a ruzzian Kh-101 missile flying unintercepted right into one of the hospital complex buildings. Which means it hit exactly where it was programmed to hit. So there is actually a person who entered the coordinates of a child’s hospital into the missile computer.

Not only that, but a couple of hours later, the next wave of missiles hit another part of the city. One missile hit a reproductive clinic, killing 9 people inside, including patients and medical personnel. This definitely demonstrates that strikes on medical facilities are not accidental, but deliberate.

Other parts of the city were also hit. Another missile blew up a section of an apartment building. So now, emergency services and volunteers are cleaning up the rubble of the collapsed structure, looking for survivors.

Today, I am more pessimistic than ever. A daylight strike in the rush hour to increase the number of victims shows yet another escalation from the ruzzian side. The end of the war is nowhere to be seen and it just spreads and becomes more violent.

When an air raid alert triggered on my phone at 4:50 AM, I kept sleeping. I also ignored an increased thread alert buzzed at 4:52 AM warning about an imminent strike.

But you can’t ignore an explosion. I was instantly up and fully awake. Talking about a super fast and decisive alarm clock. You can’t snooze this one! There is no need for a knocker-up person when you have a crazy neighbor regularly launching missiles at you early in the morning.

Everything is fine. The missile is intercepted, the damage is minimal and nobody has died from this attack.

A thundering beginning of a new day.

But in my case, I need something more intricate. Since I’m not only using Collider.JAM, but also developing it, I need an installation working right from git repositories deployed locally instead of using pre-packaged remote snapshots. That way I can introduce changes and test them right away.

One also could benefit from that type of installation in complex project requiring some framework customizations. Just fork a package you want to customize and link it with other parts of the framework.

Here are the necessary steps to do that.

1. Create Framework Folder

Select an appropriate location and create a folder for Collider.JAM packages. I find it convenient to keep all framework components in a separate folder:

mkdir jam

2. Clone Collider.JAM Repos

Collider.JAM consists of 4 major packages you need to install: collider.jam, collider.mix, collider-dev.mix, collider-boot.mix.

cd jam
git clone git@github.com:invadium/collider.jam.git
git clone git@github.com:invadium/collider.mix.git
git clone git@github.com:invadium/collider-dev.mix.git
git clone git@github.com:invadium/collider-boot.mix.git

3. Link Packages Globally

We definitely can install collider.jam package from local git repository globally by running npm install -g from the collider.jam folder. But when you introduce any changes to collider.jam it must be reinstalled for changes to take place. Even worse, any changes to submodules (like collider.mix or collider-dev.mix) are going to be ignored, since collider.jam package uses their snapshots from remote repos.

To fix this we need to link those packages with local repo deployments. Linking is a two-step process.

First, we create global links for each locally deployed component:

cd collider.jam
sudo npm link
cd ../collider.mix
sudo npm link
cd ../collider-dev.mix
sudo npm link
cd ../collider-boot.mix
sudo npm link
cd ..

This links the global npm packages to the local repos.

Local Link

The last step is to link those package dependencies locally. When you run npm install or npm update npm installs or updates package snapshots in ./node_modules folder.

We need to patch ./node_modules so it would contain the links to actual local repos instead of remote snapshots.

Only the packages with other framework dependencies need to be linked - collider-dev.mix and collider.jam.

cd jam/collider-dev.mix
npm install
npm link collider.mix
cd ..

cd collider.jam
npm install
npm link collider.mix collider-dev.mix collider-boot.mix

The link <module-name> command creates a link to package deployment in ./node_modules.

Note, that these links are going to be wiped next time you run npm install or npm update. So this linking process must be repeated after each install or update.

Since this deployment is very peculiar and necessary only when developing or modifying Collider.JAM, there is currently no command in jam to help you with that. All steps need to be performed manually.

You might want to create a script to automate this.

Recent Russian missile strikes on hydroelectric dams and thermal power plants left 8GWt whole in the Ukrainian power grid and it was just a matter of time before the system became unbalanced. Kyiv was luckier than others for a few weeks, but it looks like that luck ran out.

So now I’m getting to the old routine of keeping my laptops and power banks charged in addition to warm tea, water, and some food in thermal bottles.

I’m one of the lucky souls who only need a laptop and the Internet for work. Some businesses will suffer more, especially the ones requiring uninterrupted power supply.

But even with electricity gone, the city lives on. I hear the buzz of portable power generators. Cafes in the area were prepared, meaning I could still enjoy my morning coffee and croissant.

The war continues but so is life.

It looks like Kyiv was attacked with hypersonic 3M22 Zircon missiles from the occupied Crimea. They fly so fast that there is very little time to react.

We moved to the corridor as fast as possible since there was no time to get to the bomb shelter. Here, in Kyiv, we had cases of people killed by falling debris on the way to a shelter, so sometimes it is just safer to stay inside away from windows.

One of the missiles hit another part of the city destroying a little two-story building, part of a university campus. Usually used for fitness or dance classes for teens and kids, the building luckily was empty at the moment of the strike. So we are extremely lucky nobody got killed… This time.

Just another day in Ukraine.

It is a massive release baked for almost 4 months. The changelog alone is bigger than any of the previous ones.

A lot of effort this time went to simplify project bootstrap. You can now use jam init ls to list all available samples:

mkdir next.mix
cd next.mix
jam init ls

The last command will scan installed modules and list all available samples. By the way, jam init list or jam init help would also work just fine. I’m trying to make the cli as user-friendly and forgiving as possible :)

There is going to be one new interesting sample in the list:

* planets - bouncing planets sample

Bootstrap the project with:

jam init planets

Collider.JAM will generate a package.json and other artifacts.

Now you can run the project:

jam play

A browser should open with a flying planet. Click on the screen to spawn more planets.

From the features included in DR10 the most interesting is color manipulation.

Now it is easy to transform string color descriptors back to rgb or hsl representations and also manipulate colors with lighten(), saturate(), and shiftHue().

It can be used to simulate light effects and manipulate sprite colors (e.g. colorize multiple teams from a single source sprite).

There are also helpful utilities included in this version. Like obj.toData() to simplify JSON object serialization and lib.array.prev() and lib.array.next() to walk over the elements of an array.

There are some compatibility-breaking changes in the APIs (like _sizable flag was renamed to _rectangular), but it mostly affects Collider.JAM internals like HUD subsystem and shouldn’t break client code in most of the cases.

The APIs look stable and ready to migrate to the stable Alpha-release branches.

Development Release 10 is going to be shipped soon. Then, DR 11 and 12 will follow, and we might finally be ready to ship the first Alpha.

Spring is traditionally a jam season. And since it is Collider.JAM, all major releases are usually shipped around these jams :)

Themes and limitations are always different, so each jam provides a unique testing playground for framework features and development approach.

I’ve started the season with Going Hyper Winter 2021 and my third 7DRL Challenge. Each deserves a separate post-mortem and each challenged Collider.JAM in new and unexpected ways.

There are hardly any major features, but many small changes making the framework usage more pleasant and consistent.

So now I’m sharpening my tools for the upcoming Ludum Dare 48 in late April. It is my next milestone. There is definitely going to be another Collider.JAM release with a bunch of cool features!

Let’s see how easy it is to build a similar app with Collider.JAM and JavaScript.

And let’s also extend the original concept by adding the ability to create additional eyes on the mouse click. There was no way to do that in the original X-Window version, but we can do it, since we have the whole canvas at our disposal.

.mod sketch project

Let’s create a Collider.JAM .mod project and dna/eye.js file:

mkdir eyes.mod
cd eyes.mod
mkdir dna
touch dna/eye.js

defaults

First, we need to define eye defaults in dna/eyes.js:

// dna/eyes.js

const defaults = {
    x: rx(.5),
    y: ry(.5),
    hr: rx(.02),
    vr: rx(.03),

    color: hsl(.1, .9, .9),

    iris: {
        size: .5,
        shift: .4,
        color: hsl(.42, .4, .5),
    },
    pupil: {
        size: .2,
        shift: .55,
        color: hsl(.05, .3, .1),
    },
}

This object contains the values we use to initialize a newly constructed eye instance.

The properties x and y set the eye center position, hr and vr - horizontal and vertical radiuses for the eye ellipse. The eye color is also defined here.

Functions rx() and ry() calculate relative sizes to screen width and height. So rx(.5) means the half of the screen width and ry(1) means the full-screen height.

An eye has two internal parts - iris and pupil. Each defined by its own property object that determines the size (relative to the eye horizontal radius), color, and shift. The shift is a distance to move the iris or pupil towards the mouse cursor. It is also defined relative to the hr value.

onClone()

We are going to define eye as a simple prototype instead of a constructor or a factory. It means the defined object will be used as a prototype to clone new instances. This process doesn’t create a traditional JavaScript prototype chain, rather produces a fully independent object.

The onClone() function is used in Collider.JAM to initialize a cloned object after construction. Any fancy actions required to setup the object can be performed here.

let id = 0
function onClone(settings) {
    this.name = 'eye' + (++id) // assign a unique name
    augment(this, defaults, settings)
}

The function assigns a unique name like eye1, eye2 etc… Next, it augments the cloned object with default and spawn settings.

draw()

The drawing procedure is the most complex one in this app. But the meaning of each individual command is pretty straightforward.

function draw() {
    // declare local shortcuts to simplify calculations
    const { x, y, hr, vr, iris, pupil } = this

    // eye
    fill(this.color)
    ellipse(x, y, hr, vr)
    
    // calculate direction of the mouse cursor
    const dir = bearing(x, y, mouse.x, mouse.y)
    const d = dist(x, y, mouse.x, mouse.y)

    // iris
    fill(iris.color)
    const ishift = min(hr * iris.shift, d)
    ellipse( x + ishift * cos(dir), y + ishift * sin(dir),
                hr * iris.size, vr * iris.size )

    // pupil
    fill(pupil.color)
    const pshift = min(hr * pupil.shift, d)
    ellipse( x + pshift * cos(dir), y + pshift * sin(dir),
                hr * pupil.size, vr * pupil.size )
}

We use object deconstruction syntax here to simplify calculations, so we don’t have to supply each value with this. prefix.

Three ellipses are drawn here in total. Each preceded by a fill() call to set the corresponding fill color.

There are also some preliminary calculations to determine the shift direction for iris and pupil.

Collider.JAM bearing() and dist() functions are used to calculate the angle and distance to the mouse cursor.

setup()

The setup function creates two eyes in the /lab node:

function setup() {
    // spawn two eyes
    lab.spawn(dna.eye, {
        x: rx(.69),
        y: rx(.25),
    })
    lab.spawn(dna.eye, {
        x: rx(.75),
        y: rx(.25),
    })
}

click()

To create an additional eye on mouse click, introduce a click trap in trap/click.js:

// trap/click.js

function click(e) {
    lab.spawn('eye', {
        x: mouse.x,
        y: mouse.y,
    })
}

Green Eyes on the mouse!

That’s all you need for a functioning Collider.JAM app.

Run it from inside the eyes.mod folder with:

jam play

And eyes in the browser will start to track your cursor :)

Click anywhere on the screen to create more eyes!

You can find the demo app sources on GitHub.

Usually, backgrounds are not a part of the action, nevertheless, they are a crucial element of a game style and aesthetics.

Backgrounds also play an important role in the game loop, since usually they are the first thing we draw each frame. So the background is supposed to clean up the previous frame.

Before DR4

In early versions of Collider.JAM we used to draw backgrounds manually.

The simplest form you can find in the early examples would be whole screen color fill in a draw function:

// lab/background.js

const Z = 0

function draw() {
    fill(.55, .4, .1)
    rect(0, 0, ctx.width, ctx.height)
}

background()

Since backgrounds were so common, manual fill was soon replaced by the background() function:

function draw() {
    background(.75, .4, .1) // HSL values
}

So you don’t have to specify the screen size - in the case of the background, it is obviously the whole screen.

And you can use it in many different ways:

background('#252030')      // CSS-style color
background(15, 10, 30)     // RGB values
background(res.background) // fill with a background image

Since DR4

However, backgrounds are so common, that even one function call seems like overkill. When you drawing a simple sketch, you need a background just to be there. You don’t have to care about puny details.

Therefore, since the Development Release 4 we have a background enabled by default. I choose it to be dark (more precisely - a dark grey ‘#121313’). The dark background seems to work better than a light one for most of the examples. Also, the dark grey is better mixed with most of the colors as opposed to the totally black ‘#000000’.

The default background is set as background property in lab. If you don’t want #121313, you can set it manually:

function setup() {
    lab.background = hsl(.75, .4, .1)
}

Or maybe set an image:

lab.background = res.background // fill with the background image

Complex Backgrounds

You can turn off the background:

lab.background = false

You might want to do that to draw a complex background manually (e.g. when you need parallax scrolling) or to preserve the scene for the next frame in simulations like brownian motion.

To make a complex background node with parallax scrolling or other effects, just include the node in /lab and make sure it has the lowest Z-value, e.g.:

// lab/background.js

const Z = 0

function draw() {
    // some complex drawing
}

Interestingly, it is just the way we used to do backgrounds before DR4 :)

Design

You can see, that in Collider.JAM the default option is the most simple and widespread one. But any level of customization can easily be achieved by simple overrides.

That little feature actually reflects an important tenet in Collider.JAM design:

Provide the most used case as a default option, but give the ability to easily override with custom behavior.

That principle rules over many features of Collider.JAM, not only backgrounds. You can find many reasonable defaults all across the framework. And they are one of the key reasons for code simplicity in Collider.JAM.

The package is available on npm:

npm install -g collider.jam

It’s the 8th Collider.JAM release this year. The changelog is not as big, as in the previous release, but still, there are significant changes.

We finally have CONTRIBUTING.md with tips on how one can help the project. It’s attributed primarily to Hacktoberfest and the best open-source practices I’ve learned along the way.

But this release is not about features, it is about user experience.

The readme and help are significantly improved. The ultimate goal is to have the documentation good enough for on-boarding without any additional help. We still have a long road ahead to get there, but the roadmap is in place. And we’ll continue to experiment with various forms and formats to get the best results possible.

There is a Pong tutorial available in help now. I feel the need for a series of tutorials just like that - Breakout, Tetris, Asteroids, Snake, Missile Attack…

Classic games are built around well-understood mechanics, thus providing ideal tutorial material. You don’t have to figure out how the game works, just discover and use the fitting blocks of Collider.JAM and JavaScript to make it work.

It is a valuable lesson in pedagogy I haven’t defined for myself up to this point. Although, I’ve been using it intuitively for quite a while.

Leverage well-understood mechanics to teach new concepts.

Everybody knows how to play Pac-Man or fit blocks in Tetris. We can use that as a vehicle of discovery. E.g. explain two-dimensional arrays using the Tetris field. The possibilities are limited only by our imagination.

So expect more awesome tutorials on Collider.JAM and JavaScript in the nearest future!

However, a game state is essentially a one big global scope.

It defines where the enemies are, how many hit points they have, and how much health and ammo you’ve got. And each part of that system potentially can affect any other.

In reality, the global scope is not that bad if you know how to deal with it.

Collider.JAM offers its own approach of global scope organization and handling.

The Mix

The global scope in Collider.JAM represents the scene and all associated resources. It is called the mix since it mixes all mods and fixes into a single tree hierarchy. At the top of the mix, there is the root mod. All other mods are mounted inside at /mod by default.

Everything in your game is placed somewhere in the mix. You can think of it as a virtual filesystem that joins together all the *.mod and *.fix folders you have plus all the system *mod and *.fix folders shipped with Collider.JAM.

The mixing process is pretty straightforward - you start with a bunch of mod & fix folders and load them into a single tree at particular mount points.

$ Global Accessor

By default, the whole mix hierarchy is exported as a $ object.

It is done primarily for the convenience of debugging. You can always open the browser developer console and type $ to dump the whole mix, or maybe $.lab.hero to dump the hero object.

Since Collider.JAM DR9, the $ object is defined both as a global variable and as a variable within Collider.JAM scope.

The reason is that the global $ can be disabled to restrict the access to mix from the outside:

delete window.$

or

window.$ = null

Also, it can be reused for other purposes.

But within Collider.JAM scope, the $ will still be pointing at the mix.

Almost everything in your game can be accessed through $.* since everything is placed as a node on the mix tree. It is truly the global context of the game. The rare exception would be the data and functions hidden inside closures.

Local Mod

In most cases, you don’t need to access the root mod.

Usually, you work with the current mod and there are a bunch of links in scope to access it. We call it a local mod context, but it is not truly local. Better think of it as a global context of the current mod.

There is the _ accessor that points to the current mod.

There are also fast node accessors like res, env, dna, lab and trap. You can use them for quick access to particular components of the current mod.

Let’s assume you need to run the show() function on hud object in console.mod.

You can access it from anywhere by using the mix $ accessor:

$.mod.console.lab.hud.show()

But within console.mod you can say:

_.lab.hud.show()

Or even better, use the lab shortcut:

lab.hud.show()

By using the local path instead of global, you make code shorter and more portable. You can rename the mod or mount it at another node of the tree and all the local links will continue to work without any changes.

_ and $

Accessors _ and $ are the main things you need to know about the global scope in Collider.JAM.

Use _ to access current mod.

Use $ when you need to access things globally in other mods.

Also, use $ in the browser dev console. The _ accessor is defined only within each mod’s scope and makes no sense in the browser dev console context.

Collider.JAM Global Context

It would be unfair if I’ll not mention other objects in Collider.JAM global context.

Besides the _ and $, there are many more things defined in the mod scope.

There are drawing functions like line(), rect(), and circle().

There are math functions like sin(), cos(), and sqrt().

There are utility functions like defer() and kill().

But these would require more than a single post to cover them properly, so see you the next time.

Just execute somewhere inside a project folder:

jam

And then open http://localhost:9999.

Even better, you can ask Collider.JAM to open the project link automatically:

jam play

However, during development we often use a different form:

jam -d

The -d flag turns on the debug mode. There are a number of debug and development features enabled by this:

• debug output
• fast boot
• help data
• hot reload
• custom debug hooks

Debug output in the terminal

The debug output prints a lot of data besides the usual Collider.JAM version and listening address.

It shows the type of project it runs (sketch mod, sketch mix or package), what configurations are found and used, the scan map used to find and inspect all the units.

It prints all the files and folders it has found, which ones are included and which ones are ignored.

It shows where exactly the found units are mounted on the webserver.

If you are missing a resource, it is the first place to look. Maybe Collider.JAM scans wrong folders or the file is ignored for some reason.

Fast Boot

Collider.JAM tries to minimize the load time when in debug mode. Keeping [Change-> Reload -> Try ↵] cycle short is crucial for a jamming-style development.

Help Data

Collider.JAM collects help data only in debug mode.

Open the project and use F1 to access the help system. It includes a lot of useful information - how to get started with Collider.JAM, useful links, tutorials, documentation on framework libraries, and your own objects and prototypes.

Hot Reload

This feature significantly speeds up the tuning process.

Collider.JAM scans the included folders for changes and reloads all changed files.

Hot reload works well for things like /dna, /env, /lib and static resources, but can be tricky for entities in /lab.

The ones placed directly in /lab are mostly OK. The entities spawned from DNA, on the other hand, have an evolved state associated with them that can’t be changed. Collider.JAM tries to patch the functions in order to upgrade behavior. But there is a change it can brake the entity - especially if a new state has been introduced in updated DNA.

Therefore, sometimes full page reload is necessary to get a consistent update. But if you are changing resources or tuning colors in /env/tune.js, it works just fine.

Custom Debug Hooks

The last significant feature of debug mode is custom hooks you can add for development and debugging.

When you run the projects with jam -d, the environment configuration has debug flag activated. So you can introduce debug-only code in your project as simple as:

if (env.config.debug) {
    // TODO enable debug feature or log debug info
}

Useful by default

I always run Collider.JAM with the -d flag while working on a project. The debug features are really useful and have no practical downsides.

Only when I want to see the release version, I skip the -d.

The level of noise modern tools generate is just unbelievable. When you click on “Create a New Project” in a typical modern IDE, you receive a folder full of mystery and surprises.

A hello-world type of project might consist of hundreds of files.

Do these files essential? Do they serve any purpose? Is it possible to hide or eliminate some of them while preserving the functionality? Is it really necessary to be that complex?

I believe Collider.JAM has an answer to this problem. We put all the effort to make projects smooth and clean. You put in only the essentials. And it is a good example of minimalistic design.

sketch mod

In Collider.JAM you don’t need an IDE to create a project. You just type:

mkdir test.mod

That’s it! Simply create a folder named *.mod, cd into it, and you can already run it with:

jam play

It doesn’t show anything, but it works!

It represents a mod - the most fundamental concept in Collider.JAM, that defines both structure and behavior. And you can already explore that structure by hitting F2.

To have something on the screen, you might create lab.js inside:

function draw() {
    fill(.35, .5, .5)
    cirlce(rx(.5), ry(.5), 50)
}

Now you filled a circle in the center.

This type of Collider.JAM project is called sketch mod. We don’t have to create package.json or any other boilerplate files for it to work.

Just a simple folder with content sorted in subfolders. The extension *.mod is important though. It is how Collider.JAM recognizes the root of the project.

The structure inside *.mod have to follow Collider.JAM conventions. It means factories and prototypes go to /dna, utility functions are placed in /lib, event handlers are in /trap, and everything that lives is in /lab.

These folders represent conventions used by Collider.JAM to locate and use different game components. It is similar to conventions used by some web frameworks like Ruby on Rails to locate models, views, and controllers. Placing a *.js file in different folders can change its behavior.

The mod structure might look daunting at first. But it turns into a familiar landscape once you used it for a little while. And when you know it, it becomes easy to navigate Collider.JAM projects, especially the more complex mixes consisting of multiple modes.

The best thing is that you don’t need to know the whole mod structure to start the development. Just 4 essential folders will suffice.

jam new

Sometimes we don’t want to create a structure manually.

Collider.JAM provides some helpers to do it automatically. Run new ls command to see the possible options:

jam new ls

Let’s create a sample mod:

jam new mod sample

This generates a sample.mod folder with a typical structure - there are dna, lab, lib, res, and trap examples generated. Run the mod to see the result:

cd sample.mod
jam play

sketch mixes and packages

There are other types of projects in Collider.JAM - sketch mixes and packages. They are usually used in more special cases.

For example, when packaging the game for a mobile platform or desktop, you need to have a package.json with appropriate dependencies. So these projects are created in the so-called “package mode”.

But in most cases, you can start in the sketch mode and move to the package mode later.

The world is a very noisy place. You don’t need more noise in your Collider.JAM projects. So stick with the sketch mode whenever possible.

In this video, Blender Guru talks with Ton Roosendaal about the origins and the future of Blender.

Blender originated in 3D animation studio NeoGeo on the Amiga platform in the late 80s. You can still download and try the original software called Traces.

Later, a company Not A Number was formed to support the development of 3D modeler by that time called Blender.

Initially, Blender was a freemium software. You can download a basic version for free and get the full-featured one for money.

But the company has failed to generate enough sales and investors decided to close the operations.

So Ton Roosendaal came up with a truly unique solution - announce a crowd-sourcing campaign to gather 100,000 EUR for NaN investors to free Blender under an open-source license. The campaign was highly successful and reached the goal in just 7 weeks.

It is probably one of the first crowd-sourcing campaigns on record and it is highly remarkable for turning a commercial software product into an open-source one.

When I was working in game development in the late 2000s, Blender wasn’t considered to be a true “professional” option. Except for a rare few enthusiasts, most artists sticked to MAX and Maya.

But today, with each new release, Blender gains momentum over the competition. It shows the actual power of the open-source community and the huge challenges commercial software vendors face.

In some areas, open-source already had a decisive victory.

In the 80s and the 90s, most developers were buying their compilers, linkers, profilers, and other tools. Nobody thinks about buying a compiler today. It is inconceivable now since we used to get our SDKs for free (except for some special cases - do you hear me, game console vendors?).

So I love this time when our platforms and tools are open-sourced. The technologies today are more accessible than ever before.

The future is already here! And the future is open-source!

The Essence of Life is simple and ruled only by 2 functions - evo(dt) and draw(). The first determines the lifeform’s behavior in a short timespan (usually a single frame). The second - how the lifeform looks in its current state.

To have a lifeform on the screen, you just have to define these two functions on any object and place it in /lab.

Note, that you don’t have to extend from any special class like GameObject or do any other crazy stuff.

You and only you define how your objects are going to be created and organized. Collider.JAM just provides some conventions to simplify that.

You can use a prototype hierarchy, you can use a composition of mixins, you can create custom factories…

Moving Circle

Let’s create a circle that moves horizontally:

// === mover.mod/lab.js ===

// coordinates and radius
let   x = rx(.5)  // center horizontally
const y = ry(.5)  // center vertically
const r = ry(.05) // 5% of the screen height

const SPEED = rx(.25) // 25% of the screen width per second

function evo(dt) {
    // move the circle horizontally
    // warp the coordinate, so it always stays on the screen
    x = warp(x + SPEED*dt, 0, rx(1))
}

function draw() {
    fill(.45, .5, .5) // color in HSL
    circle(x, y, r)
}

We are placing our entity directly in /lab.js. It is OK as long as we are not going to have any other lifeforms. Otherwise, it is better to place it deeper, e.g. /lab/circle.js.

You can run it by typing jam in the mover.mod folder. Check the sources at GitHub.

After initializing coordinates, radius and speed, we are defining functions evo(dt) and draw().

The purpose of evo(dt) is to update object state before the next drawing cycle. In our case, it determines the movement behavior of the circle. Each step, it moves to the right at the declared SPEED in pixels/second.

Note, it is crucial to factor on dt everything you do in evo(dt). It represents the time in seconds passed after the last update.

Since the speed is defined in pixels per second, we need to factor the speed value like SPEED * dt to find the actual movement over the X-axis for the current frame.

When properly factored, the movement doesn’t depend on the actual framerate.

The draw() function sets the fill color and draws the circle.

Each frame, all lifeforms in /lab evolve with their evo(dt) and rendered on the screen with their draw() functions.

Any object within the /lab subtree with evo(dt) and draw() functions is an actor on the scene. It shows something and behaves somehow.

Plants

Some lifeforms might have only a draw() function. So they are not actors on the scene, but props. We call them plants since they have a visual representation, but no behavior of their own.

It might be an ammo indicator, showing the hero’s ammo supply. Or maybe a score indicator. Or a static wall…

Ghosts

Plants are visible but static. But what if we have behavior, but no visual representation whatsoever. These entities are called ghosts and they have evo(dt) but no draw() function defined

A collision detection node can be an example of a ghost.

Summary

That is all there is to life in Collider.JAM. Only two functions are needed to define how lifeforms look and behave.

But evo(dt) and draw() are not the only convention functions you can define on nodes in Collider.JAM. There are also init(), onSpawn(), kill()…

But I’ll save them for another time :)

Collider.JAM framework has its own majik. To master it, you need to know 4 essential folders.

These folders are:

• /res
• /dna
• /lab
• /trap

You can find them at the root of almost any Collider.JAM project. Place files into proper folders to leverage the power of Collider.JAM.

The names may look cryptic at first. You have to get used to it.

After using Collider.JAM for a while, you might appreciate the design decision to use short lowercase names for widely used concepts.

This is one of the cases, where UNIX philosophy had a major impact on Collider.JAM design.

/res

All assets go here.

In /res you can find a bunch of *.png, *.svg, *.ttf, *.wav, *.txt, *.csv and *.json files among other things. These are the resources used by the game code.

Since most of games contain many similar resources, they can be grouped in subfolders, e.g.:

/res/tiles - for tilesets
/res/fnt - for fonts
/res/sfx - for sound effects
/res/backgrounds - for various background images

Resources, like everything else, are loaded automatically. So there is no need to load() them explicitly.

Do you need to draw a Moon sprite? Just place moon.png in /res. Now you can render it in any draw() function:

function draw() {
    image(res.moon, 100, 100, 75, 75)
}

/dna

It is the place for factories and prototypes.

Say, your main hero is implemented as class Hero. Place the source into /dna/Hero.js. Now you can spawn the hero in lab during the game setup:

// setup.js

function setup() {
    lab.spawn('Hero', {
        name: 'hero',
        health: 100,
        x: 100,
        y: 100,
    })
}

The logic is simple - you need DNA to create a lifeform. And DNA determines the lifeform view and behavior - with functions draw() and evo(dt).

/lab

All lifeforms are spawned in /lab.

When you need something in the game to be visible and moving, you place it in /lab.

Sometimes, we spawn lifeforms from /dna. And sometimes we just place them directly in /lab like this:

// lab/redCircle.js

function draw() {
    fill(.01, .5, .5) // color in HSL
    circle( rx(.5), ry(.5), 75 )
}

This will create a node named “redCircle” that renders… a red circle in the middle of the screen.

Note, that the color is in HSL. But it can also be represented as RGB values like fill(255, 0, 0) or even as a css-styled string like fill('#ff0000').

Functions rx() and ry() can be read as “screen-relative” x and y.

/trap

All events are “trapped” in /trap.

These can be system events - mouse clicks, keypresses, etc… Or they can be user-defined events like “gameOver” or “levelComplete”.

Traps are just functions placed in /trap.

To trap the Space key down event, define:

// trap/spaceDown.js
function spaceDown() {
    // TODO handle space key down
}

User-defined events can be trapped by the trap() function:

trap('gameOver')
trap('startLevel', 1)

To handle the startLevel event, create startLevel() function in startLevel.js like so:

// trap/startLevel.js
function startLevel(nextLevel) {
    // TODO start the level specified in the nextLevel parameter
}

4 the Game

These 4 folders represent all essential elements of any game. Sprites, tiles, sound effects, and music are stored in /res. Entities you can spawn are placed in /dna. /lab keeps everything that lives. And /trap traps all controls.

Given a simple arcade game, you hardly gonna need anything else.

Other Folders

There are other top-level folders in Collider.JAM. Some more important than others. Like /env that is used to store configuration and global environment (e.g. things like game score). Or /lib that’s dedicated to utility functions. Or /cue with timed triggers…

But the 4 highlighted folders are the most used ones. So it is crucial to know and understand them. This is the way Collider.JAM game development works.

What is the best thing after delivering Collider.JAM DR8? Sure thing it is Collider.JAM DR9. And that is what I plan to ship in late October - early November.

The last release was dedicated to our team’s participation in Ludum Dare 47 Jam. So it included mostly the features needed in jams - features for rapid development, like jam new command that simplifies the creation of various entities.

But Hacktoberfest is all about open-source community, so the next release will be all about people, not technology.

I firmly believe that Collider.JAM offers a very unique and unobstructive way to develop interactive applications. It gives a totally different perspective on development - the one you will not find in regular IDE-oriented game engines and frameworks.

Some people are quite happy to work in heavy-duty environments with hundreds of panels, buttons, and checkboxes. And that is totally fine.

I myself prefer a more straightforward and text-oriented way when code and mechanics are not hidden behind incomprehensive UI but sorted neatly in folders around me as plain .js files. And the same code and structure are there when I load the project in a web browser. That gives me the feeling of control and understanding of what is going on inside my game.

I’m sure there are people out there who are like me. Who is not satisfied by the “black box” approach and prefer to understand what is going on under the hood. These people are the ones I’m gonna try to reach. These are the people who can get and appreciate the vision of Collider.

And reaching those people are going to be my Hacktoberfest.

It is the first release for which I can claim more or less full help coverage. Finally, the big and complex prototypes in /hud are fully documented. And it feels good. Now I can focus on missing tutorials.

There are a lot of changes delivering more consistency and convenience.

Like Frame’s select() and selectOne() methods now support asterix patterns and JQuery/CSS-like selectors. So you can get all instances of Missile proto in /lab like lab.select('.Missile') or maybe select them by id like lab.select('#missile*') or name like lab.select('&missile*'). Consistent.

Also, select() and selectOne() are global functions now looking at the /lab node (convenient).

There are many other cool features. Like require() to require dependent nodes, defer() to schedule function call after the game loop iteration, on…() events support in /lab, and new debug console commands for the mix navigation.

And finally, the promised change for package mixes. Even when run globally, Collider.JAM uses local packages by default now, unless the –global flag is specified.

So, try the new release by installing it directly from the npm registry:

npm install -g collider.jam

Enjoy!

The framework is getting more usable out of the box. DR7 has brought an immense improvement in help quality. But we are still missing introductory materials. Simple tutorials in help and readme are all we have. Also, there is a bunch of demo mods in bits.mix that might be useful for starters. But that is about it.

To remedy this, I’m shooting a bunch of video tutorials to publish on Invadium(EN) and PowerUps(RU) channels. And also preparing a set of tutorials to publish on this blog first and some other platforms later.

I’ve established that tradition to ship Collider.JAM releases for game jams. I’ve shipped a new version for 7DRL Challenge, Ludum Dare 46, HyperCasual Jam, and GameBoy Jam.

Collider.JAM Development Release 8 is not going to be an exception and I plan to deliver it before the upcoming Ludum Dare 47.

Don’t expect big features. Many minor bug fixes and help system improvements are going to be included. Plus already mentioned tutorials.

As soon as we have a stable core covered with tests, help, and tutorials, we will deliver the last Development Release (9? 10? 11? It’s not clear yet) and start a new era for that unique and amazing framework.

Since I had my share of defeats as well as successful jams, I want to share my experience and lay down some things you can do to make the upcoming jam as smooth and productive, as possible.

Jams, Sprints, and Hackathons are hyper-intensive events and you want to be ready beforehand. Skipping preparations and just diving in can result in wasting valuable time, losing the flow, and even failing the jam.

So it might be a good idea to spend some time preparing.

Get the Tools Ready

First, you have to make sure that all your tools are in good shape.

The day before, update your software and check all the setup. It might seem to be a trivial issue, but it is not. In my experience, the team might lose valuable time fixing unexpected issues. Linux is mostly OK, but both Windows and macOS are notorious for that stupid “reboot to update” approach. Windows might even start the update automatically without confirmation. And you will end up with the “Updating…” logo instead of your favorite IDE.

You might think, things like that rarely happen. In fact, they happen all the time. It’s just that we are not in a hurry to notice and be upset about it.

But in a jam or a hackathon, everything is happening so fast. And any distraction is a flow killer for the whole team.

Imagine, that you are on-site for jamming, Wi-Fi is not that good. And you are trying to update Homebrew or download hundreds of megabytes worth of plugins for your favorite IDE. Or register in Discord to join the team chat. Or figure out how to install drivers for your new Wacom tablet…

Make sure you’ve done these things the day before, over the sweet home Wi-Fi.

Checklist of stuff to bring along.

It is a good morning. I’ve already had my breakfast. But I’m in a hurry to skip the traffic and get to the jamming site earlier. I put a laptop, a charger, a phone, a notebook and a pen in my backpack.

And on a way to the parking lot, I suddenly stop. You know the feeling… I forgot the cable for the phone. Not a dealbreaker for a jam where you work only with a laptop - the phone is fully charged after all. But it is a mobile game jam and I need the cable to check the game on the phone. Now, I have to go back… And after that, I’m stuck in a jam of the other kind - a traffic jam :)

When you are jamming on an external site, you have to bring everything you might need during the whole jam.

Make a checklist and use it to pack the stuff. Mine usually looks like this:

Items to Pack

• laptop
• laptop charger
• phone
• phone charger
• USB to USB Type-C cable
• drawing tablet
• brainstorming items
  • sheets of dotted paper
  • color stickers
  • a bunch of markers, pens, and pencils
  • various dices and tokens
  • a couple of RetroGamer issues for inspiration
• some snacks and water (if not provided on-site).

Warm-up

It is something I still fail to do all the time. And I think it is the most important of the bunch.

Warm-up sessions allow your team to setup and adjust the tools, establish means of communication and organization. It is an opportunity to discuss potential themes, styles, and game mechanics. And ideally, test-drive your tools.

Even if you plan to find your team on-site, you still have to make sure that you have installed everything that might be useful for communication with your future teammates. Again, you will avoid the download of Discord or Slack or Telegram distribution over the slow Wi-Fi.

The exact warm-up format may vary depending on a jam and personal goals.

Try to build an experimental prototype. Extend your toolbox with common library functions or typical code stubs. Sometimes, you can predict and mock-up generic features.

Before 7 Day Rogue Like Challenge, I’ve mocked up a text mode emulation and usage of Perlin noise to generate endless maps.

I’ve experimented with platform physics, transitions, and menu systems while warming up for the last Ludum Dare.

In mid-June, just before another hypercasual game jam, I’ve spent a day with my teammate to create a VS Code autocomplete feature for Collider.JAM.

Eval New Tech

Some say you should never try unfamiliar tech during a jam. Stick to what you know.

I’m not completely agree - it depends on your goals for that particular jam.

It is always risky, and some of my most spectacular failures happened when I decided to experiment with new tech.

But it can be a part of your personal goal. It is better to test out a tool during the warm-up. But a jam is a perfect opportunity to truly see the tool in the field - before you made any long-term commitments.

Just don’t underestimate the effort required to handle a new tech. Don’t try to experiment with other things at the same time - like an unfamiliar genre or experimental gameplay.

Make the project scope as microscopic, as possible. And then use the new tech to deliver it. You can extend the scope later if you’ll have time left.

Explore the Area

There is a benefit in preliminary exploring the area for on-site jams. Figure out how can you get there, where can you park, what facilities are available on-site.

Research the restaurants or food delivery nearby if needed. And sync-up with your team on food options.

Have a Nice Jam!

Following the advice above doesn’t guarantee a successful jam, nor ensures that there won’t be any problems. But I’ve found, that it makes my team much more effective and focused on delivering the prototype.

These techniques significantly reduce interruptions. And you should avoid interruptions at all costs. Since hyperfocus is the key ingredient for a successful jam.

Put additional effort to get your team in the zone, and in a couple of days, you will have an amazing prototype.

Good luck with your next jam!

Collider.JAM shell is based on Node.js and it’s supposed to be portable… In theory. In practice, there are ALWAYS some issues.

Since I haven’t been using Windows for the last 13 years or so, I didn’t have a machine suitable for proper testing. I guess it was working for some time… Then I started to do some clever stuff with module scanning and unit discovery. And when you do something fancy with a filesystem, portability might suffer.

In our case, it was a little function responsible for mapping to a full path. It worked OK on Linux and MacOS, but failed to deliver a valid path on Windows.

DR6 is the first Collider.JAM release evaluated with our new test set called Geneva. And I figured, it a nice opportunity to cover Windows support.

So I’ve found a little Windows sticker on one of my Alienware Alphas, installed the OS along with Linux, and turned that machine into a test station. That allowed me to pinpoint and fix the bug on Windows.

Now that Alpha is dedicated to testing new releases. I can run tests against a git branch or a particular version from npm repo.

The only thing missing in this config is MacOS, and I still have to use an additional laptop to complete the portability test. Maybe a Mac Mini along with Alpha can be a solution to complete my testing stand?

To avoid that in the future, more elaborated system is needed to check the release branch before a push. And the testing has to be done on a clean machine or inside a special Docker container.

Collider.JAM has a test engine implemented, but still no acceptance tests to validate a release. That is something to be delivered in the nearest Development Release to guaranty stability.

Being a solo developer working on the framework makes it hard to properly prioritize. What should come first? New exiting features, bug fixes, tooling, tests, documentation? Each is highly important. And for every release, I’m trying to figure out the main focus. And only hope that my assumptions and priorities are right and that I’m delivering a more polished and useful framework as a result.

I’ve completed major features for DR4 just before Ludum Dare 46. Only some minor fixes were included later.

The jam itself is an adventure, that deserves it’s own post or two. I will definitely cover it in the future. Now I’m exhausted but quite satisfied with the results - a survival platformer on a space station with local co-op multiplayer.

In DR4 announce, I’d expected it would be possible to deliver the release somewhere before or after the jam. But a couple of sleepless nights and the following prostration made it impossible.

Now, I’ve finished the major scope of post-jam activities. My game has already received 35 ratings, which qualifies it for the final score.

And I can finally focus on the release.

There is nothing big in DR4. However, a long list of various updates makes Collider.JAM closer to being a complete and finished product.

With DR4, you can spawn an entity from a state descriptor. So instead of a list of lab.spawn() calls somewhere in setup.js just put state descriptors in lab/ and they will be spawn automatically.

Now you can create custom post-processors for *.js and *.json files. Say, I want to post-process Ogmo tilemaps. To do that, I will create a function in /lib/ext/ogmo.js and now all *.ogmo.js files will be post-processed by that function when added to the mix.

The list of changes goes on and too long for a single post. You can run sketch mixes now, there are changes in how traps work, there are new ways to control mods, there is a new dynamic Z-ordering…

Now I will focus on tutorials to cover all these wonderful features.

Keep tuned and don’t stop jamming!

Main achievements are pretty simple - F1 and F2.

Readme and man pages have been updated. By pressing F1, you are getting much better info now. But tutorials are still missing, and that is something to fix in future releases.

Node Inspector is available by pressing F2. It has also been greatly improved. Back action works as expected and there is a proper sync between tabs.

The taken multi-tab approach has good usage potential - not just plain node exploration. I’m thinking about copy/spawn features, search, and node modifications here.

I’ve managed to deliver that release in a month (and not in 6 like DR2). Now, I’m declaring a more ambitious target - make DR4 in just 2 weeks. Ludum Dare 46 is coming in the middle of April 2020 and that is a perfect deadline for the next Development Release.

So keep quarantine and don’t stop jamming!

New amazing features are coming!

I’ve been using blogger.com for many years. Though not a productive blogger, I’ve been posting now and then.

For invasionwave.com and invaderslounge.com I’ve decided to go with Wordpress. A lot of features, but also a lot of hustle to maintain.

I don’t need any fancy plugins for my personal page. All I need is a simple way to turn markdown into HTML pages.

Therefore, this site is running on Hugo - simple and powerful static site generator written in Go.

I’m still figuring out how to do some stuff, but the overall impressions are good. It is simple and text-file oriented. An ideal choice for a unix plumber and a vim aficionado like me.

See you soon!