Friday, May 31, 2013

On Why the Stars We See in the Sky are NOT Long Dead

The light from distant stars takes a long time to reach us. High powered telescopes can look at stars that are millions, even billions, of light-years away. Because of this, a surprising number of people believe that when they look up into the sky, they are seeing stars as they were millions of years ago. Unfortunately, that's not true. In most cases, you're only seeing the star as it was a couple of centuries ago, or in many cases, only a couple of decades ago. In fact, if you look at Rigel Kent (the left most of the two pointers to the Southern Cross) tonight, you'd be seeing it as it was back in January 2009.

In fact, for more than half of the 50 brightest stars in the sky, the light reaching us now left them some time in the 20th or 21st centuries.

It kind of ruins the popular anti-joke: "According to astronomy, when you wish upon a star, you're actually a few million years late. That star is dead. Just like your dreams." Pretty much all the stars we see are almost certainly still alive. The one that's expected to die the soonest is Betelgeuse (that's pronounced Beetlejuice), which we see as it was in the late 14th century. Betelgeuse is due to explode any day now... Which in astronomical terms means some time in the next million or so years.

Just to give you an idea of how long ago the light left some of the stars in the sky, I used Stellarium to generate a map of the stars in the sky from Johannesburg, South Africa at 8 pm and 4 am last light. I've labelled most of the more prominent stars, and included the approximate date on Earth at which the light left the star. I didn't account for changes in calenders or anything, so some of the older dates may be a few days out, but it's still accurate enough to give you an idea.

    Johannesburg, 30 May 2013, 8PM:

    Johannesburg, 31 May 2013, 4AM:

As always, you can click on the images for a higher resolution version.

Unfortunately, the constellation of Orion (of which Betelgeuse makes up the armpit) disappeared over the horizon shortly after sunset, so it was not visible for very long last night. For the briefest instant at around 4AM, the very dim Mu Cephei would have popped above the northern horizon if you had a clear enough view. Mu Cephei is one of the largest and most luminous stars in our galaxy, and yet it's barely visible with the naked eye. Light from Mu Cephei travels a mere 6000 years to reach us. If you think that's a long time, consider that light takes 100 000 years to travel from one side of the Milky Way to the other, and about 2.5 million years to get from here to our neighbouring galaxy, Andromeda.

If you enjoyed this post, then don't forget to like, tweet, +1, or upvote on reddit. If you have any questions, comments or complaints, post them using the form below.
. . . . . . . . . . . . . . . . . . . . . . . .

Wednesday, May 22, 2013

On Video Game Programming

I haven't really had much time in the last few years to spend time programming something for fun, and I think it's really starting to get to me. In an attempt to fix this, I've set myself a fairly ambitious goal. I'm going to attempt to program a fully functional 3D game, or at least a working prototype of one. The catch is that I'd like to release the game under a GNU General Public Licence, or something similar, and so any libraries or engines that I use need to be compatible with that licence. Even so, I'm strictly limiting myself to using only free and open source software to develop the game. That means I'm not even going to use my Windows laptop to make backups. The game will stay strictly between my Linux netbook and desktop (This is also to prevent me from being tempted to do anything on this project while I'm at work). However, I'd like the final game to be cross-platform if I ever release it.

    1. My Game Programming History

My experience with creating games is fairly limited. I completed my first "real" PC game about 10 years ago. It was a simple text-based fighter with a combat system fairly similar to that of the Game Boy's Pokemon games. I've made a couple of attempts at games since - all ridiculously simple - a vertically scrolling space shooter (where balls start falling from the sky that get progressively faster), a pointless game where you control a grim reaper figure and try herd one of several balls into various baskets on variously shaped fields. One of the most promising games I've made was a horizontal scrolling platform game inspired by Contra. You controlled a figure that resembled the guy from the toilet signs (I'm sorry. I drew all the sprites pixel-by-pixel in MS Paint), and the object was to make your way through the rooms of some form of hostile building. I finished the first level, started prototypes for the second and third, and realised that I had no clue about balancing difficulty. The result was... well, it's probably better if you just try it for yourself.

    2. The Concept

So, what am I going to try and make now? The concept is one that I think is really simple to implement. I want something that makes use of (at least approximtely) real life physics, but in an environment that is completely unfamiliar. I want people with an understanding of physics to be able to understand the game mechanics, but I want a person who works off of everyday experience to be thrown off, and hopefully spark a curiosity as to why things happen that way.

When it comes to physics, there are two phenomena that more or less govern all of our intuition when it comes to judging how things behave. Those two phenomena are gravity and physical resistance (be it friction, air resistance, whatever). So, getting rid of these two things will change the way everything behaves, and the behaviour will be physically possible, yet completely unfamiliar. You can see where I'm going with this. The game will be set in space. Or at least, on a space station in space.

When I was a teenager, I played a game called Descent. While I was never particularly good at the game, the game's unconventional use of 3D movement in an enclosed zero-gravity environment stuck with me. I was always fascinated with the way my mind would always pick a direction as "down" based on visual clues, and I would always needlessly try and orient my ship in that direction, even wasting time during combat to do so.

When I read Orson Scott Card's Ender's Game, I could not help remembering playing Descent, always needing to orient myself according to those visual clues. "Remember- the enemy’s gate is down" is a well known quote from the book - and refers to the fact that ignoring the visual clues, and over riding your instinct with a different concept of direction could give you a strategic advantage. I always wondered about how it would feel if I was in a Battle Room, with no ability to change direction or velocity until I touch an object, and with no sure way to stop myself. I've always toyed with the idea of programming something based on that concept. I've finally decided that I will make it into a game.

So, to sum it up, the game will consist of a room, with obstacles, in which players will float free from any effects of gravity or air resistance. The only means of controlling ones motion will be through physical interaction with the walls, obstacles, and other players. In this, I will incorporate a combat element, and hopefully later a team combat element, as well as a certain level of puzzle solving. I don't want to take the concept too far until I see how everything works.

    3. Starting Off

Programming a game is not easy. There are a lot of aspects that need to be taken care of, and the one thing that's always stood in my way is not knowing where to begin. In the past, I've falling into the trap of designing the GUI, the main menu, writing the help files, character design, and all the wrong things to start with. I know where to begin now. A prototype. I need a rectangular room with a sphere, and very basic camera controls. I can then make the sphere move, and then make it bounce off walls. Then I can worry about adding controls to allow the player to control how the sphere bounces. Once I've got that, I'll have a basic prototype. I'll then start thinking about how to add other players. Only once I have that am I going to try put in models, textures, a GUI, and all the rest.

    4. The Language Question

The first thing I need to decide is what language I'm going to write the game in. This section is going to have to start with a bit of a rant, and I apologise for that. Without a doubt, Python is my favourite language. Despite criticisms against it, it's actually not such a terrible language to use to make a decent game. The one thing I hate though is the general attitude some people seem to have toward Python. "Its slow because it's a scripting language!" It can be used as a scripting language, but it's got so many other uses. Also, it can call C libraries, which is almost as fast as if the entire game was written in C/C++ anyway. "But Python sucks with graphics!" Yes, but once again, C libraries... Personally, I can write code far quicker in Python than in any other language I've dealt with, and it's not just because I've got more Python experience. I also get fewer bugs with Python, and I find those bugs easier to find. I've often written a quick Python program to do menial tasks. I've never written a C++ code for anything other than university projects, and even then, I only used C++ because the choice of language was made for me. I'm not a big fan of C++. I love almost everything about Python.

But the fact remains, if I Google some problem I'm having in Python, I land up with a forum post swamped with useless comments like "learn a real language" and the like, even though the real solution is usually some really elegant and concise line of code, and it really gets on my nerves. When I Google the same problem for C++, I get several civilised answers on how to go about solving my problem.

So, for that reason, and because of the game engines available, I'm going to be programming this game in C++. Although I've read through and made minor modifications to bits of C++ code in the last couple of years, it's about 6 years since I did any serious C++ programming from scratch, but hopefully I'll pick it up quickly again. Project Euler time again, I guess.

    5. The Engine Question

So, I also mentioned that I'd be using C++ because of the engines available. If I was using Windows, I'd probably use Unity. I've heard a lot of good things about Unity, but it doesn't meet the constraints that I've set myself. I need something with a decent free software licence, and preferably something that works nicely on Ubuntu. The first engine I started looking into was Panda3D. It's a 3D library for Python, made available under a modified BSD license. However, after a week of messing around with it, I found it clumsy and messy. I also found it difficult to learn. The closest thing I could find to a tutorial are a set of poorly commented sample programs, which I had to manually read through to find what was relevant to what I wanted to do. I grew frustrated quickly and decided to start looking elsewhere.

There are a surprising number of 3D engines out there, but very few work well with Python. Once I broadened my search to include engines for other languages, I had better luck. I eventually settled on OGRE, which is made available under an MIT license, and seems to have a decent set of tutorials available. The advantage of OGRE is that it apparently works quite well with Bullet, an open source physics engine that looks like a good bet.

    6. Conclusion

I'm pretty sure this project will take me a while. It's possibly one of the most ambitious projects I've ever undertaken. That said, I'm hoping that once I get some sort of working prototype, the rest will be easy. I've written this for three reasons. The first is to get my plans down in a coherent form that I can follow. It forces me to iron out the concept, in a way that can be explained simply, and this gives me a solid foundation on which to start developing. Secondly, it makes a commitment that I will do this. It gives me some level of accountability, and hopefully my readers will remind me if I forget about the project (although, that's never really worked in the past). Thirdly, it exposes my idea to much needed criticism. If you have any improvements to the idea, or if you think it's rubbish and I should do something else altogether, please tell me.

If you enjoyed this post, then don't forget to like, tweet, +1, or upvote on reddit. If you have any questions, comments or complaints, post them using the form below.
. . . . . . . . . . . . . . . . . . . . . . . .