For the last two years we’ve run informal, rules-free, open to all, game jams in the month of November as an alternative to the NaNoWriMo novel writing event. These have traditionally been hosted by Tom Larkworthy, who has since moved to San Francisco to work on exciting new projects in a challenging new climate. But[…]
With the 2014 Global Game Jam fast approaching I have been asked a few times by new participants what they should take with them, and how they should prepare. Wikipedia defines a game jam as “a gathering of game developers for the purpose of planning, designing, and creating one or more games within a short span of time“, they are a wonderful experience for anyone interested in game development. They are often suited to any level of experience, as participants can form themselves into teams with total strangers of compatible skill-sets. Often people will volunteer to take a role that they know little about, experiencing a new side of the development process or polishing rarely used skills.
The Global Game Jam is a yearly event, taking place simultaneously around the world with a single theme given out to all participants. The event itself lasts for 48 hours, a very long time to be awake and developing, but a very short time to put a project together with a team of people you may have never met before! This makes it quite an exciting challenge that deserves at least a little preparation and planning! To that end I’m going to give you a few ideas and tips from my own experience. Ultimately a game jam is about being yourself, creating something, and having fun. There is no right and wrong, and it’s not a competition! Your experiences will vary, and my suggestions are only a rough guide. (Please note that none of the links in this post are affiliate links!)
Firesafe has just been developed and uploaded to github
Firesafe is a technology to enforce data integrity, and enable complex transactions, on Firebase.
Firesafe compiles hierarchical state machines (HSM) definitions into Firebase security rules. The Firesafe HSM language is expressive, and a super set of the Firebase security language. Adding consistent, concurrent and fail safe protocols to Firebase is now a whole lot simpler (e.g. cross-tree transactions).
Firebase is already the future of databases, offering scalable low latency database-as-a-servie. Firesafe, compliments this amazing technology with an expressive syntax to get the most out of its security model. (Firesafe is not endorsed by Firebase)
In multiplayer apps/games, people cheat. It’s a loss of direct sales, AND the free loaders also diminish the fun for everyone else. Multiplayer games are webscale, which means the old solutions to data integrity and transactions don’t work (e.g. SQL).
Firebase solved one problem of the cost of providing low latency persistent data storage to mobile and desktop games. It’s the first scalable NoSQL hosted solution that didn’t suck. It also provided an unorthodox security and transactions abstraction. Turns out that abstraction has enough purchase to do some really cool things not possible in many NoSQL environments. Unfortunately, properly configuring the security layer is extremely verbose and error prone. Firesafe makes it easy.
I have been irritated that many recent introductions to machine learning/neural networks/whatever that fail to emphasise the most import trick in machine learning. Many internet resources don’t mention it, and even good textbooks often don’t drill it in to the reader the absolute criticality to success the trick is. In a machine learning context, we wish a learning system to generalise. That is, make good predictions on data it has never encounter before, based on what it learnt during from a training set. There is no easy formula to predict the ability of a learning system to generalise, but you can estimate it using held out data. That held out data is labelled but it is not used in training. It is called the validation set.
The reason why we keep certain information private, when and to whom we disclose it, is a private choice. The Edinburgh Hacklab hosts on Friday (2013-10-25) the first tin foil hat party to investigate together how you can hack your daily routine to limit access to this information (Yes, it is a cryptoparty.in with a[…]
Our robot arm is learning to control itself from optical feedback alone! We connected the Lagadic’s visual servoing platform (ViSP), OpenCVs robust homography estimator and University of Edinburgh’s Locally Weighted Projection Regression (LWPR) adaptive control to create a software stack for a cheap USB robot arm toy and a webcam. The hardware cost about £48, and it took us 6 weekends to connect up cutting edge open source research software. Yes! All this software is free! It’s been paid for already. I hope this article will guide people towards making use of these valuable public domain resources. We used an adaptive control scheme so at no point was robotic geometry measured, and instead the software *learnt* how to move the robot from experience alone.
To recap (here and here), our goal is to build high precision robot systems using cheap components, and now we have actually tried a control installation. The existing approach to precision machinery is to spend lots of money on precision steel components and more or less control the machine open loop (without feedback). CNCs are a good example of this where the lead screws are *really* expensive. This approach made sense when we did not have cheap methods of precision feedback, but now we have cheap cameras and cheap computation (thanks smart phones), an alternative method for obtaining precision could be to just to use dodgy mechanics and closed loop control (feedback). Visual feedback is particularly attractive because: its easy to install; it is contactless (so does not affect the motion of the thing you want to control) and it doesn’t wear. With vision you can just slap markers on a mechanical part and off you go (with the appropriate software).
Janek “hand soldered BGAs” Mann has just published his extensive PCB prototyping buying experience. [Addition by Al] And Hacklab member Peter Jackson (@greenhac, not the Lord of the Rings guy) is documenting his experiences with laying out his first board and ordering prototypes from Seeed Studio on his blog.
The problem: you need to share files with people on an ad hoc basis for a project.
One choice is sharing files with Dropbox. On the plus side of Dropbox is it’s ease of use, however, there is a drawback that if you work on the same files you get “My conflicted copy of x” spawning everywhere and making a mess. If you are coding you will trip over other author’ changes.
To work around that problem you need version control. But that can come with baggage. You’ll need a server to run a git/svn/cvs (infrastructure), or a project on GitHub/sourceforge/google code (open source requirement, or pro account). Some projects don’t have these resources or freedoms, so they do without version control, but there is another way…
You can run the best version control software from inside a Dropbox folder! (or Google Drive) Running git from a Dropbox folder does not require spending money, having a server or open sourcing files. Because git compresses its repositories, it also reduces your Dropbox quota usage. Awesome! And it is easy to install. In this article I will show you how to set everything up properly, and give you a quick user guide to git incase you (or your collaborators) have not used it before. By the end you should be able to setup and use git like a true intermediate.
The first UK hacker camp in many years was taking place in Milton Keynes, hackers, makers and other interested people were going to be there from across the UK and beyond. It was an opportunity that couldn’t be missed. After a early start the “hackbus” (a hired 9 seat mini-bus) was making good progress and we arrived by mid-afternoon in time to put up our tents and connect to the supper-fast Internet connection before the first talk started….
There were several other hack spaces, including NottingHack that had brought a gazebo village complete with laser cutter. Our “village” was slightly more modest a few straw bales with cooking equipment spread out nearby. A borrowed sail provided the only means of identification and protection from rain, that fortunately didn’t occur in any significant quantity.
Why on earth would you like to spend an evening on a laptop after you most likely have been sitting on an computer for the last 8h? Because its cool, right?! Code & Coffee is a software night that I host at the Edinburgh Hacklab. It is my pet project, to give me an hour[…]