CloudFlare is a popular, DNS-level proxy service that has layered on tons of useful features over the years like asset optimization and denial of service attack mitigation. Probably the most prominent service they provide though is caching. This caching functionality is primarily geared towards webpage content. Out of the box, CloudFlare’s caching settings work great and it intelligently decides what kind of files to cache (images, css, javascript) and what not to cache (html or other files that could contain dynamic content). You can tune CloudFlare’s settings to fit your specific needs and do a lot to lighten the load on your server. I started to think about all the interesting things I could do with a distributed caching layer that sits in front of my servers. I was designing the back end of ultralink.me at the time and thought: “Gee, CloudFlare might actually make a pretty decent read cache!“.
Now I have to start this article with some caveats. Using CloudFlare in this manner will not solve all your problems or even be appropriate in many cases. But if you do have a certain kind of workload and can expose the interface to your database in a specific way, it can really do a lot to absorb your database read traffic. (more…)
Some of you might have noticed that I haven’t written any blog posts here in a long while. That’s because I have been head down, cranking away on my latest exciting project. It is a very bold, new concept unlike anything that has been seen before. I call it the ‘Ultralink’.
To explain what an ultralink is, let’s first examine it’s ancestor, the hyperlink. The hyperlink is the most basic grammar of the internet. It’s assumptions and usage quickly permeate anyone who has used the web for more than five minutes. Even grandma knows what a hyperlink is and how to use it. I want to take that foundation and evolve it forward into something even more useful, more valuable and more user friendly. I want to re-write the most basic grammar of the internet.
The easiest way to understand what an ultralink is, is to go to https://ultralink.me and watch the introduction video there on the front page. Then install one of the browser extensions and take them for a test drive on any page on the internet.
We have finally decided to declare public beta and are now putting ourselves out there for all the world to use. We want feedback so that we can continually make our products more awesome. I would ask that you please take a look at the resources we have for ultralink above (and share/like/retweet/etc.), try them out for yourself and send me feedback on what you thought was awesome and what can be improved.
Hyperlinks still have their place, but ultralinks can do much of what they do better and some stuff they just can’t do at all. It’s the hyperlink… 2.0.
Here’s demo of the new 60beat GamePad with my friend Mike‘s game Caster HD. I added support to both Caster/Caster HD and the update has been submitted to the App Store for approval. It shouldn’t be too long before the update actually hits the App Store. (UPDATE: Both updates are now live on the App Store!)
In the video I demo the controls starting with the cursor. The Mac/Win/Linux version of Caster has game pad support for the in-game cursor and so it was easiest to just hook into that. You don’t need to worry about switching between touch and game pad controls. Caster has no on-screen control overlays and both control styles will work concurrently so you just plug in and go! No setting switch required.
After getting into the game I demonstrate the settings for the camera movement which is controlled by the right analog stick. The start button will pause the game and give you access to the options menu. There you can tweak the camera sensitivity and invert the axis if you want.
A lot of the other controls are doubled up so you can use whichever you prefer. The left analog stick or the directional pad control walking movement. Button 3 or R2 will jump. Button 4 or the R1 will fire. Buttons 1, 2 and L2 will rotate through the different weapons. By holding down L1 you initiate a dash when moving.
(While I’ve got you here, be sure to check out my new 3D physics shooter Invader Zurp if you haven’t already. It is a ton of fun and there is nothing else like in on the App Store. 🙂 )
Last September I wrote a blog post introducing Invader Zurp which revealed a little of the back story on how I came upon this new game idea after it’s first 2 months in development. Fast forward to 3 months later and Invader Zurp had just hit the App Store! I thought it would be useful to sit down and review the last 5 months of development, kind of plan out where I want to go from here and go over the events and insights that I thought were most influential during development.
The Story So Far…
So to recap the original blog post a bit, it was the middle of the summer (2011) and I had been working my brains out on Cannonade for the previous 6 months. I was a little discouraged at that point because progress wasn’t coming quite as quickly as I had hoped. Reception from my testers (just friends and family at that point) hadn’t been as positive as I had wanted either. I still had a very clear vision of what I wanted Cannonade to be and still believed that there is a ton of untapped potential for multiplayer-only games on iOS. But there was only so much I that could do as a one-man team and testing a multiplayer game can be quite time consuming. I took the family on vacation in early July and was able to step away from things for a while. It was then that I got an idea for a single player experience that distilled the core gameplay mechanic of Cannonade down to it’s essence. Thus Invader Zurp was born. Within two weeks I had modularized the Cannonade game engine, re-written the graphics sub-system in OpenGL ES 2.0 and had a working prototype. And it was fun! I found myself on very long “testing” sessions playing even after I had verified my fixes. I seeded the first alpha version in early September and wrote the introductory blog post. Then began the journey of finishing the game and kicking the darn thing out the door. (more…)
Aright it’s here! Invader Zurp, the project I have worked so hard on for the last 5 months is now for sale on the App Store! I want to thank all my wonderful testers for all their time they put into playing it and even more for the thoughtful and productive feedback that they so lavishly furnished on me. I couldn’t have done it without you!
In developing Cannonade and Invader Zurp I’ve invested a fair amount of time becoming familiar with the Bullet Physics Library and trying to milk every bit of performance I can out of it. Realistic physics simulation plays a crucial part in both games, and is also the performance bottleneck in the majority of gameplay scenarios for both. When trying to optimize for performance, I generally find myself using two kinds of approaches. One is a higher level algorithmic approach that tries to find ways to create less work or avoid work in order to keep things going fast. Once I’ve nailed down the minimum set of work that absolutely must be done, then comes the work of getting down and dirty to speed up the routines that actually do that work. When I first approached the problem of speeding up Bullet, I simply treated it as a black box (work that I wouldn’t be able to avoid) and explored what kinds of compiler configurations I could leverage to create the fastest possible execution of the physics simulation work. Later, after I had nailed down the gameplay mechanic for Invader Zurp, I was able to start specifically attacking the set of physics simulation work needed for the game, and whittled it down to a much smaller amount using some simplifications, accuracy compromises and psychology.
So I have these thoughts…a lot. No not that kind! 😉 I get these fun ideas for neat projects or crazy inventions as I am driving in the car, singing in the shower, lying in bed or even in the midst of coding. Really creative ideas that may or may not be realistically viable but worthy of entertaining nonetheless. I get really excited and start working it over in my mind. It feels like inspiration. Then something happens… Life resumes and I need to deal with the actual task at hand. No worry, it was such a compelling idea that I will surely remember it later when I have cycles to devote to it. And then I never think about it again. Or even worse, the next day rolls around and I all of the sudden remember that I did think of a cool idea the day before, but I can’t quite bring the memory into focus. Does any part of this sound familiar to you?
Write It Down
“No more!” I declared. Nothing gets remembered unless it is written down. Hmm, idea notebook? TextEdit file on the computer? I did the text file thing for a while but I kept forgetting that it was there or didn’t have access to it at the time. No worries… Evolution of the computer to the rescue! Transferred things to Notes.app on the iPhone. Not good. Too jumbled, un-organized, too much information presented in-general. I knew of the million and a half “getting things done”, task management, mind-mapping and brain organization apps/ecosystems out there. But I found most were too general for what I wanted and too heavy. Well, if you want something done…
Above is some footage from the current Invader Zurp alpha (apologies for the bad exposure). As you can see, things have come quite a ways since I released the first video! There are a lot more visual effects, 5 music tracks from Monte ‘Trance’ Emerson, a new gameplay mechanic, an in-game currency system and tons of other little advancements. I must say that I feel like things are progressing quite nicely! I still have a ways to go though and so I am going to continue cranking away with my head down until it is finished.
What are your thoughts on how development is going? Let me know in the comments. Also, a huge thank you to all of my testers who have given me invaluable feedback on all the builds thus far.
The Startup Grind is expanding! You may or may not have heard that we have recently opened up a Los Angeles chapter of the Startup Grind and to coincide with that we have added multiple chapter support to the Startup Grind.app! Now if you are a member of the Startup Grind LA your upcoming and past events should be visible when you log into the Startup Grind.app with your Meetup account. If you are a member of multiple chapters then you will be presented with a top level pane allowing you to switch between them at will.
As we open up more chapters of the Startup Grind you will be able to access all the information and interactive elements for the events for every new meetup that we get going. More awesome features are in the works so stay tuned!
Much like Amit Singh and his Hanoimania, I regularly attempt to port my friend’s game Caster to as many platforms as I can. Because of some good language and API choices upfront (C++, OpenGL 1.X, SDL, etc…) the Caster codebase is very portable. That portability combined with its relatively humble (for these days) performance needs has lent the (currently still unified) codebase to easy porting. This multi-platform journey began many years ago before Caster was even released. Caster was still in early development when Mike approached me with the idea of maintaining a concurrent Mac build. At that time Macs had not yet moved over to x86 processors and so the most difficult part of the process was reverse engineering Valve’s Half-Life model format (which Caster uses for animated character models). The Half-Life model format was a binary, in-memory format utilizing offsets which meant that while loading it was quick and simple (just read it into memory, no processing whatsoever) it was unfortunately dependent on little-endian byte order to work. Other than that and a couple of other issues, the Mac port was really straightforward. So before release, Caster was solidly supported on both the Windows and Mac platforms. After release another guy helped out with the Linux port of Caster and so at that point we now had the major desktop operating systems covered. Over the years we added slightly different versions for the desktop platforms to adapt them to specific distribution avenues like Steam and the Mac App Store. The first port that required major reworking was iOS. That adventure was chronicled in my post Caster for iPhone: A Postmortem. Mike and I had the opportunity to give a presentation about what we learned at GDC Austin ’09. Later on as the Android and webOS mobile platforms took shape, I started to look into porting Caster to those platforms as well.
Spencer Nielsen 
