I’ve made several toy games with friends, but whenever it came around to adding some simple multiplayer support, getting the networking running was always a royal pain. It seemed like each game had so many special cases for how game-state needed to be synchronized between players that it was impossible to decouple the netcode from the game logic. I wished for a network library that could handle all the state synchronization for me, but I could never find one.
The trouble is that most existing “game networking libraries” are actually mostly data transport protocols (built over UDP). These help ship the data to its destination more responsively than TCP and more reliably than UDP, but usually don’t help much with the coordination/synchronization of game-state between players. So I decided to make one myself! And I did! (It only took me 3 years; turns out it’s kinda tricky.)
I have a simple, working, and hopefully actually useful implementation at github. Read more on Game Networking Made Easy…
So you’ve been studiously committing your changes early and often only to discover that, for whatever reason, you really wished you’d been committing your changes to a different branch. Now what do you do? Is there a way we can just move unpushed changes onto a new branch? Actually, Yes!
1. Make a Backup
First of all, in order to do this we’re going to need to use the mercurial rebase extension to essentially re-write (unpushed) commit history. Rebasing is one of the few mercurial commands that can irreversibly destroy changes. Fortunately, we can easily create a convenient backup by just creating a local clone of the repository.
Make sure you don’t have any uncommitted local changes, and then do:
hg clone path/to/original path/to/backup/
Now that we have a good backup, lets get started. Read more on Moving Unpushed Changes to a New Branch with Mercurial…
I was recently working on a project where I needed to be able to tell (in an automated way) if the versions of two builds matched. The project provided version info that consisted of a manually hardcoded version number and timestamp of when the source was built. This was problematic. The manual version number was incremented rarely and so was useless for day-to-day development. And the timestamp would only tell you when that particular build was generated but not what source was used to generate it. This made it difficult to trace down bugs as it was nearly impossible to know for sure what source a build was generated from.
So I set about to come up with a good replacement.
What Makes Version Information Useful?
Here are the things we wanted from version information:
- Determine if two builds come from the same source (even if built on different machines, at different times).
- Easily find the code associated with a particular build.
- Easily determine approximately how old a build is; compare age of versions.
- Provide an easy mechanism for the user to tell different versions of builds apart.
Read more on Creating Automated Build Versions During Development…
I’ve been using *nix systems for quite a while. But there are a few commands that I somehow overlooked and I wish I’d discovered years earlier.
1. man ascii
This prints out the ascii tables in octal, hexadeciamal and decimal. I can’t believe I didn’t know about this one until a month ago. I’d always resorted to googling for the tables. This is much more convenient.
ASCII(7) BSD Miscellaneous Information Manual ASCII(7)
ascii -- octal, hexadecimal and decimal ASCII character sets
The octal set:
000 nul 001 soh 002 stx 003 etx 004 eot 005 enq 006 ack 007 bel
010 bs 011 ht 012 nl 013 vt 014 np 015 cr 016 so 017 si
020 dle 021 dc1 022 dc2 023 dc3 024 dc4 025 nak 026 syn 027 etb
030 can 031 em 032 sub 033 esc 034 fs 035 gs 036 rs 037 us
For more information, see the ascii man page.
Read more on 5 Unix Commands I Wish I’d Discovered Years Earlier…
Haskell is my language of choice, and one of the features that I miss the most when working in a different language is algebraic data types. I get particularly frustrated about the lack of algebraic data types (and the associated destructuring) because they are so simple. You don’t need any fancy runtime features to make them work. It would even be feasible to make them work in C, for goodness sake.
If you are unfamiliar with algebraic data types, you should check out Rust’s enum data type. Rusts’ enum’s are algebraic data types, and I’ve found them to be the gentlest introduction to their usefulness. The Algebraic data type wikipedia entry is also decent and a bit more thorough. Read more on Simple Algebraic Data Types for Ruby…
Posted in Ruby Tagged haskell, ruby
In one of my previous posts, I described an implementation of miniKanren in Haskell. I have since been improving the implementation.
I am currently working on the third iteration of my logic library. The first one was described by my previous post. The second is in a GitHub repository. I have yet to settle on a design that I really like, but I thought I’d post something about what I’ve been working on.
The key improvements in the second iteration were the ability to easily add custom data types and the addition of a
match function. The custom data type addition was pretty straightforward. Read more on Towards a Haskell Logic Library…