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?
Not to belittle your efforts, I like the idea of this series, but no one would do this. A mesh would be 1000x more effective, and easier.
^This
I think you should listen to him, because in the end you might end up with a mod that horribly lacks optimization.
However, it looks quite good...
Totaly agree here. If I had better modeling and animation skills that's the way I would go. I'll probably look into that to improve and expand the sequence later on. Thanks for the comment!
Well, I dont think that this would be difficult to do :)
Yar Im very much into bending the rules, always looking for some neat tricks or ideas to do with the entities or rendering.
Modelling does help alot.. if you have access to that, it makes the possibilities endless. And more efficient.
i too like the bend the mapping rules as much as possible, and in quit some cases i could come up with some quit simple use of door_funcs, parenting stuff, etc to fix stuff that otherwise would require loads of scripting.
but, overall it's clear that mapping isn't anymore the old brushwork building, more and more the use of models is important in to leveldesign. more and more we see games that are build out of models for 99%, only walls, floors and ceilings are brushwork these days. a real shame because i see myself as a real brushmapper so to speak, although i have to admit that models do look much much better as things build out of brushes.
this door above is a great example, in ep2 there is just such a door model that works great as a prop_dynamic, and its therefore much more realistic. still, great tut!!
leon
I try and stick to the original content on the Development Kit until there's no other way around doing something without making it look like crap.
While you are modding to the extreme, you are bound to bend a few rules but when designing a game from scratch you make the rules.
When bending rules, always consider this. Is the outcome worth it? For example, is the door in an important location or will people rush by it? Does it affect other things?