For a while I have been working on a generic draft engine for card games. In trading card games (TCGs), drafting is a way to distribute cards in a semi random way, where players interact with how cards are distributed. In the TCG world this is distinct from sealed deck (semi randomly distributed cards, but no player interaction during dustribution) and constructed (you design your deck before playing from a set of allowed cards).
Supported draft styles
My draft engine supports two styles of draft:
Grid draft: A draft style for two people where you select rows or columns of cards from 9 face up cards.
Regular draft: In this draft style you pick a card from a pack and pass the pack to the next player. It works with 2-8 players, but 6-8 is recommended.
The draft engine in action. This example is an Magic the Gathering grid draft.
These forms of draft can be used for most kinds of TCGs. Since the engine is not tied to any specific kind of game, you can draft anything you can give a name and an image. You can draft your family photos if you want to.
Drafts with custom content
The engine works by using a very simple JSON structure to supply card names and card images, it looks like this:
The engine comes with several predefined card list. Packs will then be drawn from those lists, but if you want to supply your own set (for example a cube or your own game) it is possible to start a draft where you send in any number of packs of cards using the JSON format shown above.
After looking at webtorrent a while ago I really wanted to dig deep down into WebRTC to see how it actually worked. WebRTC is a web standard that allows two browsers to set up a peer to peer connection (usually browsers only talk through intermediary servers). It also brings unreliable and unordered networking to the browser, which is great for some kinds of applications.
Searching for WebRTC and Java on Github mostly gave me some very simple applications that use a Java server to set up a peer to peer application between two browsers. There also seemed to be some unmaintained JNI wrappers for the WebRTC libs. What I wanted was a pure Java WebRTC implementation so that I could talk directly to the browser more on my terms.
Since this was lacking I decided to try to write my own Java WebRTC implementation. To limit the scope, I decided that I would only try to talk to Firefox, and only support an unordered unreliable DataChannel. Which is WebRTC’s greatest selling point for me. What I ended up with can be found on my profile on GitHub. It is not pretty or solid, but it sort of works.
Protocols
WebRTC is made up of bunch of protocols: ICE (to establish communication), STUN (binding and NAT traversal), DTLS (encryption), SCPT (over UDP) (message flow control), TURN (fallback for difficult network situations, which I have chosen to ignore).
The initial part of starting a WebRTC connection uses the ICE protocol, the ICE protocol is typically carried out over an encrypted WebSocket connection, though you can use encrypted pigeons if you like.
To be honest I have not looked a lot at ICE, but the parts most relevant for WebRTC works a bit like this:
A goes: This is my password and certificate signature, this is referred to as an offer.
B goes: This is my password and certificate signature, this is referred to as an answer.
Then A and B send each other different options of connectivity as candidates. I am currently blissfully ignorant of how this is supposed to work, in my current implementation I just send the first candidate from the browser and replace IP, port and auth data in the response.
The message format used in the browsers WebRTC implementation for offers and answers is JSON containing an SDP. The SDP contains tons of information that is not used (afaik). The values I have touched are marked in green below, for more information about the fields, this is a great overview.
The important parts of the offer and candidates, this is SDPARTA!
192.168.1.100 58713 – Your offered address and port.
STUN
Once candidates have been exchanged, a STUN binding request is sent to establish connectivity, this request must be responded to with a binding response with a xor mapped address. The received message integrity hash is a HMAC-SHA1 which can be checked against the message hashed with the ice-pwd as key.
DTLS
After the STUN the next step is a DTLS handshake. Thank you Legion of the Bouncy Castle, without you I would have given up here.
Over the same UDP socket where DTLS is running, STUN must be multiplexed. STUN is here used to send “consent” requests every X seconds. If you do not respond to the STUN the browser reports ICE error and shuts down the connection. Bouncy Castle DTLS will silently drop these STUN “consent” packets, so this was a pain to figure out and debug.
SCTP
Once the DTLS is set up an SCTP connection is initiated. SCTP can be configured to work in all constellations of ordered/unordered and reliable/unreliable.
SCTP over UDP challenges
With SCTP over UDP several issues crop up. My main languages are all JVM based (Kotlin, Java). There is no SCTP implementation in Java, but there is an API for the systems SCTP. The API is very hard to integrate with an UDP socket though (I tried a bit, but it seemed very hard), so the simpler solution is probably to use a userland C lib like the one used by libjitsi.
Sadly i did not know libjitsi existed so I started hacking my own SCTP implementation in Java land. Way more fun…
Writing my own SCTP implementation
The SCTP spec is mostly ok, if a bit unclear in some parts. Once I found the SCTP parameter list it got better. It should also be mentioned that SCTP uses a CRC32C for checksums, this differs from the one used by STUN. This took me quite a while to figure out.
I currently have a very minimal “working” SCTP implementation. Meaning that it can talk to a browser, but does not shut down nicely, and does not do congestion control, and does not handle resends properly. These are very tricky areas to do well, and I have no clue, so I will probably change to use the lib used by libjitsi.
Getting the all important firefox logs
To not go in blind when debugging, logging from the connected browser is invaluable. This is my script to run firefox with WebRTC logging. The different modules can be turned on and off by not including them in the NSPR_LOG_MODULES. It took me a while to figure out the correct modules, so hopefully this helps someone else.
Yesterday I finally finished some of my planned Artifact updates. The new version can be downloaded from here. Below is a detailed account of the changes in this version.
Added a game mode (rascal), where you can not lose:
As my 4 year old daughter was playing the game I had to keep typing cheat codes to keep her alive. This made me realise that I could introduce a game mode where it is not possible to lose, and where the player has infinite resources. Once I added the rascal mode she played for quite a while, and she even figured out some smart plays all by herself.
Rascal mode allows exploration of the game in a different way. Hello integer overflowing high score!
Removed global score tracking:
Global score tracking from games not played on a server will always be prone to modified clients posting fake scores. This can be mitigated though obfuscation, but not really solved. My implementation was also very bad, and very hard to maintain. Maybe I’ll revisit this one day, but for now I am glad its gone.
Removed hash checks of local data:
I do not care if you hack your local files so that you have insane scores. Hack the game all you want!
Prepare for OS X removal of some carbon audio API:
I kept getting this message in my logs:
WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API’s in AudioComponent.h
The solution was to upgrade openal-soft by building from source, and replace the old openal.dylib that came with Slick2D with the libopenal.dylib built, which I guess uses the API Apple wants you to use.
With the discovery of a possibly habitable planet around one of our closest stellar neighbours, it has become clear that sooner rather then later, there will be aliens and UFOs around.
A new hope
This summer, UFO Hunter, a simulator for waging war against UFOs was revived and released to the public.
Our consultant getting accustomed to the simulator.
Since the future of humanity rests on the shoulders of this simulator and spacex, we have called back one of our most important assets (a veteran from future wars carefully regrown from DNA retrieved in the Artifact) to perform a thorough test of the simulator.
The force awakens
In the spirit of Shi Qiang, Lou Ji and Thomas Wade, we at BitBreeds have declared for the humans. Like our spacex and UFO Hunter friends, we have set our sight on the stars, and we are going for the goal.
Lately I have been looking into WebRTC which is an open standard for real time communication between browsers. It allows communication styles in the browser which previously were not possible.
WebTorrent uses WebRTC for a protocol similar to bittorrent. Instead of having to download a program or install a browser plugin, you can download a webtorrent (which currently must be seeded as a webtorrent, by forexample instant.io) directly in the browser.
To test Webtorrent, I made a small javascript project. WT-widgets, is a collection of graphics for starting webtorrent downloads and showing download progress. Below is an example where you can download Artifact for Mac OS X using webtorrent.
No seeds
If there are no seeds, you can seed the file yourself by visiting the differently styled button below. This button uses a feature of WT-widgets that does a fallback to XMLHttpRequest after 5 seconds. When it is finished downloading the file, it will start seeding. Then the first button should work, since there is a seed.
The file will be downloaded in your browser, and you can then copy it to your filesystem by clicking the link that appears when the file finished downloading. This does not follow the usual download flow, so one of the aims of WT-widgets is to ensure that it clear to the user that a download is happening. I am not sure how well my widgets succeed in that regard, as my current widgets might not be the best at communicating that there is a download happening.
Suggestions or pull requests with fixes/additions are always welcome. I hope to expand WT-widgets with some widgets that show progress horizontally, as well as some widgets that more clearly show when it is in the different states of a download.
What Webtorrent sorely needs
While seeding in the browser works great, I do not want to have a browser fired up at all times to ensure there are seeds for my content. The best option I found for seeding webtorrents was webtorrent-hybrid, but when I tried it, I sadly could not get it to build.
Once Webtorrent has a solid solution for server side bootstrap seeding, I think it is will become a great alternative for distributing some kinds of content.
For some reason Artifact-1.0.2 would crash on level 10+ on some OS X installations. This seems to stem from some issue with my LWJGL version, the bundled JVM and those OS X installations.
Artifact-1.0.2.1 includes a later JVM which seems to work in my tests. If you experience any issues with it please report using the address here.
Last year i got a kindle for Christmas. This is a review of all the science-fiction books it contains at this moment, with the exception of Robert A. Heinlein’s Starship Troopers and Joe Haldeman’s Forever War (This post is already way too long and these are pretty well known books). For each book/series I’ll try and give a very short description followed by my thoughts.
The TLDR; these books provide a balanced diet ;-).
Someone (not humans) has built a space elevator in Darwin Australia. After some years a disease either kills or turns everyone into zombies except in a safe zone around the space elevator.
The dire earth cycle is a quick read, and an entertaining one. It was way better then I expected. Sometimes it goes into these very long and meaningless action sequences; you can safely skim those.
The story follows an AI fragment from the Radch starship Justice of Toren. This fragment is all that is left after the starship was destroyed. While Justice of Toren plans revenge on its destructor, we get flashbacks to its previous life as a ship AI in service of the Radch.
I do not have enough positive things to say about this book. The main character is extremely well written. The pace is good. I’m really looking forward to the third book in the series. If you are going to read it, do not read about the book first, it might spoil some parts which it is worth not to have spoiled.
We follow the first 100 colonists of Mars as they colonize and attempt to terraform mars.
Of all the books on this list, this series really stands out as different. Most of the time the book follows the everyday work of the 100 colonists as they work, scheme, and daydream. There is no good and evil here. While the political views of the author shines through it never feels like preaching. On the negative side the book has travel descriptions that makes the travel descriptions in Lord of the Rings feel like short strolls. Still the series is one of my favourites.
Set in the same universe as the Mars Trilogy. It follows some of the same style, but the pace was a bit faster. The story has a lot of references to the Mars Trilogy, so it might be better to read that first.
We follow the master of ‘Holywelkins Orchestra’ on its tour from the outer to the inner solar system. On the way it becomes clear that the orchestra is immensely powerful. And also some cult controls Mercury and therefore the power distribution to the rest of the solar system.
That probably made no sense. The book seemed to make sense (and was enjoyable) for the first half, then it stopped making sense. Too weird for me.
In the future humanity figures out a way to suspend time in bobbles (allowing time travel to the future). The main character is unwillingly suspended and returns to a worlds where human civilisation is gone and only a few humans (bobblers from varying degrees of civilisation) are left, including his suspender.
Vernor Vinge does a very good job with his concepts. He introduces the rules of his universe and then follows them. This book is short and to the point. No infinite traveling on Mars; no zombies. A very enjoyable read.
Our galaxy is divided in zones that allow different sorts of intelligence and technology to arise and be used. We follow humanity which has traveled to the Beyond where AI and FTL travel is possible ( Earth is located in the Slow zone where these things are not possible). The outer zone is called the Transcend, where the beings are basically gods. Trying to enter the Transcend from the Beyond, some humans fall into a trap and release a being which threatens all life in the beyond. A ship escapes the trap with information on how to counter the being, but strands on a world with wolf like creatures with group-minds.
Very interesting concepts and quite well executed. A lot of the book is written from the perspective of packs which are group-minds of several individual wolfs. For me these chapters were initially hard to follow, since I do not think it was explicitly explained that these were group-minds.
This book takes place in the Slow zone (no FTL). Two human space traveling civilisations discover a world which orbits around a star that is only active for one year every 250 years. On this world lives a species of spiders which will soon reach space. The two human civilisations clash over the right to trade with/enslave this species. The clash leaves them both crippled though, and they need to cooperate while waiting for the star to wake and get new resources from the Spiders.
I liked this book more then A fire upon the deep. There are some parts about layered complex software growing over time (they have very old software on their spaceships, like if glibc would be used several thousand years in the future), which to an enterprise programmer almost feels way too believable.
Arik must figure out artificial photosynthesis, or his not yet born child will cause the colony he belongs to on Venus to eventually run out of of oxygen.
I was really surprised by this book. It has some great plot twists, and was very difficult to put down. I am currently in the process of reading the sequel Equinox. These books both has very brief encounters with zombies. Thankfully very short, but they would be better without.
Humanity has reached space and has settled several planets, but it is in conflict with several alien species over territory. This conflict is handled by the CDF (Colonial Defense Forces) who is in constant need of new soldier on a very deadly battlefield. These soldiers are recruited from an overpopulated Earth where the CDF controls the only access point to space. To keep the stream of soldiers the CDF largely keeps Earth in the dark of their technology and stategies. The series explores the conflicts with the alien and the political struggles resulting from this situation from the perspective of the soldiers and political figures caught in it.
The overall quality of this series is great. If you liked Starship Troopers you will most likely like this. I do not think any single book of the series is as good as Ancillary Justice, but I read every new book in the series.
I made a small scripting language that runs in the browser. It is very ninja. To see the ninja, first open Javascript console and write:
function recur() {recur()};recur();
Hopefully it blew the stack. Then type this into the Scape REPL:
def recur() recur(); recur();
When you are convinced it will infinitely loop without blowing the stack, hit ctrl-c to stop further processing.
Rincewinds rave, that is black magic! Also called tail call elimination. Scape code is not evaluated by snarfing functions from Javascript (JS functions do not have tail call elimination before ECMAScript 6), but instead is compiled to its own set of instructions, which are then run on a stack machine (running in the Javascript VM). During parsing Scape functions are checked for whether they can use tail call elimination. If they can, they get different instructions that reuse the existing stack frame.
More magic
Scape has forward mode automatic differentiation as a language feature. Automatic differentiation allows you to compute the derivative of a function, without having to define the derivative explicitly.
Without automatic differentiation, this would be the way to compute the partial derivative of the function for and :
def fun(x,y) * (* x x) (* y y);
def diff_fun(x,y) [* (* 2 x) (* y y),* (* 2 y) (* x x)];
diff_fun(4,5);
[200, 160]
With automatic differentiation in Scape, this is how it is done:
def fun(x,y) * (* x x) (* y y);
diff(fun(4,5));
[200, 160]
This is very useful for a number of numerical methods involving derivatives. The feature is currently experimental, it might interact with non-double types in funky ways.
Wai?
Mostly just for fun. I also started toying with the idea to make a safe scripting language for use in networked games. A language and runtime that would allow the player to define custom logic during gameplay without being able to ruin the experience for other players.
A dream would be a personalized Starcraft where it is you and your custom control scripts versus the other player and his scripts.
I hope to create a simple real time multiplayer game to show how I imagine it working. For now, playing with the Scape REPL is the only way to try the language.
My 3 year old daughter’s current favourite book is Jakob Martin Strid’sDen utrolige historien om den kjempestore pæra. In the story a giant pear is made hollow, and eventually turned into a boat. I decided to try and make a similar upright floating pear-boat out of a normal pear. One that my my daughter could play with once finished. Off I went to buy a pear and tools, the pear I ended up with have these specs:
Weighs around 238 g.
Displaces approximately 225 ml of water. This means it is slightly more dense then water since the weight of that water would be approximately 225 g.
Judging from the pears available in the shop, the one I chose was slightly more symmetric then most pears.
In addition to the pear, the tools I used are shown in the image below:
Pear, knife, melon baller (the MVT in pear pram construction), coins, thread.
The first step in pear pram creation, is to cut the windows using a knife. Once that is done carve out the inside using the melon baller. I recommend making the windows close to the top of the pear. If you make them too low they will result in water intake when launched. It is better to create the windows high initially and expand them downwards once you have a feeling for how the pear floats.
After carving out the core and flesh.
Another great reason for making the windows high up is lowering the center of mass. Pears have not yet been cultivated to float upright, and the center of mass is way too high for that. Having a too high center of mass on a ship is catastrophic. In its unmodified form a hollow pear will most likely perform worse then the Vasa on its maiden voyage.
To lower the center of mass even more, it is important to carve out as much as possible of the “roof”. Since the stalk extends into the pear this is difficult. It is easy to ruin the pear if you use too much force; be careful.
Even with the windows high up and a very light roof, the center of mass is still too high. Initially I added coins on the inside as ballast, this worked if I put the pear very carefully into the water, but it was still prone to capsizing.
Coins on a thread prevents capsizing. The pear is finally approved for transport of Lego men
To remedy this I moved the center of mass even lower by adding ballast on a thread below the pear. This was done by creating a knot on the thread and using a needle to get it through the bottom of the pear. Then the coins were added as shown in the picture. To ensure that water would not leak along the thread into the pear, I greased the entry points.
In its finished form the pear is quite stable, it could hold a surprising amount of Lego men without capsizing. I never got around to test adding a sail, but I think it might be stable enough to support a small sail.
Sadly rot is an inevitability facing all pear prams. If you have a great idea for prolonging pear pram life, please leave a comment.
Today I released Artifact-1.0.2 after finally getting my ass around to create a close to fully automated build script for Mac OS X (a topic for another blog post). The full changelog is listed below, but I instead recommend you go get it and try it!
New second orb graphics
Changelog:
Added full screen and resolution management in game.
Removed splash screen.
Adjusted difficulties and added new names (Apprentice, Journeyman, Master).
Added additional fire button, allowing better control using a touch-pad.
Redesigned second orb with additional graphics and new behavior.
More in detail:
The splash screen in Artifact was unnecessary and the only issue keeping me from removing it was having in-game window and resolution management.
See above.
The Normal and Hard game difficulties were hardly different in version 1.0.0, while the Not sane difficulty was extremely hard. Now the Apprentice difficulty is much easier then the old Normal, Journeyman is similar to the old Normal, while Master is slightly easier then the old Not Sane difficulty. The change was mainly done to make the initial difficulty easier for new players.
On a touch-pad moving the mouse and clicking might interfere with each other, so I added an alternate fire welder button for those who might prefer that.
The Second orb was very hard to predict and its mechanic felt wrong. The new version is cooler , and most of the time way easier to predict. It also has a slight comeback factor, which is nice in this cutthroat game.
for 
and 
:
