As a student as the University of Texas, I am very fortunate to be able to work closely with Bob Metcalfe, co-inventor of Ethernet, and founder of 3Com. Ethernet celebrates its 40th anniversary this year with a history of obviously great success. Last week Metcalfe was speaking on why Ethernet ‘won’, and he attributes that to the fact that it was an open standard. As he was speaking, I started realizing there are a lot of similarities between the history of both Ethernet and HTML5.

First, a bit of a background on Ethernet.

Ethernet vs. Token Ring

The main competitor to Ethernet in 80′s was IBM’s Token ring. Like Ethernet, Token Ring was a local area network technology.

Standards

IBM’s Token Ring was also a standard, but a bad one because IBM was not committed to interoperability (where many different systems can work together). The fact that Token Ring was developed by a PC manufacturer, subsequent manufacturers were less likely to choose a standard controlled by a competitor who wasn’t focused on making it work in as many environments as possible.

Similar to IBM and Token Ring, Apple controls Objective-C thus Android and others will clearly never support it, and each operating system has their fairly controlling, closed-off App Store. These factors do not bode well for ‘native’ apps. The only current ubiquity can be found in HTML5.

Interoperability led to Ethernet’s overall success, and it makes sense that HTML5′s open standard equivalent will do the same.

Performance Improvements

The Ethernet-HTML5 analogy, though Metcalfe is probably a lot less likely to acknowledge, holds true on the performance end as well – at least at first. Without question native code performs much better than Javascript, just as Token Ring was technically more ideal than Ethernet in many areas. Ethernet however improved more rapidly by offering more and more bandwidth, while keeping it’s price much lower than Token Ring. In the mid-80s Ethernet adopted twisted pair ether wiring (like Token Ring) which made Ethernet cheaper, faster, and available in more places.

Javascript engines, especially on mobile, are improving at an incredible rate to the point that they will bring near-native performance. In fact, with LinkedIn’s move away from HTML5, speed wasn’t the reason, “It’s not performance issues, like speed or rendering”, but rather memory issues (Source).

With the performance aspect no longer as much of an issue, the other benefits (lower cost of not having to fully port apps) will contribute to HTML5′s success.

History Repeating Itself

Ethernet and HTML5 have a surprising amount of similarities, and if history repeats itself as it often does, HTML5 will succeed over native apps.

The fact of the matter is Microsoft, Apple, Google, Mozilla, Intel, and just about any major tech company strongly supports the idea of HTML5, and that idea is rapidly becoming reality in today’s native-app driven mobile world.

Clay.io is my baby, it’s a company I started back in January with Joe Vennix. Both of us have solid backgrounds considering our age (21) – our claims to fame: Joe developed Pizza Hut’s first iOS app, I was one of 4 at IntenseDebate when we were acquired by Automattic. What we’ve been building is a platform for HTML5 games (with Steam as our inspiration). It’s part cross-platform marketplace, part API for high scores, achievements, data storage, payments, etc.

Despite the fact that we don’t have funding, the main reason I thought we would be able to land a post is the TechCrunch-themed HTML5 game I developed. In my email to their tips line (as well as a few emails later to individual writers) I mentioned the game to get their attention, and also let them know they would be able to embed it directly into their article if they were to write one. Here it is embedded below – the game also works on mobile devices (link).

It wasn’t just the game… I thought we had a good story. There are three of us working on the company right now and we’re all University of Texas students. We’re in a startup accelerator class called 1 Semester Startup (yeah, we get credit to work on our company), have great office space provided by the University, and some fantastic mentors. Like I mentioned before, Joe and I also have fairly interesting backgrounds for our age – though, I suppose now, it’s not uncommon to see successful companies run by sub-21-year-olds.

If that wasn’t enough, we actually have a legitimate company in an exciting space with a proven revenue model (which should be the most important aspect, but for a TechCrunch article, I figured the fluff should be first). I know it’s clear to all of our current members and developers this isn’t just a hobby for us, and the site/API should reflect that as well. We started in January of this year, and have been able to keep things chugging along while the other student startups around us, and startups in general, have flickered on and off.

However, all of this wasn’t enough to get noticed, and that’s fine. I was completely wrong to think TechCrunch would be pivotal for Clay.io’s success. Sure, it’s a nice boost in traffic and new users for a day or two, and a bit of extra credibility, but by no means is it worth the effort I put into it. It’s a learning experience for me, and hopefully one for others reading this post.

If you’ve secured a decent round of funding for your hype-filled startup, then sure, it’s easy enough to get on TechCrunch… same goes if you have connections with the writers. Otherwise, tough luck! It’s not the end of the world. Continue to build your company and prove them wrong.

I thought it would be helpful if I posted some statistics of the signups we’re getting per login/signup method.

Here is how the signups break down for our 1,058 users at the time I collected data:

​

We didn’t implement Google Federated Login until we were already at 200 users. Below are the stats for our most recent 835 users.

​

As percentages: 24.7% Facebook, 10.5% Twitter, 22.3% Google and 42.5% Email.

The main thing I would say to take from this is: using Google as a third option for login is certainly worthwhile. If you are hoping to get the most people signing up, I would use all 3 (+email). If you need to cut one out, give the ax to Twitter. Of course, there is still a lot of value in Twitter (for example if you want to look at their followers and find people within your site to recommend).

Implementing Google as a login option was relatively painless.

The most popular option is still email, and there are sites that don’t allow that as an option… that’s not very smart.

I will mention that a lot of our audience has been from Hacker News, Reddit, and other early adopters. For a more broad population, it’s hard to say how it would be different. Even fewer Twitter users I’d imagine, and perhaps a lower percentage of Google as well.

Some extra stats:

A graph of activity (basically how much a given user plays the games on Clay.io) per signup method. With such a small sample size, a few really active users can throw this off, so don’t read to much into it:

Users on Clay.io can ‘upgrade’ their account to developer status. It basically just lets us know they’re interested in our API and the development side of things. Here’s the same analysis applied to all 143 developer accounts:

​

It’s a small sample size, but it’s clear the developer types prefer to use email much more than the average user. The percentages are: 12.6% Facebook (half as frequent as the typical user), 9.1% Twitter, 17.5% Google and 60.1% email.

For reference, this is what our signup form looks like. We don’t put too much emphasis on the ‘social’ options, but they are there. In fact, more of our new users come from those 3 options than through email (and we aren’t asking for a lot of information with the email option).

It would be interesting to see how these statistics would look on a much larger site… Any takers on HN?

Nick vs Bus

I’m a student at the University of Texas, and two weeks ago, another UT student was hit by a bus (video embedded below, he made it out without serious injuries). As soon as I saw the video start going viral, I decided I would make a game for it. 24 hours later, the game was complete and went viral itself. In just a few days, the game had 25,000+ unique visitors, 1,500+ likes, and articles on sites like Kotaku, News.com.au, and the Statesman. Here’s the link to the game: Nick vs Bus

The game makes use of <canvas>, SVG (Scalable Vector Graphics – which were remarkably easy to implement), and Clay.io. It’s written in CoffeeScript, here’s the source code (keep in mind it was made in <24 hours). Thanks to HTML5, it’ll run from your phone’s browser as well (assuming have a semi-modern smartphone).

Nick vs. Bus wouldn’t have received anywhere near as much response if I had released it two weeks after the incident, and HTML5 was the perfect language to crank it out in such little time. (Keep in mind when I say HTML5, what I really mean is <canvas> and JavaScript)

The graphics aren’t great, but that’s not my background (if you’re curious, I used Inkscape)

Word Wars

The second game that backs up my claim that “HTML5 is the best platform for rapid game development” is a game called Word Wars.

Word Wars was initially developed by a couple other students and friends during a 24 hour hackaton at UT. It was called Worldle at first, and had some good reception from Hacker News. One of the developers didn’t even know JavaScript going into the thing (pretty impressive).

What’s more impressive about Word Wars in relation to Nick vs Bus is it has a backend + multiplayer (nowjs), all done in less than 24 hours. This one was done in pure JavaScript rather than CoffeeScript like the first — it’s really just a matter of preference, CoffeeScript isn’t going to drastically reduce your development time.

Again, the game works from mobile devices as well

That’s two games developed in less than a day, both with a pretty good reception.

Bonus: Since it’s the development time is so little, I even made a game for TechCrunch in an attempt to get noticed for an article. That attempt wasn’t successful (a couple editors tweeted about it, but no article), but here is the game anyways.

Why HTML5?

The best candidate to compare HTML5 to for rapidly developing and deploying games like Nick vs Bus and Word Wars is Flash. Java, C++, Unity, iOS and the rest all typically have longer development cycles, not to mention they simply wouldn’t have spread as quickly since people are forced to download the game (or use the terrible Java applet). Sure, you can create a game fairly quick in those languages if you’re very familiar with them, but I’d argue that, given an equal knowledge of all languages, HTML5 would win out on rapid game development. If you’re hoping to create the next Call of Duty (we definitely need more games like those /sarcasm), go with C++… WebGL is great but we’re probably still a couple years away from seeing console-quality games using it.

Why HTML5 over Flash?

Mobile Support

This is the big one in my eyes. Right now the main benefit of HTML5 is it’s “cross-platformness” by nature. 3,000 of the 25,000 visitors to Nick vs. Bus came from mobile devices. Most of those came from people clicking the link from Facebook’s app.

Sure, you can get your Flash game on the App Store (when I say App Store, I mean iOS, Android and WP7), but that takes time, and any update you make takes time as well… With HTML5, you can get your app on the App Store if you’d like, plus your game can be played straight from the browser.

For the Nick vs. Bus game, mobile support would just now be ready… two weeks later… if I had used Flash.

In addition to mobile support, HTML5 paves the way for games to be playable on smart TVs (in the hopefully near future), Windows 8 apps, and perhaps even consoles as Microsoft is very supportive of the new markup.

No compiling

Having to wait for a compiler sucks. With JavaScript you don’t have to. (Yeah, I use CoffeeScript,  a compiled language; however, it’s very quick to compile and certainly not necessary). That also leaves open possibilities like this.

Easy Testing

As per the nature of the web, to test a game on different platforms, you just point your browser at wherever you chose to upload your game. Testing for mobile is the same, and since most browsers and mobile browsers have their own JavaScript console, it’s fairly easy to find the issue and debug quickly.

Same language for a backend

Should your game need a backend (if for example, you want a multiplayer component), you’re able to use the same language: JavaScript (node.js), which just makes sense. Why write a game in two different languages when you don’t have to? For one of our games, Slime Volley we run a separate instance of each game on the server. In our implementation, we simply share code between the client and server, so there’s no need to rewrite the mechanics in another language. The game’s source code can be found here.

It’s not a plugin

Okay, okay… pretty much everyone has Flash, but it’s hard to argue against a standard being better than a plugin. Apple has already taken a stance against Flash. Sure, none of the major players in browsers are going to publicly take a stance against Flash, but I can see HTML5 being favored over something that is completely beyond their control.

It’s not controlled by a single corporation

Adobe does fine work with their products, but in this case Google, Mozilla and Microsoft all competing against each other will be able to continue making something better. Chrome was the first to really make HTML5 games viable with the V8 engine, and now Firefox and even IE are doing their part to push the limits.

Great stuff is being pushed out like the Gamepad API and Notifications API.

More active development

Because it is new, more and more developers are building tools for HTML5. New doesn’t necessarily mean better… in fact, it means it’s likely less stable. What it does mean however is there is likely much more active development going on and much less legacy code / excess bulk.

HTML5 games get more attention

Honestly, HTML5 games get more attention just for being HTML5 – deserved or not. It’s still a buzz-word, and early adopters seem more likely to have a look, opposed to flash games which they’ve played hundreds, if not thousands, in the past 10+ years.

HTML5 Weak Spots

The two biggest criticisms of HTML5 are audio and security. Audio still needs work, I’m not going to beat around the bush on that. It shouldn’t be long though…

As for security, I just wrote an article for DZone about this. It’s not published yet, but you can have a look at the Google Doc for it here. Basically, you can make your game secure, you just need a backend that can be done fairly easily with node.js.

Finishing Words

I’ve written a three part series on HTML5 game development tips — things I’ve picked up on along the way. Part 1 is about style & performance tips, part 2 covers input methods (keyboard, mouse, touch, accelerometer, etc), and part 3 (link to Google Doc since it’s scheduled to be published on Monday) talks about security tips.

I’m betting on HTML5 which is why I’m building what’s essentially “Steam for HTML5″. It’s called Clay.io. You can have a look at more HTML5 games in the Clay.io store. For developers, have a look at the HTML5 Game Development Tools we offer.

I’m a big fan of Steam, a platform for PC (and Mac/Linux) games – it’s something that really ties together the entire industry and makes it easy to find great games. My vision is to create something along those lines for HTML5 and WebGL games.

Why HTML5 and WebGL? Because they’re awesome. No, really.

HTML5 games are completely cross-platform, meaning they’ll work in a browser, phone or tablet. As an example, you can check out the first game Joe and I developed: Slime Volley. Slime Volley is a port of a popular game from when I was in high school called Slime Volleyball. We added some cool stuff to it like networked multiplayer – since it’s cross platform, that means you can play others who are on desktops from your phone.

Here are a couple other neat HTML5 games: Onslaught! Arena, Angry Birds, and Cut the Rope.

WebGL allows even more advanced games to be created, using the HTML5 <canvas> element for 3d graphics. To get a sense for what can be done with this, have a look at this post, this one, or check out this game.

So enough about that, onto more about clay.io. We do a couple things:

The first is we offer a set of tools for developers to easily take care of some of the tedious things involved in game development (that normally get left out of the end result). Those include payment processing, achievements, leaderboards, screenshots, ratings, multiplayer rooms and a few more. If you’re interested in any of that, you can check out our API documentation.

In addition to the developer tools, clay is a central location for everything HTML5 & WebGL, so you’ll be able to find some great games in our store, and create an account that will be associated with all the games you play, achievements you earn, leaderboards you’re on, etc. Sign up and have a look yourself!

Here’s a quick demo video:

Joe Vennix and I have been working on clay since the start of 2012, devoting a lot of time and effort into it. I hope you like it, and let me know of any feedback you have!

I started off writing this post as a set of tips, but realized I’m not exactly in a position to give advice. I’m still largely unproven. Regardless, here is the approach I am taking each and every day.

Using the resources I’m given (something called the INTERNET!)
I’m always trying to extend my knowledge in all areas and I do that mostly through four sites you’ve probably heard of: Quora, Stackoverflow, Twitter and Google (no, I’m not going to link to that…)

Quora is great for following topics that interest you, seeing what others are asking, and more importantly what smart, capable people are saying in response. I check Quora a few times a day and read any thread I feel might teach me a thing or two. For an idea of what I follow, check out my profile.

Stackoverflow is much like Quora in this aspect (questions and answers), but with more of a focus on programming. There are good answers and there are not-so-great answers, with the format it’s quick and painless to see what is generally accepted as a ‘good’ answer. It’s also beneficial to look at the top questions and read the responses for the languages/paradigms that are relevant to you. For example: PHP and JavaScript

Twitter is my new Google Reader. It’s something much less verbose so I can easily weed out what I don’t want to read, and save valuable time. If someone I look up to retweets something, I’ll check it out.

Most programmers will tell you they just google everything – that’s a good description for myself as well. I became a competent programmer by first learning how to be a good googler. What I find myself doing more and more is searching “<problem I’m having> stackoverflow” since most of the time it seems someone else has had that problem before.

Programming involves constantly learning new APIs, languages, and techniques and that’s really hard to do alone without google – even with a book I’d imagine it would be very time consuming. I’m finding entrepreneurship is the same way, having to deal with stuff like filing as a company, partnership agreements, stock options and vesting, ideologies for product development (like the lean startup method and MVP). Quora, Google and Stack Overflow make all of this easy.

There’s also Reddit (the relevant, productive /r) and Hacker News - though sometimes reading too much can get in the way of productivity.

Doing what it takes to stay motivated
I’ve been able to accomplish this by choosing something I’m really passionate about – video games.

What I’ve been working on the past few days – payment processing – isn’t the most exciting thing in the world. In fact, I’m sure most programmers despise it. But what’s keeping me going is the vision I have for this business.

I’ve had sites in the past where I really enjoyed the process of building and creating a snazzy product, but that only goes so far if you’re not truly passionate about the problem your site solves.

A couple other factors that have helped immensely are having an office to work in, working on various different aspects of the business, and having someone on the ride with me.

Networking
In the last 4+ years I’ve been in a few different ‘ecosystems’ and gone through ups and downs in terms of how much I network. The most productive periods for me are obviously the ones I did a better job at reaching out and meeting others.

Now that I’m at the University of Texas – after a couple months – I was able to achieve this by getting involved in some startup and hacking events. I can already see the rewards of doing this with clay.io being formed, and having an awesome environment to work in.

Seeking advice
There is a lot I don’t know. Because of that, I ask other people with experience. Luckily, it seems like most people are willing to help (which relates to networking to get connected with these people). I am very grateful for everyone who helps me out and I hope one day I can return the favor.

So I guess the two main things I’m doing are networking and always trying to learn more to put myself in a better position to succeed.

I’m not strictly focusing on programming. I don’t want to be just a programmer — it may but what I’m best at right now, but I’m actively trying to improve all those other areas that are necessary. It’s good to have variety.

I will give one tip… be sure to apply what you learn. There are people out there who are all talk and no game. If reading Quora and various blogs gets in the way of implementing things, it’s time to cut back.

P.S. This may be a bit TMI, but for me, in the bath on my phone is a great time to learn (mostly with the Quora app or google). In fact, I’m writing this post in the bathtub right now… Another time I find myself doing this is on my bus rides to and from downtown — anywhere, anytime really.

One of those resources is a thing called Longhorn Startup Camp – office space for student startups.  It’s something new this semester, so when I heard about it, I made sure clay.io would have some space. The entire top floor of UT’s administrative building is dedicated to startups. It’s great being surrounded by other smart, driven students who want to make an impact, and I think this atmosphere will be a huge help.

Here’s a look at our office before and after we got furniture. Joe’s side looks a bit more classy than mine, but hey, at least mine was easier to move in…We might end up getting a couch in there as well. The building was renovated in 2009, so it feels brand new.

Here’s an updated picture with even more furniture…

As someone who lives pretty far off campus, it’s certainly nice having a anchor like this downtown, I’ll be spending many days and nights working there. Big thanks to Kyle Cox and Bob Metcalfe for getting us hooked up!

This was a  good opportunity to make a game for my new project, which now has a name: clay.io. This game had to be simple because of the time constraint, so I set upon an idea similar to a mini-game from Mario Party. The premise is, you, and 1-3 others are on a platform, and have to duke it out until one person comes out on top. Of course, I added my own flare to the game as well.

The game uses WebGL, to render 3d graphics right from the browser without plugins, and a combination of node.js and socket.io for the multiplayer networking. To help make WebGL a bit less painful, I used GLGE. For the 3d-modeling (if you can even call it that…) I used sketchup. That’s definitely the weak point of this game: the art. All of this was done in less than 48 hours by someone who doesn’t consider himself a game developer. I’m surprised more people aren’t hopping on board with WebGL yet.

Here’s a quick demo video – I’m happy with the results so far:

You’ll see I just have two Chrome windows open, showing the multiplayer support. It’s kind of lame watching me fiddle with it by myself, it’s much better when actually playing Packets between the server and client are being emitted 10 times per second, much less than the typical 20-30 per second – interpolation takes care of everything in between.  The player can be controlled with either the mouse or keyboard, and the goal of the game is to survive the longest.

There are 3 abilities to help you survive. One is ‘stomp’, where if you jump in the air and hit the “C” key above you opponent, it will smash them and they won’t be able to move for 1 second. The second is “Push back” – which is something you can use to prevent an opposing player from getting too close to you, or to try and push them off the edge. The final ability is just “Attack” – if you get behind another player and press “R”, it will damage them. 5 hits and they die.

As you’ll also see, parts of the platform are constantly rising and falling, with a short warning shake beforehand. This adds another dynamic as you have to make sure you don’t fall off.

I was able to get the game to a playable state, with all the features I’d initially written down. However, it’s still not at the point where I want to release it. There’s a bit more polishing to do before that – but once it’s ready I’ll have it released within clay.io. Right now it’s just 2 players max, but I programmed it with more in mind so it’ll likely be 3 or 4 players in 1 game at a time (it’s more interesting that way).

That’s all for now – I’m running on 90 minutes of sleep in the past 31 hours so it’s time to relax, watch the Pro Bowl and get a good night’s sleep.

As a programmer, this mostly involves switching between languages, languages that differ quite a bit. I’ll go anywhere from a few hours to a few weeks working on one language, say, PHP, then if I get tired of that, I have plenty of options. With the current project I’m working on, I’ve been switching from PHP to node.js to frontend javascript (coffeescript to be more specific) to CSS. All are very different in how they are programmed, making each new switch something that helps prevent complete burnout for me. One day I can work on some hard-core backend, getting all the backbone structure in place, and the next I can get more arsty and play around with some HTML and CSS. It’s good to have options. Of course, some days you’re going to be forced to work with one specific area of programming, but having rotated through them throughout the process, you’ll likely not be as tired of it.

If you’re someone who specializes in one programming language and have issues with burnout, I suggest trying to pickup something new. That doesn’t mean learn Java if you’re a C++ programmer – both are backend – try something on the opposite end of the spectrum like some HTML and CSS. If you’re strictly a frontend developer, try familiarizing yourself with Bash-Scripting to make tools that will speed up your development process.

It’s not just varying programming languages that helps; some days I’ll just sit back and read/learn about technical stuff (whether it be programming languages, unix, databases, etc) which I still find productive. Others I will focus more on the entrepreneurial side of things and work on planning out the company’s future, taking in advice, or reaching out to others. Lately I’ve spent a good chunk of time reading questions and answers from successful entrepreneurs on Quora. One more option of productivity that I’ve been using lately, is writing my thoughts on this blog, which I enjoy.

I know many of my readers aren’t programmers, but I’d argue this applies to everything in life that one can be burnt out on. A little bit of variance and changing things up can go a long way. For example, my girlfriend and I were having salmon and shrimp 4 or 5 days a week when we started the Paleo diet. The result of this was after a few weeks we started to despise fish and subsequently haven’t had it in over a month. Had we just been eaten it once or twice a week, I’m sure that would still be a meal in our repertoire. Routines can be good, but with certain things routines need to be switched up every so often to stay fresh and prevent burnout.

There are two modes: content-box and border-box. content-box is default, and will calculate the true width for an element as width+padding+border. So if you have a child <div> with 100% width and 10px of padding, it will extend outside the parent <div>. Here’s an example of content-box:

The parent<div> has a black background and the child has a red background with 50% opacity (rgba is another awesome new tool to use with css)

With border-box, the padding and border are included in the width of the element. So an element with width: 300px; and padding: 10px; will still have a width of 300px, rather than 320px. Here’s the example from above using border-box:

This allows for more fluid specification of widths in a lot of instances. Say you need a textarea with width: 100%, you can add padding to it and not have to worry about it extending to be wider than what you really want. Before, I always had to set a fixed width, which obviously isn’t ideal when developing a site you want to work in a variety of resolutions and devices (mobile).

The box-sizing property doesn’t work in IE 7, but you can get around that with this.

Here’s how you implement it:

box-sizing: border-box;
/* Firefox */
-moz-box-sizing: border-box;
/* Webkit */
-webkit-box-sizing: border-box;
/* IE */
-ms-box-sizing: border-box;
/* Opera */
-o-box-sizing: border-box;

Hope this helps you out like it has helped me!