untitled13

In 2012 I found the js13kgames game development competition where the goal is to submit a HTML-CSS-Javascript game which is not more than 13 kB (13312 bytes) ZIPed, developed between 13th August and 13th September. It is also required to publish the uncompressed game code on GitHub – this way one can prove they created the game and more importantly: others can learn from it.

This last part was what got me, I was really curious how others fit games in such a small space – what later turned out to be much more than it looked on the first sight.

As the competition was already halfway or was over when I found it (I can’t really recall) I could only examine others’ entries and decide I will participate next year, in 2013. I also tried to gather some ideas and set up a concept before the competition start date – strictly not a line of code was written.

There is a theme each year (which is optional but worth bonus points if honored), for 2013 it was bad luck – and I skipped it entirerily…

Okay and now about my entry.

My concept was to create a 2 player networked tower defense/tower attack game.

I must admit I am really bad at naming things, I just called the main (and only) client side file 13312.js and not long before the deadline I came up with the exceptionally uncreative name untitled13.

Of course to fit in 13 kB entries usually do not use existing engines, they are written from scratch – a thing I don’t mind at all, I’ve been always curious about the details and liked the control one has when starts from the ground up.

For graphics and animations I decided to go with a fixed color palette and dynamically generated content. All the objects consist of one or more layers rendered by a function that takes a string that describes a series of commands and their parameters. It turned out only two commands were necessary, a “draw a closed polygon filled with a color” and a “draw an alpha overlay” for shadows. The parameters were simply X and Y coordinates of the points, represented as characters in the base64 character set (64 distinct values), multiplied by the size of sprite. (For example: sprite size is 64×32, string is “AAAzjj”, therefore the coordinates are 0;0, 0;25, 35;17).

The map consists of starting points for the attacker, paths for the units to walk on, path intersections with switches, a few objective tiles for crystals the defender has to defend and concrete blocks to build the towers upon. There are three types of monsters with different parameters (speed, health) and three towers with different parameters (attack type, damage).

The networking approach is pretty simple but the most interesting part: the initial state is known to both players (the map is fixed in the entry version, in later versions it is randomized but the seed is shared), the mechanics are known as well and the actions can be described easily. So I came up with the idea to run a whole game instance for both players, create delayed action queues for them and synchronize them. When one player clicks a button the action is added to their queue with the configured delay, sent to the other player’s game, and a bit later executed on both instances at the same moment.

To get this working I needed reliable advancement of simulation steps, one that is not affected by skipped frames. I created a tick() method that steps the simulation by exactly one time slice (one simulation step), so when a frame is requested by the browser I calculate how many tick should have happened up until then since the last frame and call tick() that many times. (I usually go with this method to keep games frame rate independent – skipped frames are less worse than game slowing down.)

As both players are running the same game (only playing different sides), are aware of every details (only hidden from them), all events are happening at the exact same time, the game should play out identically for both of them. Later I learned this is called simultaneous simulation and it is the core of great games like Age of Empires, Starcraft and a lot more.

In this form however there is a serious flaw. There is no guarantee that the actions will reach the other player before they are due, it is blindly trusted that it will. For example: Let the action queue delay be 10 frames. The defender clicks to build a tower at frame #100, this will be executed at frame #110. If the network lag is say 7 frames then the other player gets the notification at frame #107, still 3 frames before execution, the tower gets built at frame #110 in both instances and shoots the attacker just before it reaches the crystal. But if the network lag is more than the queue delay, say 13 frames then at frame #110 the tower gets built in one instance, then the notification arrives at frame #113 for the other player, tower gets built at frame #113 when it’s already too late, the crystal was reached and the game is over. In the defender’s instance the crystal is saved, in the attacker’s the crystal is destroyed – the game is out of sync.

To address this the other instance must be notified about no action as well periodically to make sure nothing is missed. And when there is no info, the game should pause and wait until it arrives. This is a feature I had no time to think through and implement before submitting my entry.

The server part is running in node.js (my very first application) and it is very basic, it just matches the players by their IDs and passes the messages between them.

Random minor thoughts: The map is a hexagonal grid, which made finding neighbour tiles for concrete block and fog calculation ugly, but it looks so much better than a square grid – although it is handled like that. The map has fog to hide tiles that are too far away from units/towers. The UI is usable but confusing and unhelpful at first.

The project is on GitHub, the version I submitted is in the js13kgames-2013-entry branch. I like to commit often (and to have descriptive commit messages) so the submitted version had 381 commits, but for some reason I have not uploaded the final ZIP file, it was around 11255 bytes of 13312, so I used up 84.5% of the limit.

The game was better received than I expected, it ranked 1st place in Server category and 9th place in Desktop category.

The competition had awesome prizes including various licenses for game engines and gamedev related services, ebooks, physical books and vouchers. It was organized by Andrzej Mazur who tirelessly did an epic job, I’d like to thank him again for organizing and hosting this event, finding sponsors, arranging prizes and of course organizing the event annually since then, so thank you Andrzej!

Check out js13kgames.com for previous and upcoming competitions.

101hero troubleshooting: skewed print

I’d like to cover the most common issues faced during first prints using a 101hero.

One of the most common is the skewed print, like in the following images.

Photo by Bogdan Bóg Anczarski posted in 101 Hero (Unofficial) Facebook Group.

This is most likely because of the stepper motors skipping steps. The problem can be traced back to one of two reasons: a belt touching the pylon or too high printing speed. Fortunately both problems can be fixed easily.

First check all your belts during a print. See if any of them is touching the plastic of the pylon, rubbing against it. If yes then check the pulley/carriage attached to the belt, find where the belt is fixed to it. Try to push the belt a little to the front or the back. If this does not help you can also try to loosen the screw holding the bearing in place on the top of the tower a bit.

If you see no problem with the belts it can be a problem with the stepper motors moving the belts. If the printing speed is too high then the motors tend to skip steps. The 101hero is not a fast printer, the stock motors support up to 14 mm/s printing and travelling. Unfortunately in some cases this speed is still too high for the motors even with stock motors and stock GCode files (from 101land.com).

If you have the model you should try to reduce the speed of the printing by configuring the printing as well as travelling speeds to no more than 14 mm/s, maybe down to 10 mm/s.

If you do not have the model but only the GCode file (the ones that can be downloaded from 101land.com) you need to add a command to reduce the printing speed to a certain percent. Open the “101hero” file on your SD card with a text editor, find the line starting with G28 (“Move to origin/home”), and add a line right after that stating “M220 S75”. This command is “Set speed factor override percentage” and the parameter is the percentage (14 mm/s * 75% = 10.5 mm/s).

If printing with these settings fixes the problem then you should try to use higher printing speeds (or higher percentage) to see what is the speed your printer is still reliable at.

If you still have the problem leave a comment here or post in the 101 Hero (Unofficial) Facebook group.

101hero: Assembling the printer

The first part covers the short story of the printer, the contents of the box, a few tips and warnings about the ways you might damage your printer unintentionally (if you have not read these you should).

This part is about assembling the printer step by step.

First connect only the PSU to the controller and switch it ON and OFF, the red LED should light up when it is ON.

Now connect the motors and end-stops to the controller (do not assemble anything yet) and attach the SD card slot. The intended order of the pylons as well as the motor-end-stop pairings are below:

After connecting these put a simple “go home” file on your SD card and then power it up. The motors should start moving the carriages (all three at the same time) until one hits its end-stop. Then the other two should stop and only that should move back and forth triggering the end-stop a few times. After this the remaining two should do the same one by one.

If all three carriages hit the end-stops then congrats, you have working motors and end-stops, this is a good start! If not… well then you are in the unlucky group of quite a few people, including me. In this case check out the 101 Hero (Unofficial) Facebook group.

You can restart the procedure by pushing the reset button or power cycling the controller board.

Now on to assembling the printer!

At the top of the pylon arrange the red-black cable of the end-stop so it goes through the shaft:

At the bottom of the pylon the red-black cable should go through the shaft just like above and arrange the cables of the motor like on the picture:

Make sure for each pylons that the spring on the belt is tight to provide tension…

… the belts are properly on the wheel at the top…

… and the bottom:

 

If the belts are off the wheels try to put them back carefully. If that is not enough then you can loosen the motor a bit by loosening the two screws holding it in place (3mm Hex Socket aka Allan heads). If you have to remove the belt tensioner spring here’s a video how to put it back.

Next, assemble the bottom plate and the three pylons (4 pcs of M4x12 self-tapping screws (PH1 head) for each pylon):

And then add the top plate (2 pcs of M4x12 self-tapping screws (PH1 head) for each pylon, NOTE: the two inner holes remain empty on each end on the top):

And now fix the effector to the rods. The facing of the head does not matter but it can be useful to see the fan (to see if it is working) and the door (for change filament) from the front. The first screw…

… the second screw (you can safely leave it hanging)…

… and the rest:

Now stick some painter’s tape to the glass plate (you don’t need to cover the whole glass just make sure you have no overlaps of the tape) put it on the bottom plate and fix it in place using the paper clips like this:

Now connect the rest of the cables to the controller box:

Next step is to load the filament. The extruder assembly has a door you can open, this door pushes the filament to the extruder motor which is supplying the filament to the heated nozzle. Open up the door and put the filament in at the top of the extruder assembly, guide it into the tube after the motor, like this:

When completed close the door and tighten the screws (2 pcs M3x12 self-tapping screws (PH1 head)).

After completing this step the printer should look like this:

Which is a mess. The cable management is pretty much non-existent for the 101hero by default. People use different cable organizing methods, the most popular is the spiral wrap but personally I like the zip tie method which is nothing special just zip tying the cables at a few centimeters interval, like this:

After completing this step you should cut the ties short, of course. One more thing I did was fixing the bunch of extruder cable to the top plate to an unused hole like this:

You need to leave about 25 cm (10 inches) of cable between the fixing point and the extruder assembly so the hot end can reach the farthest point safely.

And that’s all about assembling the printer. The next post will be about how to calibrate the 101hero.

101hero: Hello

The 101hero is a pylon 3D printer that had a campaign on both IndieGoGo and Kickstarter with early bird prices of US$ 49 and retail price of US$ 99 on 101hero.com.

First of all, the 101hero team’s goal was to create “The World’s Most Affordable 3D Printer” as they said and not the the printer you should start your 3D printing adventures with and this can be seen in a few places. Nevertheless, the printer is functional and the prints can turn out surprisingly nice if one is willing to spend enough time and don’t mind the hassle but if you’re new to 3D printing and you want a printer that works out-of-the-box, this one is not the best choice.

I backed the IndieGoGo run and have received the printer in January, 2017. I am new to 3D printing this is the first one I bought and the first one I ever printed with, In these posts I will share my experiences, tips I find useful and caveats.
The printer comes in two versions: the CV (Consumer Version) and DV (Developer Version). The only difference is that the DV has a USB port and can be connected to a computer while the CV can only print from SD card (which is not part of the package).


Assembling the 101hero is pretty straightforward but before getting started check all the components that should be in the box:

  • 3 pylon assembly – they are identical except for the length of the wires and labels, there should be an end-stop microswitch (to detect that the carriage reached the top of the pylon), two slide rods, a belt, a carriage (fixed to the belt, sliding on the two slide rods, fixed to effector rods) and a motor
  • 1 controller box
  • 1 SD card slot
  • 2 plates – one for the base and one for the top
  • 1 extruder assembly with effector – the “head”
  • 1 bunch of filament – the printer comes with black or white, I bought the green separately
  • 1 roll of painter’s tape – to help adhesion of the first layer printed
  • 1 glass plate
  • 3 paper clips – to fix the glass plate to the base
  • 6 pcs M3x10 machine screws (PH1 head) – for the carriage-straw/strand and straw/strand-extruder assembly
  • 18 pcs M4x12 self-tapping screws (PH1 head) – for pylon-base and pylon-top
  • 2 pcs M3x12 self-tapping screws (PH1 head) – for door fixing on extruder assembly (identical to the ones used for end-stops in early editions)

In early editions the end-stops are hitting against M3x12 self-tapping screws with PH1 heads, I have read that later they switched to Hex Socket (aka Allen) types.

Before assembling the printer I would like to tell you some basics and recommend to do further checks.

When the printer is powered it looks for a file called “101hero” on the SD card and starts to execute it (i.e. printing, moving, etc.). The file is a G-code file and has no extension, it is just “101hero” (when saving the file using Notepad on Windows to prevent it appending “.txt” change the “File type” drop-down to “All files (*.*)” or put the file name between quotes).

The button on the controller box simply resets the printer that causes it to re-initialize and looking for the file and execute it.

The pylons are identical except for the cable lengths and the labels that are on them, that is you can have them swapped and even replaced from a different package, they will work. One important note however – the end-stops are used to detect when the carriages reach the top of the pylon so the motor-end-stop pairs need to be kept consistent, if they are not then the controller will keep moving the carriage until you turn the power off.

A big warning: the power is not only sourced from the power connector but from USB as well – that is as long as your printer is connected over USB it will power the board – regardless of the power switch! Yeah, if you slide the switch to OFF the board will still be powered, although the printer will not operate properly due to the low current but you can damage the printer if you short something.

One more big warning: the controller has no flyback diodes to protect itself from inductive spikes. Simply put: only move the carriage slowly by hand because the motor generates current that will be fed back to the controller. If the current is too high (due to moving fast) it might damage your controller. Although I have not tested it yet, it might also be fed back over USB damaging your computer as well.

The printer has basically no customer support. As of March, 2017 the 101hero team is still busy shipping packages and really unresponsive to support questions, however there is a really active group on Facebook, the 101 Hero (Unofficial) and a forum at 101user.com.

Now it is time to start connecting things, meet me in part two.

Fun with Planets and a DSLR camera

I have a cheap fully manual Dörr Danubia f8/500mm lens that I bought back in 2012 for shooting the Venus transit. Since then I used it to take some Moon pictures also and when I am doing so I tend to use stars to find the correct focus – the smaller the star appears the better the focus.

In June I was out for shooting again. I mounted the lens, found some bright spot but despite all attempts I could not focus it into one point. I was wondering about what could I possibly do wrong until… no, that couldn’t be, could it? Could that spot not be a star at all?

A few pictures and corrections later I was astonished by the fact that I could capture a planet (other than our own, of course) with my DSLR and a cheap lens. Of course, the image quality was bad but, that spot was Saturn.

saturn1_600x200

These pictures were taken directly from the camera, they are only cropped and stitched into one file. A few days later I spotted Saturn again:

saturn2_600x200

 

And then I checked out Venus…

venus_600x200

… and then Jupiter.

jupiter_600x200

And I will not tell you what this is in the last picture:

sun_600x200

Actually it is not just the Sun but Venus as well from the Venus transit on 6th June 2012.

All images above were just cropped but not scaled, therefore the size of the bodies can be compared to each other.

And since then I have a new hobby… :)