In my previous article I talked about how to create an RPG all by yourself. In case I wasn’t clear enough: the conclusion is that you shouldn’t attempt to do everything by yourself, unless you seriously know what you’re doing.

It’s possible to speed things up by taking advantage of what other people already created. RPG’s seem to be very popular for game development projects, and a lot of people have made their own frameworks or even art available. So why not see if one of them fits your needs?

RPG Frameworks

I’ve assembled a list of RPG frameworks, but there are plenty more. You can always google for more frameworks and specify what details you want. For example which programming language, features, etc… .

• Sphere: A cross platform, open source computer program designed primarily to make role-playing games
• vbGore: A powerful, open source, and free online RPG engine that concentrates on performance and features.
• netGore: A free, open-source cross-platform online RPG engine written in C# and SFML.
• Marauroa: An open source framework and engine to develop turn based and real time games.

RPG Graphics or Models

There is plenty of ready made artwork for you to use in your RPG. You just have to find it. Both free and paying options are available. But even if you have to pay for it, it will save you plenty of time. Here are some resources to get you started:

2D Game Graphics:

• RPG Sprites
• Lost Garden game graphics
• RPG Palace Tilesets
• Sithjester RPG Resources

3D Game Assets:

• OpenGameArt.org
• TurboSquid
• Artist3D
• Exchange 3D

Sound and Music

The atmosphere of your game is highly determined by the sounds and especially the music. There are websites that offer you royalty-free sounds and music, where you can probably find something that fits your needs.

• Soundsnap
• The Freesound Project
• SoundDogs
• Soundrangers
• Shockwave Sound

Conclusion

There are a lot of resources available if you want to make your own RPG. Just Google for it and see if there is a ready made solution for you. Here are the pros and cons of using RPG frameworks and resources:

Advantages:
1. Speed up your development
2. Learn something from other peoples code
3. Choose the art you like

Disadvantages:
1. Every framework is restricted in some way or another: programming language, platform, … .
2. You might need to tweak the art so everything fits together.

Tip 1: Check the license

I can’t stress this enough: when using ready made frameworks or content, first check if the license is OK. Some are restrictive for use in commercial products, other just require you to mention them in the credits or your own license, and others are completely free to use. So make sure you’re not breaking any licenses.

Tip 2: Work Backwards

Instead of first designing your game, and then searching for frameworks and content, why not work the other way around. Find a framework you like, find content you like, and see if you can design a game around it.

Tip 3: Don’t be fooled by bad art

A lot of Role Playing Game Frameworks have sample games, but most of them look hideous. Don’t be fooled. Great art and great programming has nothing to do with each other. Check out the things that really matter in a framework, and search for your own art assets.

In our next post, I’ll take a look at how to make an RPG really fast, and without any programming.

Eschalon Book II from Basilisk Games

This post is a part of the How to make RPG’s series, which shows you the different ways on how to make Role Playing Video Games.

Creating an RPG all by yourself is a huge undertaking. To finish such a project, a lot needs to be done, and that’s probably an understatement. Let’s go over everything:

Program the entire game

You need to write your entire game from scratch. Of course you can use game engines, but the game itself needs to be programmed by you. And remember that programming the game doesn’t only include coding the game, but also coding the graphical user interface, resource management, loading and saving the game, etc.

Create all the art

When doing everything yourself, this also means you need to create customs art for your game: characters, environments, background art, … . Items like characters also need to be animated. And it doesn’t stop there, your game also needs music and sounds. And don’t forget the menu graphics!

Design the game

For game designers, this is the most fun part: make RPG Characters, think about the plot and narrative hook, write the dialogues etc. RPG’s really depend on this, so you need to put in some extra time to write everything down.

Is that all?

That should be it to create your game. But if you want others to play it, or even pay for it, you also need a website, marketing materials, contact game review sites, find beta testers, … .

Reality Check

Torchlight from Runic Games

Creating an RPG like this is a huge undertaking. Want to make it 3D, with multiplayer? Then forget that you will be able to pull this off all by yourself.

If you don’t know how to get started on creating an RPG, or if you don’t know which programming environment, game library or art tools to use, then forget it!
Creating an RPG by yourself should not be attempted if you are new to game development. But lucky for you there are other options. Don’t know how to program? No problem, you can still create your own RPG. I will explain this in the last installment of our How to make RPG’s series.

Conclusion

As you can see it takes a huge amount of work to create an entire RPG. But of course there are advantages by doing it this way.

Avernum 6 from Spiderweb Software

Advantages:

1. Total control over development environment and target platforms.
2. Total control over asset tools.
3. Total control over every detail in your game.

Disadvantages:

1. You have to be a good (or even great) programmer, with prior game development experience.
2. You have to be a good artist.
3. You got to have lots of time available.

To finish your game, you will have to be extremely motivated. Here are some tips if you want to go down this route:

1. Assemble a team so you don’t have to do it all by yourself.
2. Use an existing graphical engine so you don’t have to write that.
3. Use existing tools (for example a map editor).
4. Use an easy programming environment (Flash, Python, …).
5. Keep it small:
   1. Do it in 2D.
   2. Forget Multiplayer.

So, who is brave (or foolish) enough to go down this route?

Most game developers I know have a game idea for a Role Playing Game. So I assume you do too. But making such a game is a huge task, plus, there are so many possible ways on how to make one. That’s why I’m writing a series of blog posts about the different paths you can take to create an RPG. This way you know what your options are, and which of those fit best with your situation.

As I see it, there are 3 mayor paths you can take to make an RPG:

1. Do it all by yourself.
2. Use an existing RPG framework and resources.
3. Use an easy to use RPG creation tool.

I will highlight each of them in a separate blog post, starting from next week. So make sure you keep an eye on this blog, or even better, subscribe to our RSS feed!

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

It’s been a while since I released any news on Koonsolo. That’s because the last few months I was completely focussed on developing our Koonsolo RPG Editor. It’s still far from finished, but currently I can play with some functionality and get some cool results. I will create a video showing off some of that stuff in the near future, so stay tuned!

Last weekend I created a ‘Koonsolo RPG Editor’ web page. That page should give you an idea of what the final program will be able to do. I’m not promoting this page just yet, but I wanted to show it to you anyway . So go and take a look at http://www.koonsolo.com/rpgeditor! If you have questions or remarks, don’t hesitate to mail me at koen@koonsolo.com.

Next time you’ll see some functionality in action ,

Koen.

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

I didn’t provide much details last time, so I hope to clarify some things in this post. The game editor is going to be aimed at creating old school 2D RPG Games like Final Fantasy or Chrono Trigger. This RPG Editor will run on Windows, Mac OS X and Linux. It will be very user friendly, so that anyone is able to create games. You won’t have to know how to program or how to create graphics. But if you’re an artist, you can of course import your own graphics and use them.

Some people asked if the game editor is going to be Open Source, but it won’t. It will be a proprietary product.

The editor will create Flash games, and they will run in any web browser. As a normal user you just click “Play” and the game will be completely generated for you. But if you’re a programmer, you can go into the source code of that game and implement or change anything you want. The game source code will use our Koonsolo Game Library, and that library will be Open Source. I will use the liberal ISC License, which allows you to adapt anything you want and release your games as both commercial or free products.

I’m working together on this with fellow indie game developer Amaranth Games, known for their successful game series Aveyond. Since Amaranth Games creates old school RPG games, they are the ideal partner.

All technical aspects will be handled by Koonsolo, so the game editor and game engine will be programmed by me .

I wanted to share all this info so you know what Koonsolo is up to. Since there hasn’t been any official announcement yet, you are the first to know about the collaboration of Koonsolo with Amaranth Games, and about the details of our upcoming RPG game editor .

Kind Regards,

Koen Witters.

Recently I came across this great opportunity, but it forced me to make a tough decision. I hope you will understand, and will keep supporting Koonsolo as you did before.

As you might know I started Koonsolo because I love creating games. Mystic Mine was the first game that I created entirely by myself, and I planned the same for the next one. But doing the programming, graphics and marketing all by myself is very hard and time consuming.

As I was working on my upcoming game, I got a request from another indie game company to work on a project together. This project isn’t a game, but a tool to create games. It will allow anyone without programming or artistic skills to create cool video games. And it’s powerful enough that when you do know how to program, you can write your own code. Or if you are an artist, you can include your own graphics.

I’ve been programming games since I was a kid, so this is the ideal opportunity to share my technical knowledge, and make it available to anyone. Doing this together with another company allows me to focus on the development and the things I’m really good at.

Because this game creation tool is going to be released first, it also means that my next game won’t be released in the near future. I hope you can understand my decision, and I certainly hope that you’re interested in creating your own games using my tool .

If you have any questions or remarks, just leave a comment below.

Thanks!

Koen.

    .--.
   |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