Kosmous
Joined: 10 Jan 2005 Posts: 44
|
Posted: Mon Mar 07, 2005 4:57 Post subject: |
|
|
been working on my project for years already but only utilized NWNX to its full extent a year ago. I would give u a link to my documentation but its down right now. This is basicly the intro, hope its not too boring to read.
The DDPW (Database-Driven Persistent World) Project was conceived in light of the difficulties that were being encountered by DnD (Dungeons and Dragons) fans who either lacked the required technical knowledge or simply did not have the time to commit massive amounts of time and effort for a Neverwinter Nights module which would take a short two (2) to three (3) hours to play. A means of creating adventures and even entire campaigns within the span of a few hours would be an ideal tool to complement NWN (Neverwinter Nights). The vision was straightforward and simple but the flexibility that NWN allowed would significantly make any streamlining process for the Aurora Toolset extremely difficult.
It eventually became apparent that simple randomization of certain aspects and simplification of the plot line were the common pitfalls of many “dynamic” quest systems that have become available for NWN through free distribution channels like Neverwinter Vault. The requirements of a system that DMs (Dungeon Masters) would actually use sets the bar high in terms of designing a way to convey their creative talents and to allow them to implement such narratives into a coherent implementation through NWN. Such requirements would be listed as follows:
1)Ability to create conversations which are not only branching, but can also garner information from the players (ie Gender, Class, Level) as well as execute a string of simple events (ie Cast a Spell, Give Gold, Create a Creature) without the use of additional NeverWinter Scripts.
This first requirement is fulfilled through the DCE (Dynamic Conversation Editor). As with all my systems, this is entirely dependant on the database (specifically mySQL)… a prerequisite to utilizing all DDPW systems. The DCE also allow for designers to edit conversations at runtime and without editing the actual module, enabling for dynamic changes without restarting the server and without needing direct access to the module file.
2)A method of object manipulation is central to plot-driven events. Manipulation of objects such as the player himself, creatures, placeables, items, area of effects, doors, stores, and area triggers is integral. Objects must be able to change their function based on their specific current use. An example would be a chest that would yield a magical dagger during one quest but would turn into a black dragon in another mission. Different blueprints with different scripts is the standard method for most module builders but a system is needed to allow a more flexible way to assign events and conditions to certain triggers on a specific object without being forced to change the physical module.
This second requirement is fulfilled with the (OTEM) Object Trigger Events Manager which makes objects refer to database entries to determine what event actually occurs. Since a database entry can be dynamically changed at runtime, object events themselves can be easily altered. Take note that area objects were not included in the above list above since the OnExit and OnEnter triggers of an area can be simulated through area trigger events. Also, it is important to note that heartbeats are not used in this system since the OTEM can be extremely expensive on the server when run constantly.
3)A method of “creating” areas temporarily for a single use such as a quest. Areas should not need to be individually created for a specific purpose. Instead, certain parameters must be allowed which will create the current mood and allow for events to occur within such areas.
Area Generation is tricky within the context of the Aurora Toolset. It is impossible to actually generate an area on the fly and then destroy it. Games such as the Diablo series took pride in their area generators which simply randomized certain aspects of the map and placed the end destination (where the objectives were located) at the farthest end. The key to simulating a similar design was not to connect randomized parts into a single cohesive map but to create smaller areas which would then connect dynamically by selecting areas which fall under certain categories. This is done through the Outland Generator which is not only responsible for linking areas together in a cohesive manner but also sets the lighting, music and sounds, and the decorative aspects of the quest areas. The Outland Generator utilizes other subsystems such as mob generators, hostile placeables creator, and the event and task generator.
These are actually the only vital systems that are needed to properly create and simulate a quest with a deep plot. There are other subsystems that need to make all these systems work well together to form a recognizable mission for players to accept and complete, however. With these, a player will be able to become employed through an NPC, travel towards the area of the quest, face danger, complete the job, return to the NPC and finally get the reward he deserves.
The last and probably most important thing to remember when creating such a system is database connectivity. There are two, very important, pieces of software which must be had before going any further. One is the NWNX wrapper program that was created by the Avlis Team, and the other is mySQL. I choose mySQL since it is fast, free, and probably the best database available for a small NWN PW (Persistent World). Although many games, namely MMORPGs (Massive Multiplayer Online Roleplaying Games) like EverQuest are able to edit their game world without interrupting the game play of its customers, such manipulation demands an expert working knowledge of their specific systems. In the perspective of players, as long as the administrators of the game constantly create new content, this is not a concern. However, since this is a project geared towards the needs of DMs and builders, the process of manipulating the game world and the events that are run within its boundaries is integral if they wish to continue providing solid entertainment to their target audience.
Through database connectivity, DMs are fully equipped to create, edit, and delete events such as quests without interrupting game play. It is only logical, as well, that third-party interface must be used to translate the ideas of a DM into organized data which will be stored in the database and then translated to information that the Aurora Engine can understand. Hence, we may say that any work done in the toolset such as the development of Neverwinter Scripts are only as important as the programming done for any of the interface applications. A large quantity of time has been taken by the development of such interfaces and hopefully such programs may exclusively become web-based and done in PHP and JavaScript. This would allow the interface to be always updated and readily available anywhere there is an Internet Connection. As of now, the current available interfaces have been done in Visual Basic 6.0. |
|