VERC: Scripting vs. Entities Last edited 2 years ago2022-09-29 07:55:29 UTC

It could be said that a map is an expression of a mapper's creativity: through its architecture and ambience it immerses the player into a created environment. For Half-life, we use editor placed brushes to give the map architectural structure, and editor placed Entities to define the technical points that simulate the interactive details of the world. A map without entities would be lifeless, and certainly no fun.

The debate over scripting and entities revolves around the method for implementing these interactive details. Worldcraft/Hammer, in combination with the Half-Life engine, currently uses physical entities to do this - 'physical' in the sense that each point Entity has a bounding box that the mapper can see, physically move and place within the map, even if it may have no appearance or tangibility in the game itself.

This concept is quite popular, as it appeals strongly to basic senses: people like things that they can see, 'touch', and play around with, and doing so helps bring the whole technicality of making a map down a level. Ease of use is also a commercial issue for game developers. As a rule of thumb, the easier you can make editing for your game without losing functionality, the larger the editing community you can expect to attract. As a game that allows the user to 'Play God' just by tweaking a few properties of some Lego bricks, it isn't much surprise that the Half-Life editing community is one of the biggest. This system also has a high visualisation factor; a mapper can easily gain a visual representation in their mind of how each of the coloured blocks interact, making it less difficult to translate thoughts and logic flow into Entity properties. Less Frustration is a Good Thing™.

As wonderful as this all sounds, the Entity system suffers from strict limitations. While there are some flexible entities (e.g., the multi_managers), the majority of brush and point based entities are designed to serve a single purpose only. In fact, if you want a specific entity for a specific purpose that doesn't already exist, then you will either have to program it yourself into a new mod, or try and fudge something up using a combination of the existing entities. Additionally, inter-entity communication is limited to conventional 'targeting', often without a specific state. Spirit of Half-Life is a fairly recent modification for Half-Life, created for mappers with the intention of overcoming as much of these limitations as possible whilst keeping the existing entity concept. It is no longer actively developed.

As an exact opposite to the Entity implementation, Scripting is probably as close as you would get. The concept of Scripting, for the unfamiliar, involves creating a text-based series of commands, events and declarations to simulate events and ambience in the map, much like a very simplified programming language. Scripting is, in theory, very flexible and overcomes most of the previous hard limitations of Entities. Under a scripting system a mapper is limited only by their imagination and ability to work within the technicalities and functionality of the scripting system.

However, the technicalities of the scripting system is its own weakness. Learning to use another language and abide by a new set of rules is something most people can't be bothered with. With no visual interface or physical presence, scripting relies on logic and conception; if you don't approach it with the correct way of thinking it probably isn't going to agree with you. As a rather biased generalisation, the creative people in our community (i.e. the most interesting mappers) are not good programmers - and the good programmers are not the most creative people. Hence, implementing a scripting system with an appropriate functionality would disrupt the whole mapping process as we know it. It seems to come down to the fact that most people find manipulating purple blocks more intuitive than manipulating text files of commands.

---

On a more personal note, I would argue that the power of scripting is not something to be simply ignored in the face of user friendliness. Would it be possible to design a map development process that was not only dependent upon Entities, but also had the option of Scripting on the side? In fact, for me, this is in concept the perfect solution to this problem: the user friendliness of the Entity system with the option of the additional raw power of a Scripting feature for those who desired it. However, the time and cost restraints in game development mean that implementing such a low-appeal additional feature might proove an overall loss as far as a commercial company is concerned.

With the Real World™ in mind, I set on a slightly different idea. What if I could create some sort of Scripting system that would interface with the existing Entity system, to provide some sort of false scripting support? I tried and got halfway there, before the limitations of the Entity system itself came back to haunt me. For those that may be interested, this solution is simply an application called Bruce that translates a script written in a simple protocol into a bunch of point based entities. This has a number of obvious limitations:

• Scripting can only do what the existing entities do, thereby removing a lot of the power you might have in a proper implementation.
• Physical point entity placement is missing under a scripted system, meaning that the user has to either enter co-ordinates manually (very bad!) or the conversion tool needs to detect and place entities appropriately within the map.
• No inherent editor support.

The tool itself is not finished and only has basic functionality. If you are interested in continuing work or using the sourcecode as a base for something else, it is available here.