Skip navigation

Category Archives: ogre

In my last post I was writing about dynamic animation. I was researching the topic a bit and made a small plan on how to actually implement the technique. As it basically boils down to three steps – ragdoll without any muscles, ragdoll with joints and an ability to move the body parts with them, actual animation by defining the movements using these joints and muscles – I started with the first step, which is my own ragdoll class. However, after working with the subject for some time I got tired of it and decided it was time for something else. I often feel like having an overdose of some particular subject, where I have the feeling it’s for the best to give the problem some time and rather concentrate on something else.

So I will be returning to dynamic animation at some point, but for the past week or two I’ve been going for something completely different. Luckily I’m going for a soccer game, which means there are a lot of construction sites to work on. Basically the game is divided to two parts – the actual soccer game on the pitch, and everything around it including the managerial and organisatory things like creating and updating league tables, calculating the results of the matches not shown etc. So I decided to take a look at the latter side of my project for some time.

In my first post I was wondering about which programming language to use with my project. I can’t remember if I wrote anything about functional programming languages back then, but ever since I realised how handy they can be when working with lots of arrays or lists (such as league tables) and AI (both the player and the manager AI) I’ve been wondering about using a functional programming language in my project. The problem is, I don’t have any experience in programming with them and they seem to have a reputation of being not so easy to learn once you’ve gotten used to the imperative style.

The good thing is that I’m willing to learn from my project. That was why I also went for Ogre and ODE; I didn’t choose them thinking I’d master them in a week, instead I was willing to make the effort and learn them because they’re effective, even if they’re not the easiest libraries to use. And since my past programs with AI haven’t really ended up as I wanted, I wanted to take a look at the world of functional languages. I decided I’d take the time to try and learn Haskell, a lazy, purely functional programming language. While I won’t go to details in explaining what that means (you can go check it out at Wikipedia or Haskell website), the point is that the code written in Haskell is supposed to be shorter, easier to read and to maintain and contain less bugs… If you know how to program in Haskell. So I’ve been going through some tutorials on Haskell (and will be going through them for a long time from now on, I think) and I’m quite impressed with it.

In my next post I’ll hopefully be able to explain a bit about how to use Haskell and how it could be used in my project. (At the moment I’m still too shocked about the new way of thinking to comprehend how I could actually program something with the language.) While I think I have a long way ahead of me with Haskell, I also have a feeling I won’t regret it. After all, I’m already now seeing programming somehow in a whole new way, so that I even see programming in C from a whole new perspective, a perspective filled with pure functions, lists and pattern matching… That can’t be such a bad thing, right?

Advertisements

So, this is the notorious first post to a blog. I hope it won’t be the last one as well (like in my last blog). I’ll just start by telling you what the blog is supposed to be all about. I’m a young computer enthusiast (also called “geek”) and I’m going to program a new computer game designed myself. In this blog I’m going to write all about my game and about the decisions I had to make while doing this game, so this is where 1. I should be looking when I forget why I wanted to do something like I’m doing, and 2. you can check if I’m still doing my game or if I’m vanished somewhere and turned my creation to another piece of vaporware.

Probably the next question for the reader is, what’s this game going to be all about. Well, it’s going to be a soccer (association football) game. How boring, I hear you say. I’m making a soccer game simply because there isn’t any other soccer game that I’d like to play. I want my soccer game to be huge, with tons of leagues and depth (like the good ol’ Sensible World of Soccer), be fun and easy to play and offer you a realistic, thoroughly simulated soccer with an impressive, creative AI. I also want my soccer game to be free software, open source, available for Linux. And since I haven’t found a soccer game like that, I’ll be making one on my free time.

“Oh, this is one of those free software freaks,” I hear someone whisper in the background. I admit that I’m very much into free software, and that free software is also a motivation for me. I’ve developed games by myself before, and still a couple of years ago I was doing that in Windows. Back then I had no idea what the free software fuss was about, and my problem was that everything I wanted to do had been more or less done before. You can’t find the soccer game I’m imagining for Windows, but you get pretty close, and that was good enough for me; I was playing games instead of programming them. Then I switched to Linux and bid my games farewell, my new hobby was figuring out how Linux works (and boy, that was fun). Now, I’m starting to miss gaming a bit again. As we all probably know, there really aren’t that many good games available for Linux, yet I refuse to boot to Windows or use Wine to play games. It’s not only because of Windows as a platform is not ideal or because with Wine most of the games I’ve tried don’t work, it’s also because the games aren’t free (needless to say, I mean free as in freedom). So, I’ll program my game in Linux, for Linux, I’ll make it free and open source, and because I know that there are people who actually miss good games in Linux, my work wouldn’t be in vain.

That is, my work won’t be in vain IF the game gets done and is playable.

I’ll go a bit to the technical details about the game now. The working title is “Free Kick”. Clever, huh. I’ll be programming it in C++, though I also considered other languages as well (namely C, Python, or the two for me unknown languages D or Eiffel). I chose C++ over the other languages because object oriented programming probably makes a big project such as this easier to manage (even if it’s not necessarily my favorite), because of the documentation, APIs, engines and tutorials available and because the step of learning a language like Eiffel or D (which I’ve heard they would be superior to C++ in quite a few areas) with the relatively small amount of documentation is at the moment too big for me to take.

I actually already have some code for the game. In the past few weeks I’ve programmed the basics about the game, but it looks way too shabby and doesn’t really work that well, so I’ll just skip the screenshot. I was programming something about the players a few days ago and noticed I was planning to do stuff like vectors and collision detection, where it hit me that it had actually all been done before (I’m pretty naive, at least when it comes to game development). So I went searching for an open source physics/graphics engine to suit my needs. I had been programming my game with SDL until now and thought it would be enough to be the only library I need, but thinking about the physics and graphics I wanted my game to have made me think otherwise.

So I went to check out the latest engines I could use for my game and the first thing I stumbled upon was Irrlicht. (http://irrlicht.sourceforge.net/) It seemed like a very good engine (and still does), but I went on a bit further down the net and the next thing I found was OGRE3D. (http://www.ogre3d.org/) For me, as an outsider without a clue, I spotted the following differences between the two libraries:

– Irrlicht has some physics simulation, while the users of Ogre rather rely on an external physics engine that they plug in and use with Ogre. This can be done with Irrlicht as well, but Ogre was specifically designed to integrate with other libraries.

– Irrlicht is, based on the first look, simpler to use. It is quite compact, wants to keep things simple, while Ogre offers more features and extensibility, having a slightly steeper learning curve. (This is also what they said in a thread on Irrlicht forums, for which I don’t have the URL.)

– Ogre uses LGPL as a licence, Irrlicht has Zlib. This means a lot of people choose Irrlicht because they are developing a commercial game and make changes to the engine, but don’t want to contribute their changes to the community. If you modify Ogre and release the modified version of it with your game, you have to release the source code changes you made.

At first, I saw the first point as a strong plus for Irrlicht. I thought I only need basic physics (it’s only soccer, after all), and seeing Irrlicht have integrated collision detection made me quite happy, after the horror story of half-implementing that by myself a few years back. The second point was also something that made me rather want Irrlicht instead of Ogre. This is the first graphics engine I’ll be using (since my QuakeC days, but that doesn’t really count), I thought, I should start with the easier stuff. As for the third point, it didn’t really make a difference for me, though I was surprised how happy some people at the Irrlicht forums were for the engine not being GPL’d and how it’s even listed as a feature of Irrlicht.

Yet, in the end I went for Ogre. Why? Well, I tried out a couple of examples of Irrlicht, and it didn’t really impress me. Well, the graphics did, it looked nice, even if OpenGL 1.5 sounds a bit old, but I realized the included physics were really quite basic and I’d have to go through integrating another library as well, just like with Ogre. Furthermore, my impression was that Irrlicht isn’t really as modular and extensible as Ogre, which seems to be built on the idea that everything can be plugged in and out. I still wasn’t quite sure about which library to take, so I looked at the tutorials section of both parties and went through a couple of them. The tutorials of Irrlicht were very easy to understand, very compact, and I found it very positive how easy things were made in Irrlicht. With the Ogre tutorials I was impressed by the amount of information. The tutorials build up from the very basics and go up to the advanced topics explaining everything on the way, making the material a lot to read but easy to learn.

I’ve taken the easy way down the road quite often, but here I had the feeling it wouldn’t bring me so much in the end. So I went for Ogre, even though Irrlicht was also very tempting, with the attitude of spending quite a lot of time learning to use the engine (and the other engines I’ll be integrating with Ogre). I’ve gone through a couple of the first tutorials by now and I’m very impressed. As I’ve often made the mistake of skipping a lot of the learning material of APIs or languages and tried to program my own thing (just to come crawling back to the tutorials later), I’ll be spending some time now just learning to actually use Ogre, instead of starting to program Free Kick with it.

So that was the first post of this blog. Actually I just wanted to tell you about me making the game, plus the “why” and the first “how” about it. I guess I accomplished that. I’ll be writing some more about my project in a few days (hopefully), so stay tuned.