Frog Jumper – A JS13K Retrospective

I participated in the Javascript 13 Kilobyte game challenge this year along with 227 other game programmers. It is a month long contest that has been done since 2012. 2020 is the first year I’ve even heard about it, and I think it is an excellent contest. Check it out, and consider participating next year:

So why is this contest special? It celebrates “open web technologies” and adds the artificial size constraint to your final package size. This guides the programmer to seriously embrace the fundamentals of computer software engineering. You have no real chance to import a giant library of code, you must tap into the browser, and really focus on being creative with the constraints of code, assets, and browser quirks.

30 Days is not a lot of time if you are just getting started into web programming. But it is enough to make a basic “demo” of a game and submit, and get a t-shirt. I suggest brushing up before the contest begins on some basic html, css, javascript. Luckily I did a TypeScript project early in the year and am somewhat familiar with the web.

Here is the journey of Frog Jumper…

First Week

Read the recommended tips and tricks, and get the lay-of-the-land.

Do some calculations.

Choose some art from

See if I can get some pixel art that looks good and practice scaling it with css to make look nostalgic for me. I want to make an 80s arcade style game.

Learn about scaling modes for all three browsers… (sad)

Think to myself, I have plenty of time.

Second Week

Find a TypeScript project on GitHub to fork

Link up Kontra.js a micro game framework by Stephen Lambert.

Make some animations and think I’m really doing good.

Very little work done, mostly readying Kontra.js docs and checking into sound libraries.

Third Week

Kontra.js linked up and tested the packaging to see if i’m under size with basic animation screen.

Zipped it is 11kb so I’m ok. Then, I add the chicken.

I have no room for game!?

Only thing in it so far is WASD movement and 2 sprites.

Asking for help on twitter I switch to Parcel.js and enable some “tree-shaking” which removes dead code not used from library.

Keep shrinking and trying everything eventually i get down to 10kb!

Time to actually make game.

Fourth Week

Crunch time.

Add some sounds with Frank Forces Zynth library.

Can’t sleep, keep trying to figure out what to do for game play.

Decide to start adding emojis for inspiration.

Then make them scroll…. ok.

Lets Jump.

Ok now I understand what my games is… it is just a side scroller with a jump.

I refactor for the ability to do levels.

It is 3 days left to turn in game.

I’ll leave the rest to the GitHub commits:

Play the “final” version here:

Works on Mobile and Desktop.

Double tap to jump higher when frog is under you.

Will add more levels and fix bugs soon.

Will add more technical details fo the challenge later 🙂

Thanks to for hosting even for the 8th year. Look forward to next year.

Also thank you to all of you that helped me actually ship game. Lots of play testers from my family and work. And cheers to my wife Jessica for putting up with me and my silly chicken games ❤

Make Yourself

Owning your whole tool chain is important part of becoming a seasoned developer of quality software.

Building the software is the first step. We all love to use Integrated Development Environments (IDE) but what happens if you lose license to that suite of tools?

Your developer ergonomics are important and it is why we use those heavy weight tools like Visual Studio, the best IDE ever invented.

How would you even start rolling your own development toolchain with “free as in beer” tools?

Little Black Books

When you are cook aspiring to become a chef, you are expected to write down notes.

These are your notes, they go home with you.

When you quit or get fired. You keep the book.

In tech, it is not like that 😦

We have one way to exfiltrate some of the sauce. “Open Source”

The post that inspired this post:

I miss that blog.

I ❤ @internetarchive

The Speed of Thought

There are two types of software.

Those that you choose to use, and those that your boss chooses for you.


The “only way to do it” is sometimes painful. But if there are dollars to be made between those button clicks and some frustration, I will happily click them. Hopefully in the right order.

If I have a choice though, I will choose the program that keeps me in the “zone” for as long as possible. Every second I feel like I am waiting on the machine; is one more second I’m likely to change tasks or get distracted from what I’m actually in your program for.

There is some number… of millisecond lag tolerance. This is the most important metric and a balancing act with the value you are creating. How much of the program’s feature plays in your cash generating mechanisms? How long am I willing to wait? Remember I’m not just a user of a novel feature in your app. It is part of an entire flow that you will never see.

In the craft of turning dirt to dollars, I focus mostly on Electronic Design Automation (EDA). The vast amount of tooling surrounding modern Semi-Conductors and PCBs are staggering (and expensive). Unifying these tools for the usage of mere mortals has been my task for the past 5 years.

To me the task of the next 10 years is to optimize this flow to take seconds or minutes… Rather than years. Who will be a blackbox and who will be sherlocked?

The Mind Compiler

Reading code is the most important activity of a computer programmer. Ideally the code is then interpreted and ran as a thought experiment inside the programmer’s brain. This sounds hard, but as you learn an environment, the mind will eventually reach this level of tooling.

The ability to reason about code without running it, is the key to failing fast and often. Which you always want to do. Failing slow is painful. Just as Intellisense is a huge help for catching syntax errors early, not having to actually build & run your program, you can iterate much quicker.

Of course what happens if your internal transpiling mechanism and logic simulation units fail as you bite off more than your meat computer can handle?

Just press F5.

I recommend picking your favorite open source project and start reading. If you get stuck, just start dropping some breakpoints and calibrating your internal toolkit.

Big Idea Fridays

There are few speeches that cause me to read them multiple times. Dr. Hamming’s “You and Your Research” resonates deeply with me and is one of my favorites. Hamming, defines a work ethic and sprinkles the talk with antedotes that are both kind and relatable.

However you define great things

Dick Hamming

He gave this speech many times and prefer this written version:

I like the idea of reserving Friday’s for thinking about deep problems.

Have a good weekend.

Building Your Own Lightsaber

If you can find a piece of software that does what you need in a timely manner and is within your budget, then by all means use it and move on.  But sometimes you need a feature or a flow that can’t be bought for any cost.  You must roll your own.

I’d run for the hills if you can’t stand computers, because the only thing worse than computers is programming computers.  But if you have the muster and the gumption you to can make the computer go beep.

Chances are there are ways to make it go beep without you writing your own software but what is the fun in doing that?


The Tool Makers Dilemma…

Sometimes though, you just build to build.  This is very, very dangerous.  It is the state that I am in right now with the Session Link Engine.  I’ve learned and forgotten the web stuff a few times since I started with it in the late 90s.

The purpose of this build is to relearn the web and ship a web app.  So what do we make?  A modern wiki:



Session Link 1.0

Update Summer 2020:

This was never meant to be a single player game… Perhaps the biggest change in humanity over the past 200 years is the ability to communicate over the wire or the air thousands of miles away instantly.

The Hive Mind is a real thing and is buzzing with all of your data.  The aggregate.

I’ve been working on a proof of concept prototype for multi-user editing.  Co-design if you will.  Essentially a google docs shared cursor:


This has been my side project for a few months and it uses Typescript, React, and WebSockets.  Beware that there is no privacy features yet. So be good.

Open it up in two+ different browsers/machines etc 🙂

Standback google docs.

I will do a walk-through of the source code soon.  Here are some shots during development.

We still have callback hell here with my commando function.  It is passed into every block and is the way that everything updates.  Not sure if I will keep this but it works.

Screen Shot 2019-12-13 at 5.41.11 AM.png

Main render from “Playbox” the root component of app.  I have a file drop that isn’t being used yet.

Screen Shot 2019-12-13 at 5.45.21 AM.png

The kids these days call it hydration/dehydration instead of deserialize/serialize:Screen Shot 2019-12-13 at 5.42.03 AM.png

On the todo list:

  • Private Channels w/ XOR Key
  • JSON Deltas not full blobs for transmission of edits
  • Throttling server/client
  • Usernames/Colors not random
  • Actually Reseeding the data to new users
  • Collision Avoidance Schemes w/ Time travel
  • File Sharing
  • Markdown Editing
  • DataTable Editing

Stay tuned.

Red Dawn or Blue Sky 4

Breathing life into an old unknown codebase is one of the most exhilarating and most often a frustrating endeavor a software engineer can partake in.  Duct-tape programmers as someone once said, are a necessity.  The question I always ask myself:

Is it easier or faster just to rewrite all this shit?

Depends on where you are in your journey.  Knowing when to add another layer of lasagna vs replacing 5k lines of code with 3 python functions and no dependencies is the real key.

Baggage or Luggage?  Baggage you wish you could leave behind.  Only bring the luggage.

rm -rf