Tuesday, February 27, 2007
I interview quite a few people who’ve been to university and done the courses, and quite likely were good at coding their assigned projects. However once university finishes they stop coding, and start looking for work. What happens is that if you don’t land a job quickly, your skills start to rust over. You can’t remember where the asterisks go, how big the data types are, the standard library functions etc. Sure, if you had google with you, you could work it out pretty quick, but that’s a weak defence in an interview. The longer you go without coding, the harder it becomes to make it past the phone interview.
Here’s a different picture. You have a phone interview or programming test at 2pm, and you just spent the last three weeks working on a 3D game demo. Now you’ll likely remember lots of stuff, you’ll be in a coding frame of mind, and you might even get a demo to show them.
Sounds obvious, but you’d be surprised how many people fall into this trap.
Tuesday, February 20, 2007
Perlin noise is a useful technique to be aware of when making games. It’s useful for creating apparently random ‘noise’, which is restricted to a range of numbers. Some potential uses in games are:
- Make a random looking heightmap of a mountainous area, without going outside certain bounds.
- Create the jagged line for a lightning bolt between two exact points.
- Apply a subtle random wander to the game camera to make it look like the camera is hand held, while still pointing generally at the target.
- Create a tiling plasma texture.
Perlin noise works by starting with a straight line and recursively bisecting it. Each bisection point is shifted some random amount from it’s initial position. Each recursion can specify a different range from the random offset. By varying the level of recursion and the shift range for the different recursion depths, you can get a range of different types of shape.
Actually, the above is just my simple/para-phrased understanding of Perlin. Here’s a better page which really goes into it in depth.
Saturday, February 17, 2007
Tuesday, February 13, 2007
I decided to try and find the cause, and thought I’d document my attempts here, in the hopes of saving the world from upgrading their PC’s. (I’m all about saving the planet.)
Clean Up That Systray
I went through all the icons in my system tray, and uninstalled the ones which I wasn’t really using.
I was running Microsoft Messenger and Skype. I tried using task manager to see how much memory they use. The ‘Mem Usage’ column (‘View->Select Columns’) seems to be the current physical memory, which fluctuates too much to give you a useful number. The ‘VM Size’ seems pretty constant though. Messenger takes 26meg, and Skype takes 15meg. I decided to not start them by default, and install Trillian, and have that start by default instead. Trillian is a small download, works with Messenger, and looks like it might use less memory. That said, I found that it takes about the same as messenger, so it might not be much of a win. Still, I think that not having Skype on by default will save me something. Anyone that I talk to on Skype is also on my messenger list, so I can use Trillian to see if they are online.
I had a look what was in my ‘Programs->Startup’ folder. I had ‘Google Updater, Adobe (Acrobat) Speed Launcher, and Juice (a podcasting program I’ve not really been using). I deleted all of these, as I decided they weren’t generally serving much purpose for me.
Browser startup time was something that I was curious about. I experimented with IE7, Firefox and Opera. I found that they all opened up to my home page in about the same amount of time. The difference in perceived performance was pretty intangible, so I decided to stick with what I’m used to, which is Firefox.
OK, now I’m getting all hardcore and dangerous. I don’t recommend that novices play around with this application.
If you run MSConfig (‘Start->Run->type “msconfig” in the box’), there’s a tab called ‘Startup’ which lists a bunch of executables which run at startup. Looking down this list, I found plenty of things to turn off:
- A version updater for ‘Musicmatch’ (mp3 player), which coincidentally was also causing me problems when shutting down windows.
- “ITunes helper”, something that iTunes can live without.
- “QTTask”, something that QuickTime player can live without.
- A program which my bank gave me.
- A web browser launcher which got installed during my broadband setup.
- A printer software update program. (I’ve had the thing two years, it works fine, and the update never gives me new software. I left the printer spooler though.)
- A program related to my old webcam.
- A program which I accumulated at some point which supports a remote control for my DVD drive. No thanks.
Finally I’ll list a few other things that I like to do occasionally to keep the machine clean.
- Run spyware and anti-virus scans.
- Look through the ‘Add/Remove Programs’ list and delete things I’m not using.
- Delete or move things off the desktop which I’m not using.
- Empty the recycle bin.
So after all this messing about, is my machine much faster? I’d say it’s going mildly faster, but not so much. That said, I do have a nice feeling of cleanliness, knowing that I’ve cleaned up a bunch of stuff.
Wednesday, February 07, 2007
In the last couple of posts I’ve presented the pros and cons of using scripting languages such as LUA and Python in commercial games. To summarize, there are some powerful reasons for and against using them, and you need to think carefully about it before using them.
This time I’m going to present an alternative which is commonly used, but let me say up front that this method also has pros and cons, and I’m not attempting to say that this method is better than scripting languages.
Most games have some kind of editor for building levels. In these editors you shape the environment, and also fill the world with objects of different types. Some types of objects you might place might be, player start position, enemies, crates, trigger volumes, pickups etc. Each object will have some configurable properties. Enemies might have health and strength, crates might have a configurable number of gold coins in, etc.
The alternative to scripting languages comes in by these gameplay objects ‘sending messages’ when different events happen. In the properties for the object, you specify that when ‘X’ happens to the object, send a message called ‘Y’ to object ‘Z’. For instance, on the trigger volume object there might be an ‘on volume entered by player’ event, which could be configured to send a message called ‘Appear’ to another object called ‘Enemy62’.
This simple connecting of objects together using events and messages allows simple scripting of the game, and basically gives simple ‘if…then…’ functionality. There’s a lot of stuff missing though. What about variables, complex conditionals, timers, functions, passing parameters with messages etc? Well, you can tack these on by adding gameplay widgets which perform these goals, and generally follow the same theme of having an point-and-click style of scripting, rather than writing code.
- You don’t have the problem of novice programmers writing bad code.
- You don’t have to use a third party scripting language (i.e. the stepping into someone else’s code problem) or have to write your own complex scripting language interpreter.
- You can tack scripting onto your game using the level editor which you’ll need anyway.
- You’d rarely have performance problems as this method doesn’t give script files which need interpreting, but also due to having a limiting simplicity, the amount of scripting is usually light.
- The power of the scripting ability is pretty limited. Normally you just get simple ‘if…then…’ type operations.
- Just because you’re not giving them a coding language, it doesn’t stop the users from making convoluted scripts.
- Reading how the game scripting works can be much harder, as instead of a single list of instructions, you have a sea of objects, each firing little messages at each other.
- You’ll likely have a similar lack of IDE-like debugging tools for your scripts.
So there we go. Scripting languages – can’t live with them, can’t live without them.
Or something like that…