swiss_cheese9797
Newbie
- Joined
- Feb 21, 2005
- Messages
- 304
- Reaction score
- 0
Purpose: To provide Valve with a comprehensive list, constructed by the Half-Life community, of desired features to be changed, omitted or added to the Half-life 3 engine. This will help ensure that the release version of Half-life 3 will approach the ideal, playable, editable, and moddable gaming experience. Here is what I have so far. Let me know what other features you think would improve the next new engine...
A: The HL3 engine
1) No more Binary space partitioning (BSP)
Half-Life and Half-Life 2 were both watersheds in the gaming industry and set the bar high for their rival contemporaries. Both used Binary space partitioning (BSP) in the development of environments, and it served the games well, but clinging to this aging method can only hold back some of the possibilities for the next big HL game. BSP is strong, but not very flexible. Concave geometry is invalid in creating environments with BSP geometry. To successfully incorporate modern high-poly architecture into a BSP enviroment, one must use the cumbersome and limited terrain tool, or craft meshes in another program and convert them into a native format for the game, also cumbersome. Many gamers wait in long-term anticipation for the release of HL3, and it only makes sense to develop a next-gen engine, or use a pre-existing engine that can handle world geometry much, much better than Quake II can.
2) A new radiosity method
While developing on a new, non BSP engine, it would be advisable to develop a new way for lighting, one that is more dynamic and does not take hours of compiling. If, as of 1999, UnrealED's 3d window can show display how lights will look where they are placed, then it makes sense that there is a way to create shadows nearly instantaniously.
3) Boundless map (virtually)
With the inclusion of physics, vehicles, thrusters, and alike, Editors and Modders have been creating high-velocity aircraft and other vehicles. But as any Gmod player can tell you, the size limit of the maps still leave much to be desired. We need to be able to develop maps that extend far, far beyond the tight limits we have now. With the implementation of the two previously listed desired features, this should not be a problem. Imagine what it would be like to experience spacebuild with a boundless map. If the engine requires some kind of limit, it should still be many, many times the size of the current limit.
4) Physics dynamic models
Currently, the dynamic models can be animated, but cannot interact with any physics prop or the world. This is unacceptable. If I want to make a robotic arm that can pick up objects, I should be able to create it from one single dynamic model, and not world geometry.
B: Editing
1) More GUI entity options for output. If I wanna create a GUI ingame, I should be able to bind more keys than WASD and the mouse button. If I'm building an aircraft, if I wanna bind something to the J button, I should be able to do so. (technically I could bind it in console, but it would only work for my setup and would not work for people who downloaded it.)
2) Portal Function (not to be confused with portal gun)
Unreal Tournament (1999) had a static portal function for seamless transitioning between two remote planes. Modders/Editors may find a lot of uses for a scalable portal function. We could even create opposing portal brushes against each skybox wall and create an effect to not unlike flying around the world. Imagine what that could do for space build.
3) Better Particle generation
Many games include flexible, easy to use entities for generating particles. Half-Life 2 does not. Currently, If anyone wants to create a custom particle effect for their map that is more dynamic than an env_shooter, they must do some coding. Unreal has had in-editor custom particle generatrion for years, and I think Half-Life 3 should, too.
A: The HL3 engine
1) No more Binary space partitioning (BSP)
Half-Life and Half-Life 2 were both watersheds in the gaming industry and set the bar high for their rival contemporaries. Both used Binary space partitioning (BSP) in the development of environments, and it served the games well, but clinging to this aging method can only hold back some of the possibilities for the next big HL game. BSP is strong, but not very flexible. Concave geometry is invalid in creating environments with BSP geometry. To successfully incorporate modern high-poly architecture into a BSP enviroment, one must use the cumbersome and limited terrain tool, or craft meshes in another program and convert them into a native format for the game, also cumbersome. Many gamers wait in long-term anticipation for the release of HL3, and it only makes sense to develop a next-gen engine, or use a pre-existing engine that can handle world geometry much, much better than Quake II can.
2) A new radiosity method
While developing on a new, non BSP engine, it would be advisable to develop a new way for lighting, one that is more dynamic and does not take hours of compiling. If, as of 1999, UnrealED's 3d window can show display how lights will look where they are placed, then it makes sense that there is a way to create shadows nearly instantaniously.
3) Boundless map (virtually)
With the inclusion of physics, vehicles, thrusters, and alike, Editors and Modders have been creating high-velocity aircraft and other vehicles. But as any Gmod player can tell you, the size limit of the maps still leave much to be desired. We need to be able to develop maps that extend far, far beyond the tight limits we have now. With the implementation of the two previously listed desired features, this should not be a problem. Imagine what it would be like to experience spacebuild with a boundless map. If the engine requires some kind of limit, it should still be many, many times the size of the current limit.
4) Physics dynamic models
Currently, the dynamic models can be animated, but cannot interact with any physics prop or the world. This is unacceptable. If I want to make a robotic arm that can pick up objects, I should be able to create it from one single dynamic model, and not world geometry.
B: Editing
1) More GUI entity options for output. If I wanna create a GUI ingame, I should be able to bind more keys than WASD and the mouse button. If I'm building an aircraft, if I wanna bind something to the J button, I should be able to do so. (technically I could bind it in console, but it would only work for my setup and would not work for people who downloaded it.)
2) Portal Function (not to be confused with portal gun)
Unreal Tournament (1999) had a static portal function for seamless transitioning between two remote planes. Modders/Editors may find a lot of uses for a scalable portal function. We could even create opposing portal brushes against each skybox wall and create an effect to not unlike flying around the world. Imagine what that could do for space build.
3) Better Particle generation
Many games include flexible, easy to use entities for generating particles. Half-Life 2 does not. Currently, If anyone wants to create a custom particle effect for their map that is more dynamic than an env_shooter, they must do some coding. Unreal has had in-editor custom particle generatrion for years, and I think Half-Life 3 should, too.
