Skip navigation

Tag Archives: game

It’s been a while since the last post.

This post is to announce a new version of Freekick 3, the latest rewrite of my project of writing a soccer game. It doesn’t have fancy graphics (on the contrary, it’s very ugly), but it tries to provide a fun soccer game to play nevertheless.

This is actually the first announcement of Freekick 3. The previous announcement on the Freekick series was the announcement of Freekick 2. Here’s a short overview of the features.

– A few different game modes, including friendly games, knockouts, leagues, seasons and a mockup of a career mode.

– The team, league and player data is not included, but can be imported to Freekick 3 either from Sensible World of Soccer data files or, my favourite, from Wikipedia. By having a script to fetch all the data from Wikipedia it’s ensured that the data is relatively up-to-date and that there’s a fair amount of teams to play against.

– The AI is improved and may provide a nice challenge.

– You can either control the whole team in the match or choose to just control one player.

You can download Freekick 3 (source) from https://github.com/anttisalonen/freekick3. I’ll show a quick tour around Freekick 3.

This is the main menu (quite similar to Freekick 2).

This is the main menu (quite similar to Freekick 2).

After fetching the data from Wikipedia you have lots of teams to choose from.

After fetching the data from Wikipedia you have lots of teams to choose from.

You can tune the line up before the match.

You can tune the line up before the match.

During a match - about to cross.

During a match – about to cross.

Career mode currently includes a league season along with the national cup.

Career mode includes a league season along with the national cup.

Football league two mid-season table.

Football league two mid-season table.

Fighting for the ball mid-field.

Fighting for the ball mid-field.

Here’s the announcement of my latest programming project. It’s called Star Rover 2, and it’s a space flying game. You can fly around in space, trade goods, fight against other ships and complete missions for different governments. It features different difficulty levels, a high score list and several ways for the player to play the game. It’s also the first game I wrote in Haskell that’s actually playable.

Flying between planets

The game itself is quite simple: you start on a planet, and you can buy some cargo if you want before launching into the space. In space, you can fly to other planets and see if you can sell your cargo for a better price. There are other ships in space as well, and you’ll get interrupted every once in a while when coming across one, with the possibility of attacking the other ship. If you win, you get their cargo, and the various governments may have their opinions about the attack as well.

(it looks better in motion :)

Combat in Star Rover 2

As the game progresses, you may earn a reputation among the governing bodies, which leads to new dangers and possibilities. The international relationships are complicated, and attacking a ship of one nationality may not only affect the nationality being attacked but their friends and enemies as well. By playing your cards right you can receive missions from governors, and by completing them you may boost your ranking further.

Captured cargo

The game is quite non-linear; it ends when your ship is destroyed often enough and you are too weak to continue, or when you choose to retire. At the end, your achievements are rated and you may make it to the high score list. Until then, you may choose your activities freely.

You can find Star Rover 2 at Hackage, so if you have cabal, you can install it by running cabal update && cabal install starrover2. You can also fetch the sources from github. As for dependencies, you’ll need SDL, OpenGL and FTGL.

In the beginning, Star Rover 2 was more or less a test of whether I can actually concentrate on one project enough to have a playable game in the end, and I’m glad it’s now reached a state where it can be released. Other than that, I was curious to see what programming such a game actually is like in Haskell, and I’m quite pleased with the results. I started working on Star Rover 2 on my spare time pretty much exactly a month ago, and now it amounts to about 2000 lines of Haskell code. I was a bit worried I couldn’t write a larger project in Haskell, but now I can see how well Haskell scales up to complex tasks. This was also my first project where monad transformers actually came in very handy.

Any feedback and bug reports are of course very welcome.

It’s been quite a while (a month, actually) since my last post. That is not a sign of laziness, however, on the contrary; I’ve been busy playing around with Haskell and Python lately. In the last post I wrote about taking a break from Ogre to see what this thing called functional programming actually means. I think I’ve come closer to figuring that out in the past month.

Haskell really is quite an interesting language. (There’s a little tutorial showing some very nice aspects about Haskell here.) I started learning it by going through the tutorials available at haskell.org, and especially walking through Yet Another Haskell Tutorial, a mighty PDF book that explains all the major aspects of the language. I really had problems figuring out how to simulate state within Haskell, and the State monad didn’t really make it seem much easier. After going through the source code of some Haskell projects such as Frag (a 3D shooter) and LambdaHack (a roguelike), I finally started to slowly understand how a bigger project in Haskell could look like. So, to start from the bottom and work my way up, I made a blackjack and a video poker game. They’re text based but helped me figure out how to program some simple things in Haskell. (If you’re interested, you can find the sources + binaries here, MIT licensed.)

After finishing those two little cute things, I wanted to tackle the real prob– project, my soccer game wannabe. So I figured out how to read XML files in Haskell to serialize some data. As can be seen from my card games code above, I didn’t quite understand all of the monad concept (and still don’t), which turns out to be a pretty serious drawback when using Haskell to program in a bigger project. As Haskell is a purely functional programming language (one cannot emphasize that enough, I guess), doing something like file I/O without monads is impossible, and without advanced use of monads very tricky once things start to go wrong. The result is that if there is an error somewhere in the XML file to be parsed (my program doesn’t do any validation at the moment) or a bug in a function parsing the XML file, the bughunt may prove to be a very wiery task. So the next thing to do before I go on programming with Haskell is to learn more about monads. Luckily there are a lot of tutorials to the subject on Haskell.org. After that, the smartest thing for me to do would be a rewrite of my XML serializer.

My XML serializer could handle some data, but as I wrote the few XML files manually to test with I realized there is still a lot to design regarding the structure of my soccer game. And in order to see if my design would work, I needed some test scripts to create some XML files that should be able to work with each other. Since creating XML files by parsing text files and adding more or less random data to them is quite an I/O intensive thing to do and since I just wanted to quickly have some scripts that would do the job for me, I decided to do the job in Python instead.

Now, I wasn’t very experienced in Python (to be precise, I had programmed about 20 minutes in Python before this), but I still had somehow had the idea that programming in Python would be extremely fast and easy, especially for such not-very-large programs. After a few days of fooling around with Python and working with the excellent Python lxml library my scripts were finished and it seems I have proved myself correct. Even though my creations look quite terrible (if a Python fan saw my code he’d probably get his eyes hurt) and are written in a procedural fashion reminding me of my BASIC times (maybe Djikstra had a point after all) they do get the job done in the end and I think I can even understand the code.

There are some things I don’t like about Python (mainly the dynamic typing and the fact that is interpreted) and it surely doesn’t fit well for CPU intensive code, but for my XML creation scripts it’s perfect. Python also seems to be very easy to learn (just like Guido wanted it), and my scripts are a living (working) proof for that. I still keep learning Haskell (of course) since it seems even more elegant, faster and is purely functional, but the small Python excursion showed me I should keep clinging to the “right tool for the job” paradigm.

So, what now? Well, there’s the topic of monads to look at. After that I should do a rewrite of my XML serializer. (As boring as it may sound.) Then, well, I should be able to go on with my soccer game project, but with monads this time… We’ll see how it goes.

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.