Watch out for the APIs

There’s an old saying in the computer industry that says you should be lenient with what you receive and accurate with what you give, mainly it means that when parsing data you receive, it’s not uncommon to receive bad input, so it would be nice of you to either tell the program or person that generated the error that they did something wrong, try to correct the data or use a default.

Back in the real world though, writing software has taught me that this is just saying that gets ignored to several degrees by almost every API. My guess is that once the spec is done, no one actually bothers to actually whatever comes out. This post serves as a list for the problems people seem to ignore when they  make an API for C++.

Let’s start with a little bit of math, for those not very interested in 3D concepts, a Quaternion is a 4 element vector that you can turn into a rotation matrix. It basically represents the rotation around an axis, so when you see a Quaternion class with a constructor that looks like the following:

Quaternion(double, Vector3&);

your natural reaction would be to assume that it initializes the new quaternion so that it represents the rotation specified by the double argument around the axis represented by the Vector class, right ? Well as it turns out, it more often than not it just copies the values into its’ members. How on earth is that more useful than something that it was created for is beyond me, but that’s probably because I’ve actually used quaternions.

Moving on to some geometry, when you’re working with images you’re bound to run into something that requires coordinates. Now there are a lot of ways to say where an image begins and where it ends, but fortunately only two of them are used in practice. Most of you have probably seen the one where coordinates start in the upper left corner and go toward the bottom right as they increase, so for instance if you have a resolution of 1280 x 800, then the bottom right corner is (1280, 800). The second one is the mathematical one where images start in the bottom left corner and go towards the upper right, however this one is seldomly present in libraries, so if you insist that the Y axis should be up because that’s how things were in highschool, then at least leave a comment to let the rest of the world know that the top should be bigger than the bottom of the image in order for something to work.

And last, but not least, never ever use STL in an API, ever. Containers are awesome for programming in general, I agree, but when you want to send data from one dll to another you have to keep in mind that the people making the other library are sometimes using other tools than your own, and containers are almost never compatible between toolsets, something always crashes sooner or later unless everyone uses the same compiler and linker, in theory that’s not much of a problem, in practice however you’re often forced by the environment you’re developing for to use certain tools if you want to be able to debug your application. So in the end it all comes down to either using some really awkward hacks to be able to accommodate the library or dropping that library altogether. This is why nice, clean APIs are usually made in C, well that and no name mangling to take into account when importing functions by hand.

So yeah, making an API isn’t as easy as one would originally assume, however if you have some patience and are lenient with what you expect from it sometimes it’s not that bad, after all everyone makes mistakes, they’re ok so long as you learn to recognise them early.


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.