The mod you are trying to view has ceased development and consequently been archived. If you are a member of this mod, can demonstrate that it is being actively developed and will be able to keep this profile up to date with the latest news, images, videos and downloads, please contact us with all details and we will consider its re-activation.

An Open Window is an experimental MOD for Half-Life 2, Episode 2. In this project I will attempt to bring the concept of different realities to life in a realistic scenario. Instead of being another Shooter, AnOpWi centers around the role of the player and his/her experience, emotion and memories. By interacting with the world the player will define his own reality within the story. For this project I chose an open development cycle, which means I will update very frequently and share every step I take in the process of creating this game. Next to the regular media updates, I will also share my thoughts on the different areas of game design in the form of articles. In every article I will also ask for your opinion with the Question of the Day. This MOD also functions as a knowledge base for new and experienced designers.

Report content RSS feed An Open Window: PLD +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.

Posted by on

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?

Post comment Comments
m4x0r
m4x0r

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.

Reply Good karma Bad karma+5 votes
TheSniperFan
TheSniperFan

^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...

Reply Good karma Bad karma+1 vote
Hezus Author
Hezus

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!

Reply Good karma+1 vote
cW#Ravenblood

Well, I dont think that this would be difficult to do :)

Reply Good karma Bad karma+1 vote
Leon_Kilean
Leon_Kilean

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.

Reply Good karma Bad karma+3 votes
SPY-maps
SPY-maps

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

Reply Good karma Bad karma+1 vote
macacos2
macacos2

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.

Reply Good karma Bad karma+1 vote
Sph!nx

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?

Reply Good karma Bad karma+1 vote
Post a comment

You are not logged in, your comment will be anonymous unless you join the community. Or sign in with your social account:

Icon
Half-Life 2: Episode Two
Creator
Hezus
Contact
Send Message
Release date
Mod watch
Start tracking
News
Browse
News
Share
Related Games
Half-Life 2: Episode Two
Half-Life 2: Episode Two First Person Shooter