On the state of cross platform development

I’ve been a bit lately and while I can’t complain about anything in particular, my time dedicated to example coding for the blog hasn’t been exactly stellar.I do however try to keep a schedule of a new post every now and then and since my activities have brought me to cross-platform development research, I’d like to share a few thoughts about it.

The first thing that everyone thinks about nowadays when you say cross platform is HTML5 and it’s true that there’s no other alternative that can come close to the plethora of platforms that you can reach with that technology simply because getting a consumer electronic device out nowadays without including a browser in it is somewhat of a niche market. It’s also true that you can get some pretty nifty stuff out of it , except the obvious canvas, CSS transitions and shaders come to mind and the army of developers working round the clock to make browsers lightning fast also helps you as a developer since they will basically do all the optimization work.

All of this is of course amazing and to be honest most ideas an indie developer could create in a decent amount of time could probably give a decent experience, maybe with 1-2 optimizations that you can learn from the awesome guys at netflix, but this is something that most people already know and is well documented on other sites that have better graphics than mine, so I’d much rather talk about the next best thing.

Another alternative worth taking into account when trying to build a product that runs on almost everything is Qt. It’s probably not for the less experienced indies as the preferred language for development is C++ (and you will have to use C++ if you want your stuff to be cross platform) but on the other hand it’s still a UI toolkit that actually works and compiles with 1-2 clicks on everything that’s worth bringing into discussion. The good thing is that it has the cleanest API you can ask for and native capabilities are of course a plus (device discovery over LAN comes to mind), so there is still a gap left by HTML5 that Qt can fill, however the biggest drawback is that it’s not exactly backed by the same same amount of developers working on webkit, so the ports created for mobile devices are not exactly matching the same level of functionality you can get from the framework on desktops.

It’s slowly getting there though and it’s gotten to a point where it might be worth it to try and see if you as a company can make one Qt app and adapt it for all the platforms you intend to support (did I mention you can style controls with CSS?) since at this point making a mobile build is as easy as adding a new target to the project.

In other news I just made my tile editor run on tablets so I can make levels on my tablet and play them on my PC. The other way around is too mainstream.

What I’d do if I were facebook

I’d buy a phone company.

No really, think about it, they’re already the biggest socialization platform known to man, if they were to buy a telecom company they’d probably gain every teenager in their network, which basically means two things

  • You can pretty much ask anything you like from manufacturers.
  • You have a single unified billing account.

Now if the first thing isn’t that much of a deal since the facebook app is already ubiquitous in various marketplaces, the second would be huge. Many software companies are now struggling to convince people to give their billing details to streamline online payments, but if the company billing you for an online services is also the one sending you mail for monthly subscription fees, who’s to stop them from adding your online payment history to your monthly plan. You then talk to a few vendors, take a small fee for each transaction and you grow from there.

Sure beats adding vignetting and sepia filters to the photo gallery.

How to make a game: Choices

It’s been quite a few years since I first started making games both professionally and for myself, of course back then things went on a little bit slower since the best internet connection ran at a measly 36k and searching for answers to this question brought more noise than helpful information.

Well fast forward to present day and the situation hasn’t changed much, forums are still full of people asking how to make games and internet search engines still guide novices to NeHe’s old tutorials for opengl, so rather than repeating the same answer over and over again I’d much rather compile a list of tutorials here so that I can just give people a link.

The Idea

So the first thing you need to do is find an idea. Luckily that’s rarely a problem, if you got on this page you probably already have something in mind so you can head on over to the next section, but if you don’t or if you think you need something fresh to shift your goals and start focusing again, you can borrow one from here.

One thing to keep in mind here is that you will want to keep this as simple as possible, it’s easy to get lost in features like making flying rainbows drop random weapons for you shoot with, or making a gun that shoots tanks, you get the picture. That is an almost certain way of turning your game into a vaporware right from the beginning, but if you want to make the next mmorpg with historically accurate events that makes you travel from the roman empire to the modern era, go ahead and try, but don’t say I didn’t warn you.

For now I think it’s better to start small though so I’ll initially I’m going to show you how to make a space jumping game, the idea is simple enough, you are a space something jumping from planet to planet. The rules are as follows:

  • Each turn you can choose to jump anywhere.
  • As you jump fuel is consumed.
  • When you land somewhere, fuel is restored.
  • Each turn something comes from behind to eat you.
  • You die either if you run out of fuel or if the thing catches you and eats you.

The main advantage of this game concept is that it requires little to no careful asset crafting (no need to make levels) and it will carry us through a lot of concepts, starting from game logic to collision detection, physics and procedural generation.

The Tech

By now you should have a clear mental image of your game and you want to start making it. There’s a lot of ways to do that of course, the good thing here being that there’s a lot to choose from and the bad being well that there’s a lot to choose from.

The scope of this part is to try and help you narrow it down a bit so you don’t end up doing something you don’t really have a chance to finish what you started. First of all answer these questions:

  • Is there a langauge, or specific technology you know very well?
  • Is there a specific framework that you’re excited about ?

If any of the above is a yes, then skip this part and use that instead, the purpose here is to make a game, so if you already know say Python very well, might as well go ahead and do the game in that language instead of learning a whole new language with the purpose of making a game. Also if you do have to learn a language, at least try to first learn the language, then start making the game, it’ll help you along the way to know how to avoid doing stupid things, rather than doing them along the way and having to correct your mistakes.

If you still have no idea what you want to use, here’s a breakdown of available technologies to choose from in order of minimum amount of knowledge and patience required to start making colours appear on screen:

  • HTML5 – The easiest way I’ve tried to make a game, rookies require little knowledge to start something and advanced optimizations are possible, but generally not needed (for indie titles in any case). Use this when you want to learn and get results quickly. This is also what I’ll be using.
  • Game builders – I will include Construct, Game maker, Unity and UDK in this category, very versatile, well integrated with 3rd party software, upside is that creating a game is mostly done visually so no need to test the game 100000 times until you get the position of a tree right. They get a lower score in my list because they usually require money and/or registration processes, as well as installing and setting up your environment. Use these if you don’t really like to code or if your game requires you to place lots of assets in a precise position.
  • Pygame – This is just a set of python modules that let you draw stuff on screen, easy to use, but some things you will want to do with it require that you know how to install packages. Use this if you are a rookie but you want better access to the OS (file handling and networking) or you have an unexplainable distrust for the aforementioned technologies.
  • Flash – This probably the most common choice for indie devs, flash is easy to learn and most of the work you need to do has already been figured out by other people, so making a game with flash is more or less reduced to finding the right combination of tutorials when you’re a beginner. There is bound to be a problem with it sometime because Adobe announced they’ll drop support sometime in the future. Nevertheless it’s still tempting to use it because it’s easy to learn, it gives quick results and if you have something decent at the end, you can sell it for some pocket cash. However the way things are going right now, soon enough the same will be true for HTML5 and the market will most likely be somewhat bigger.
  • XNA – Nice because it tries very hard to hide the boilerplate details, but still gives you access to them if you need it (VBOs, shaders, render targets and states), will require visual studio or express. Use this if your game targets microsoft platforms, after the game is done it will be very easy to package into one installer. Normally I’d put it above pygame because it’s easier to debug and has support for more asset formats, but it’s very easy to find crap tutorials online for XNA.
  • Qt – People usually shun Qt for game development for reasons that sometimes escape me, the most frequent arguments are bad architecture and “it’s an UI framework”, truth is that it has a very tight integration with OpenGL and has components that let you load most useful formats. Downside is that you will need to learn some low level stuff about how the hardware works to get things done, but once you do, you can compile the same code into native apps for every platform that counts (except consoles unfortunately). Use this if you have at least a medium understanding of C++ or Python and you’d want to work your way towards a game programming career.
  • Ogre – This is one of the best rendering engines available for free, it has everything you will ever need to make nice visuals for your game and it’s very fast. Use it only if you expect to have a huge world with lots of content and make sure you understand every language feature C++ has to offer before you do, otherwise getting it to work with various other modules like physics will get frustrating very fast.

This is of course just a small list of stuff I have personally tried and used enough to feel comfortable talking about in this series, there’s other amazing software out there with decent support for beginners, I can recommend looking over Panda3D, SDL and SFML if for some reason nothing you see here has convinced you.

Putting it all together

Probably the most important thing in game development is making sure everyone has fun during the process because if you don’t have fun when you’re making the game, then the person who will want to play it won’t stand much of a chance, so make sure everyone feels comfortable with the choices you make. Also if you don’t have pretty images and can’t find someone to help you with your art, don’t force it, try to mould your game to use simple drawings (see Geometry Wars for reference) or see if you can find something you can use in this list:

So that’s about it for now, see you soon with a post on how to make an HTML5 game.

PS: I love feedback, so if you have any feel free to drop me a comment, email, or tweet.

Pinballs’ story

I really like stories, generally because there’s something you can learn from them and I particularly enjoy dev stories because not only you learn from them, but at least in my case I end up learning something useful.

This dev story is about the reason that neat little time waster called pinball wasn’t included in any windows release after XP. I guess “management reasons” was a bit of a no-brainer, but often times software engineers stay overtime to make things they believe in happen, I for one have done so on some occasions, so my curiosity naturally settled on the question, why didn’t anyone really want pinball in the next release, the answer? poorly written code.

You know something is truly badly written when the guys writing the operating system it runs on can’t figure it out, as it turns out the issue was quickly diagnosed, but finding the actual code that created it was a bit like finding an accidental piece of hair in your lasagna. It’s too bad they didn’t get to the bottom of that floating point problem though, would’ve made for a better story in my opinion, but at least I can say I learned to be more wary of rounding errors.

Anyway, the story is here, make sure to read the comments as well, they provide some further interesting insight.

Defcamp Conclusions

It’s only natural that if I write an introductory post regarding an event, then I should also follow up with some conclusions, more so when the event itself was to say the least awe inspiring.

Now I know one or two things about security, it’s as much a hobby as it is a curiosity of mine, though I’m not the “I don’t know what that is but I know I’m gonna break it” type, I like to understand common pitfalls so that if hypothetically someone were to try and break my code at least they’d say it posed some sort of a challenge, so this conference was a bit of a head rush for me, quantity and quality playing equal roles.

However what happens in Defcamp, stays in Defcamp so I’m not going to go into a lot of detail regarding the contents of the presentations, if you want them, send them an email, I just want to point out that everyone there did the same things you’d do, they only saw them differently, so if that’s what you’re after, then you’re definitely going to want to participate next year.

As for me, count me in next year as well, I have a flag to catch.

Defcamp

Seeing how lately I’ve been stockpiling on technical posts, I think a small change of topic scenery is in order, so today I’d rather talk about an interesting initiative taking place here in my approximate vicinity.

As you might have guessed by now it’s about Defcamp which announces to be an all in one security conference. There’s of course lots of speakers (official schedule anyone?) and each and every one of them looks interesting in it’s own way, so if you’d ask me to choose a favourite right now, not only would I not know which one to point, but I’d tend to think that using a coin or the slim shady algorithm would yield a result quicker.

That being said, I find it noteworthy that the conference itself is made up of an almost equal number of officially trained individuals and self trained enthusiasts that want to share their thoughts. Now, I’ve been in the CTF and while it wasn’t as focused as Stripes’, it certainly was an interesting challenge, and if the nature and difficulty of the posed problems is in any way reflecting the level of knowledge you need to posses in order to present at this event, I’d say that I’ll leave that place knowing a lot more than I did when I came.

Also, if you happen to be at the event, I’ll be participating in the final CTF event on saturday as a member of the slenders team, so if you feel like making a good deed, drop by and wish me luck.