An Open Window: Project Launch Day +76
It's been a busy but interesting week. In today's update, I'd like to share some technical aspects of MOD making, from a field which got me into this business in the first place: Mapping. I'll show you how creating something as simple as a garage door, can be tricky without custom code.
I'm getting used to start my articles with a short recap and overview of media coverage. My last article stirred up a few hives and I got many comments from different sources. Thanks for all the comments and PM's on ModDB and a special thanks goes out to Dnst, who posted the article about dynamic environments on a German Half-Life community website. If you know how to read German, be sure to check it out for it raises some interesting points. Podcast 17 covered the topic as well in their last episode. You can listen to the extract below.
As you might have noticed, I'm updating less frequently than before. This has a few reasons but mostly because I'm moving to a different country. As of next week, I will be updating this profile from within Canada! Development will still continue but I'm unsure how much time I'll be able to dedicate to this project once I'm there. However, I can promise you this won't turn into another Duke Nukem Forever or Black Mesa: Source.
On to Source Mapping. Instead of a generic "mapping 101" I'd like to dive right into the technicalities. I've heard a few players ask questions about how certain things work. A common misconception is the idea that everything is directly coded into the map. If you see a gameplay effect or sequence there is no code that tells the game to do exactly that. To put it simple: all code is written into different objects, which mappers call entities. Each entity has a special function. For example, there is a light entity which creates coloured light, a func_button entity which creates an usable button and npc_combine which is a Combine Soldier and there are many more of these.
These entities communicate with eachother through an Input/Output system. That way, I can set up the button send out a command to the light, to turn it off or change its colour. The button can also send the command to kill the Combine soldier. These entities and commands are coded into the game and the mapper can set them up in various ways to achieve a certain sequence, like the video below.
The garage door looks like 1 simple entity but there are actually 40 entities handling this entire event. Each segment of the garage door is a func_rotating_door. These were coded merely to be a door that swings open and cannot move upwards by itself. The motion is actually handled by an invisible func_tracktrain, which drags the door upwards and backwards. However, the train is not able to function without any predefined path_track entity which controls its movement. Because of certain limitations and lack of coded features and commands, each segment needs its own path to function right. The bottom line is: as a mapper you need to know what your entities can and can't do. If you want to create something special that Valve's coders didn't make, you'll need to be creative. If you're interested, check out the tutorial I wrote to create this garage door.
I hope you all enjoyed today's (long) update and demonstration video. The QotD is mostly mapping-related but non-mappers can also take a shot at this one. Thank you for reading and, as always, I hope to see your comments below.
Question of the Day:
If you were a mapper, would you mostly stick to using all original and intended content or would you try to bend the possibilities and create something different?