I was just thinking: If you can do this for your todo list, why not do it for your bug tracking system? And the more I thought about it, the more it made sense. Every decent developer team uses a bugtracker (such as Bugzilla or Trac): a tester opens a new bug, a developer fixes it, the tester checks if it’s fixed and closes the bug… BORING!

What if a tester (aka Bug Summoner) searches for bugs, and when he finds one, summons a new Bug into the RPG bugtracker system. The developer (aka Bug Slayer) checks if it’s a valid bug. And if it is, he sends back XP to the Bug Summoner (because he found a valid bug). The Bug Slayer then kills that nasty bug. The Bug Summoner checks if it’s really dead, and if it is, the Bug Slayer receives XP. If it’s not dead, the Bug Summoner revives the bug and someone has to slay it properly.

You can even take this further and let your whole workplace run on an RPG system! Lots of employees procrastinate by playing games on Facebook during work hours. So why not let them play the Workplace RPG? Productivity is aligned with RPG goals. Gaining an XP level can give you a better company car, an extra vacation day, a raise, etc. Instead of hating Monday’s, you can now look forward to receiving those last eXperience Points to increase your skills or level up, or becoming the company’s “Slayer of the month”.

For managers or company owners this also makes sense. Having clear metrics on how well each individual is performing is priceless. Of course you will have to align the RPG rules with the company business goals.

After a quick search on Google I noticed this other article with the same general idea. So am I just dreaming or could this actually work in an IT workplace? And would you want to work in such an environment?

Koen Witters

Follow me on twitter

Traditional Object Oriented Programming

In every object orientend programming course or book that I know, you get introduced to a concept called encapsulation. Encapsulation is a technique that allows you to protect implementation details while exposing only the interface. The advantage is that the rest of the code can only use the interface, and therefore is not dependent on the hidden implementation.

The thought behind the whole idea of encapsulation is that when implementing a class, you protect it against misuse. You make sure that the user can’t break it. You have total control over your class, and the user can only use that what you allow him to use. Another advantage is that providing a stable interface will protect implementation details that are likely to change, and therefore limiting interdependencies between software components. That is, it forces the users to do so.

Most Object Oriented programmers totally agree with all of the above, and I used to too. But that was until I met python.

OOP without Encapsulation?

Python supports Object Oriented Programming, but it doesn’t support encapsulation. Now how is that possible? Various OO programmers asked the same question in the python user group, and the end conclusion is pretty simple: you don’t need encapsulation for OO. In python everything is public, you just put and underscore before members or methods that are not part of the interface. If the user is going to use them, it’s at their own risk. Python programmers refer to it as “encapsulation by convention rather than enforcement”. But essentially it’s not encapsulation or data hiding at all. If you ask yourself why this would be an improvement, you probably don’t know that in some rare cases, it is necessary to access the implementation. Let me explain below.

Using the ‘computer’ metaphor

I have this computer on my desk, and it’s a nice piece of engineering. It has a public interface which is clean and simple; On the front it has 2 buttons “Power” and “Reset”, and a few leds to show if it’s on or if the hard disk is accessed. On the back it has connectors where I can plug in the power, network, keyboard, mouse, screen, etc. .

When it’s broken or I want to upgrade, I can just buy a new one and it will provide me with the same interface.

What my computer doesn’t use, is proper encapsulation. Remember that encapsulation is restricting access to some of the underlying components. But with my computer, I can pop open the hood and do anything I want. The hardware manufacturer didn’t restrict my access to the underlying components, and I’m glad he didn’t. The thing is, when I open the computer case, I know 2 things:

1. I might break stuff
2. Components inside the computer will probably change when I buy a new one.

This is exactly what encapsulation is trying to prevent. But you know what, I want to have a choice. I want to be able to put a new hard drive or silent fan in there, and yes, I know the risks, and know a new computer probably won’t support them anymore. But as a user, it’s my responsibility to make the correct decisions for solving my problems.

So what would happen when the hardware manufacturer did use encapsulation. Well, then he would make it extremely difficult for you to open the case, and anytime you want something changed you need to go back to the shop.

Encapsulation restricts access to implementation details. While I’m not saying you should access implementation details, sometimes it might be handy to do so. With hardware I’m glad they don’t restrict me opening up the hood, so why would I like it in software?

Abstraction instead of Encapsulation

One definition of abstraction states: ‘the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.’. In programming terms this means that you provide an interface on top of an implementation, but the user only needs to know the interface (abstraction), and not care about the implementation details.
The difference with encapsulation is that when the user wants to, he can still access the underlying details.

Most hardware uses abstraction instead of encapsulation. They provide an interface that’s not likely to change, but still allow “power users” to pop open the hood and access the implementation.

When using abstraction instead of encapsulation, the user can clearly see the interface, and use it in the same manner as with encapsulation. Users are encouraged to use the public interface, but are not restricted to it. When only using the interface, abstraction has the same benefits of encapsulation. But when needed he can also access the implementation behind it. And because of the clear distinction between interface and implementation, he is aware of the risks involved (ie breaking things and future incompatibility).

A real world programming example

Let me show you how this might work in the real world of programming. Suppose I’m writing an application that uses a multiplatform GUI library. Multiplatform libraries are great because they make porting really easy. Their public interface is the same across platforms, and so the method calls don’t need to be adapted when switching platforms.

Now suppose the Windows users of our application are requesting a certain feature. That features is not supported by the GUI library, but it is available in the underlying Windows implementation of that library (because MFC supports it for example).

At that point you must take a decision: If you respect encapsulation, you are limited to the following things:

1. Implement it yourself on top of the GUI library, but this could mean rewriting a whole GUI control yourself (duplicating both the code of the GUI control, and the code of the MFC feature you want).
2. Contact the GUI library vendor to make it available in their public interface, but this also means they have to implement it themselves on all non-Windows platforms. In other words, you won’t have it available soon.
3. Switch your windows code over to a Windows specific GUI library. This will cost you some serious time, money and headaces.

What if you would drop encapsulation and use abstraction? Well, in that case you still have the options above, but also an extra one. You’re able to access implemenation details, but then you will have to consider the risks:

• Accessing it is risky for breaking other parts of the GUI Library
• Updates of that library might change the way they use MFC, so you will have to double check it every time you upgrade
• Probably no official support for that from the Library Vendor

The thing is, by using abstraction instead of encapsulation, you do have a choice whether the benefits outweigh the risks. And in this case, that’s probably correct. But remember, I’m not encouraging anyone to use implementation details, but in specific cases, it might be the best solution.

How I do it

Because Python doesn’t support encapsulation, I don’t have to do anything specific to use abstraction instead of encapsulation. I follow the conventions of putting underscores in front of methods and members, to make the distinction clear between interface and implementation. My users should only use my public interfaces, but if they really need to, they can ‘pop open the hood’ pretty easily.

In more traditional object oriented languages, I use ‘public’ for my public interface, and ‘protected’ for my implementation details. You probably know the following expression from the ‘Gang of Four’: “Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‘inheritance breaks encapsulation’”. That last part is exaclty what I need for my abstraction . My users use the public interface, but if they really want to, they can access all implementation details by deriving their own version from it.
This also speeds up my development, because I don’t have to break my head over whether I should use private, package-private, protected or public. I use public for my interface, and protected for implementation details. I love to Keep It Stupid Simple.

Encapsulation is not Security

Sometimes it is necessary to protect or hide some data from the user. But in this case we are talking about security, and the worst way to implement security is through Object Oriented encapsulation.

Conclusion

Depending on implementation details is a bad idea. Therefore you should only use the public interface of a class. But for specific or unforeseen needs, it might be useful to be able to access implementation details. It’s the responsibility of the class to be as useful as possible, and the responsibility of the user to use it in a professional manner. Don’t treat your users like idiots, but treat them like professionals who make use of your class the best way possible, to solve their specific problems. If they to need access the implementation details, they probably have a good reason to do so, because else they wouldn’t. So don’t treat them like idiots by using encapsulation.

Koen Witters

Follow me on twitter

    .--.
   |o_o |
   |:_/ |
  //   \ \
 (|     | )
/'\_   _/`\
\___)=(___/

A lot of myths exist about Linux users and the whole open source community. Because of these wrong assumptions, a lot of game developers still hesitate to support the Linux platform. As both a Linux user and an indie game developer, I want to educate everybody with hard facts about the advantages of supporting Linux.

Here follows the list of 5 reasons why it benefits for indie game developers to support Linux.

1. Doesn’t take more effort or budget

Sometimes you hear game developers having a realy hard time porting their game to Linux, sometimes they even give up just because they run into technical difficulties. Truth is that it all depends on how you wrote your game in the first place. If you choose the right technologies at the start of your project, porting a game to Linux or even Mac takes no serious extra effort, or it can even eliminate a porting step.

There are plenty of game libraries and frameworks out there that support all mayor platforms (Windows/Mac/Linux), so why pick one which limits you to only one platform? I personally use pygame for my 2D games, and it just runs out of the box on all these platforms. For 3D you got some powerfull engines (for example Ogre3D for rendering, Bullet for physics, etc…)

2. Yes, linux users pay for games

A common misconception is that Linux users are not willing to pay for software. They get a whole operating system, together with loads of software, for free. Therefore most think that the main reason they use Linux is because it’s free. The following might surprise some people, but Linux users actually use it because they think it’s a better operating system (compared to anything else out there).

You don’t have to take my word for it, just look at the statistics. The developers of indie game ‘World of Goo’ found out that Linux users are willing to pay higher prices for their game. And my own statistics on Mystic Mine show that Linux users are more eager to buy my game.

3. They love it when you support their favorite platform.

In a world where MS Windows dominates desktop computers and Apple’s Mac OS is a tiny second, Linux dangles as the underdog of Operating Systems. Hardware and software companies often forget to support Linux. In the past Linux users sometimes responded to this in an offensive and impolite manner. But that trend is changing. Of course you still have total jerks online, but they represent a tiny minority right now.

Anyone who supports Linux knows how nice that community really is. They are helpful, even giving advice and tips on a technical level. They also give a lot of positive feedback, and are very supportive for anyone who supports ‘their’ operating system.

4. Less pirating. Linux users are not used to visiting warez sites

A lot of Windows users, especially young gamers, are familiar with warez sites. These sites are full of pirated software and cracked serial numbers. This way they can download commercial software for free, but at the risk of bringing in malicious software like viruses or troyans.

As a Linux user, there’s no point in visiting such sites. Most Linux software is freely downloadable as Open Source software. And as long as Linux users don’t care about warez sites, warez sites won’t care about Linux users. It’s kind or self maintaining.

5. Easier to get noticed

As an indie game developer, you have to work hard to get exposure for your games. Most game review websites get tons of requests form other game developers. But since Linux is a niche market, even the most popular Linux gaming sites are eager for any news on a game. It’s the questions of what’s best for your game: A big fish in a small pond or a small fish in a big pond. If you also develop for Linux, your game can be both the small fish in the Windows and Mac pond, and the medium/big fish in the Linux pond.

And again, it’s not just me that noticed this. The game developers from Wolfire concluded that “A lot of people heard about and supported Lugaru simply because we had a Linux build”.

Conclusion

As you can see it does make sense to develop your games for Linux. Or to put it in 2D Boy’s words: “There is a market for Linux games after all ”.

So I hope that with this article more games will become available for Linux, and more indie game developers can make a profitable business.

Koen Witters

Follow me on twitter

]]> http://www.koonsolo.com/news/5-reasons-why-indie-game-developers-should-support-linux/feed/ 2 http://www.koonsolo.com/news/lecture-video-on-game-loops/ http://www.koonsolo.com/news/lecture-video-on-game-loops/#comments Thu, 07 Jan 2010 14:47:55 +0000 Koen Witters http://dev.koonsolo.com/?p=179 I wrote my original article on game loops a few years ago, and it’s nice to see that it’s still popular today. Recently I stumbled upon some game loop lecture slides of Aaron D. Lanterman, and he seems to use my game loop article as a reference . He even has a video of his session online. So if you had a hard time understanding my article, maybe you should check out that video. It might make things more clear.

Take a look at Braid or Tower of Goo for example. Both are innovative games, both revealed their concept long before their release. And you know what? Nobody stole their idea.
Next to these two masterpieces, I’m shamelessly going to use my own game Mystic Mine as an example. To be honest I was indeed scared that someone would steel the idea of those impossible “Escher”-levels. But you know what? Nobody did! And if you think of it, this makes perfect sense. Why would you clone a game that hasn’t yet proven itself in the market? And if it’s already popular before release, people are waiting for the original game, not the clone. Besides, are you sure you will put the game faster on the market? It just doesn’t makes sense to clone a game that hasn’t been released yet. And your fellow indie game developers, they all have their own game ideas to develop.

So market the hell out of your game while working on it, and don’t worry about someone steeling your idea or concept. Now go do it! What are you waiting for?

• You have to remove any links in your game that point to your website.
• You don’t receive customer details (most importantly their email).
• You can’t decide your game’s selling price.

So what do you get out of it? Well, some portals get a lot of traffic. And what you can get out of this is a lot of sales. A lot of sales on 25% means you get a nice amount of money. But does this theory make sense? I think not. See, for portals it costs the same whether they put a good or bad game onto their website. It makes sense that when they think a game is not going to sell, they take a bigger cut from the revenue, so they can recoup their costs. When they think a game is going to sell big time, they can take a smaller cut because the total revenue will be big enough. And in practice this also gets applied: popular games can negotiate for a bigger cut.
And now comes the real problem: when you get a small royalty rate, you expect to sell high volumes to get enough revenue. But as I explained above, a small cut probably means exactly the opposite: a low sales volume.

So making deals with portals is currently very bad for your long term business strategy. You offer them your game, they use it to gain extra customers, keep those customers for themselves, and keep the biggest revenue share. And what do you get out of it? The breadcrumbs that fall off the table.

The only thing portals can offer you is traffic, but remember that they will keep that traffic for themselves. They are in control, not you, and they make damn sure it stays that way.

So what can you do about it? Well, just refuse the kind of deals that will put you in dead end street. Use your games to build up your own business, not someone else’s. And when doing deals, make sure both parties get their fair share.

I want to know your opinion on this, so comment below and tell me what you think. How low will you go to sell your game?