[plan] A single-player game creation toolkit using the Xonotic framework

This is not about Xonotic, but close enough to fit the development section. It's an idea I've been thinking about for some time, and decided to bring into debate today. It will probably be a while until I get started (likely more than an year) but I plan to make this a reality. Also, I might have previously made a topic similar to this, but since my planned approach changed a lot I guess I'll start this debate anew.

As some might know, I previously suggested support for single player features in Xonotic, to allow making games like Quake, Unreal or whatever using the Xonotic framework. Some parts of my idea would change Xonotic a lot though, and toward a direction that might not be appropriate for an arena FPS. This left me thinking for some time about what and how I should do.

A month ago, I came across a wonderful project for creating 2D RPG games called OHRRPGCE. It's an open-source tool written in Freebasic (previously Qbasic) which lets users create RPG games using nothing but a menu. Scripting is optional, and any game is created by specifying tags, NPC's that trigger other NPC's, etc. This type of development system sparked a new idea in my mind, and I plan to do something similar with Xon. Here's a screenshot from its menu to get an idea:



My plan is to create a single-player creation toolkit from Xonotic, which would allow people to create their own games without having to change and compile any code. The developer would create his maps in netRadiant, placing the appropriate entities to do so. The rest would be configured using cvars. Each game would be contained as a mod (separate data directory) which would consist of the entire game (settings + maps + assets). The engine and 'data' folder would only consist of the game code, and some default textures and models from Xonotic for people to use in their games. There would be no default maps, weapons, game types, etc. When starting xonotic.exe, the user would be presented with a menu list, in which he selects the game he wishes to load.

This might seem impossible at first, but from my experience with QC it can be done by pulling some strings in QC The hardest part would be turning all weapons into cvars, and removing all hard coded guns and attacks. For example, the cvar g_weapon_3_primary_type would have the values "hitscan single" (like the Nex), hitscan burst (like UZI alt fire), hitscan spread (shotgun), "rocket", and "grenade". Additional cvars would specify the 3D model of the projectile, if it bounces, and other settings which are hard coded in current Xonotic. This would allow the creator to make weapons as they wish, name them accordingly, and set all other properties there. All existing gametypes would be removed, and the only multiplayer types would be co-op (players play through the story together) and versus (players fight each other in the mission).

I also plan to add mechanics that Xonotic doesn't (and probably shouldn't) have. One of them is turning everything into items. In Xonotic, walking over a health pickup will immediately increase your health. In my project, you would have to stand close to the health, look it, press the 'use' key to take it, which would only put it in your inventory. You would then select it like a weapon, and press the fire button to consume it and increase your health / armor. The weapon bar would also be customizable, and the player would manually map an item they own to the 0...9 keys on the weapons bar. Overall, I plan to use an inventory system like the one in DeusEx, which looks like this:



I also plan to add skills that the player can level up, and possibly weapon upgrades as well (which would also be items). Hackable computers, a notes system (like the PDA in Doom 3), alarms that will alert enemies, the ability to pick and carry dead bodies, and other features are also on top of the list. The dynamics I have in mind for this are those of games like DeusEx, No One Lives Forever, and other RPG-FPS games which take place in urban environments.

Currently, I'm waiting for most major plans in Xonotic to be completed, and a few other features to be added, before forking a new project which I'd no longer update from Xonotic. One of them are ragdoll deaths for players, which will be a must in my game (same as ODE physical objects, but they're supposedly defaulted since the Sandbox). I also need to keep begging LordHavoc to implement Depth of Field in DarkPlaces

But to sum it up, my plan is to create a SDK from Xonotic, that will allow people to create any genre of story-based games (with RPG capabilities) without any programming. QC would only contain mechanics that can be used and emulated on any game. If this ever happens and will be easy to use and attract enough people, it might lead to the creation of several story-driven games of quality like Doom 3's... since anyone with basic knowledge will be able to make their own story, the only real requirement being to learn NetRadiant.

I'd like to hear what you think of my idea and the way I plan to implement it. If such a system were created, would you use it? Also, would you help in the development of this SDK alongside Xonotic? I know this might seem like forcing QC beyond its capabilities, but I believe it can be managed.

Aren't you worried about performance? I mean, the QC VM is already slow enough, and you're proposing to add another layer by reading a ton of game logic from text files. And this won't have the power of, say, Lua scripting. Devs will have to recompile QC progs or resort to insane map tricks if they want to add simple interactive elements.

Aren't you worried about performance? I mean, the QC VM is already slow enough, and you're proposing to add another layer by reading a ton of game logic from text files. And this won't have the power of, say, Lua scripting. Devs will have to recompile QC progs or resort to insane map tricks if they want to add simple interactive elements.

QC isn't slow for me in Xonotic, and my project would remove anything not used for single-player freeing it more. But if it would be, that's a price it would have to pay. If someone wanted to add interactivity not coded in QC, then they would need a custom game code. But a normal game would normally work with the default mechanics.

I'm likely one of the last people who could integrate LUA in DarkPlaces / QC. But I plan to allow scripting by creating entities which can execute cfg files. This is considered a bit unsafe, so I might need to use a blacklist / whitelist of cvars (since games use their own data dir it's not that bad in this case). So some scripting can exist to some level.

I will back this project with pay-pal and help with art as soon as I know that it's not going to be another one of those projects that just dies.

If you get something going, I will gladly help.

I think this is reasonably possible, the game Tomes of Mephistopheles does approximately, the same things, with the DP engine as well. I'd contribute if my coding skills are up to snuff

Thanks everyone. I'm still very interested in this idea, and often thinking of the cities, maps, and NPC's I'm going to place and make However, Xonotic still doesn't have many features I need for this, as well as some I need to know more about.

Since other people are being interested in this, I made a full list with the most major things I'll need, which I won't be able to do on my own. There are a LOT of features that will be needed, but most of them I can code by myself. Things marked as low priority are trivial for starters and will be added later (but still necessary). Things marked as medium priority are part of the system and will be needed eventually, but we can start without them. Things marked as high priority are all required to even consider the system in alpha stage.

---- Features I'm waiting for in Xonotic (will happen in Xonotic and are officially accepted) ----

Ragdolls (low priority):

I cannot create a modern world centered around story and exploring if dead bodies don't ragdoll. Even if for an arena game with fast movement they can wait, they are obligatory in a world where you want realism and detail. This is even more necessary since I plan to allow carrying dead bodies out of the way so they won't alarm enemies when seeing them. Last I heard divVerent is getting close to implementing this, but I don't know when it will happen.

Xonotic implementation: Because divVerent announced he's working on it, this is also a Xonotic feature.

Physics (low priority):

The ODE physics lib must be included with darkplaces by default. My project cannot exist without physics! It will have a lot of physical map objects (crates, barrels, etc) as well as all items being physical (dropped weapons and also map spawned items). ODE items already exist as a mutator in Xonotic (in one of my branches) and can easily be ported to the main code. I also need to figure a way to have the player walking into an object push it (current Xonotic physics only work when you shoot an object, you can't push by walking into something, must fix!).

Xonotic implementation: Xonotic already uses ODE physics in eg: my sandbox. Eventually the ODE lib will be included, so this is a Xonotic feature as well.

Terminals (medium priority):

I want to have interactive terminals in my game. Last I heard, divVerent is working on a way to add click areas to surfaces (via xml) that can trigger another skin when you touch them, allowing for touchscreen monitors with multiple pages that you can navigate through. I really wanted a web browser on BSP surfaces instead (supporting both local HTML as and online pages) which would be beautiful. You could even put a Youtube page on a map and navigate it by clicking the links with your gun. If you want a good example, here's how this was done in Second Life: Video 1, video 2. I don't need anything this complex of course... just basic interactive screens. It's been officially stated that HTML will not happen also.

Xonotic implementation: divVerent announced he's working on this, and it will be used to view stats and other info while playing (via map-placed screens). So this is a Xonotic feature as well.

---- Things that might be ok for Xonotic as well, depending on how they work and what the devs say ----

NPC's (high priority):

I am undecided how I can / should add NPC's. My first thought was to use bots with bot scripting, but I don't want an NPC to be a real player, which would be a horrible implementation. I heard tZork added this to Xonotic as an entity called zombie. What I need are entities which work exactly like bots but aren't real clients. They roam around, trigger dialogues so you talk to them (I'll make the dialogue entities later on), search for nearby enemies when being alerted by a sound, can be defined as part of a team so they attack other NPC's or the player, etc. Those behaviors are things I can add, but for now I need a basic player entity that can walk / run and shoot weapons. They must NOT use built-in attacks, and only pickup the same weapons as players and fight with them.

Xonotic implementation: The zombie entity already exists in Xonotic, and NPC's might have some use in a FPS arena game. So I imagine this might go in Xonotic to some point.

Level switching with persistence (high priority):

I already coded a trigger_changelevel entity in Xonotic a while ago. But what I'll need is something much more complex than that. Obviously, I will need it to keep all of the player's weapons and inventory between changing levels (as well as health and armor value). But if I wanna have doors that you can go back and forth through, consider this: In level 1 there is an NPC, and a door that goes back and forth to level 2. While on level 1, I kill the NPC. Then I go to level 2 and the map changes. Now I go back to level 1. Without a local persistence, I will find my NPC freshly re-spawned at map start, instead of dead like I left him. Also, what if I pushed a physical (ODE) barrel far away? Will I find it where I left it? A nice trick for this would be using the save / load commands (built into darkplaces) to persist a level exactly as you left it in case you come back.

Xonotic implementation: Level switching already exists. The item persistence part... well this might be useful for some special assault maps. So part might go to Xonotic.

Special new animations (high priority):

You simply can't have a single player environment when players and NPC's can only run and crouch-walk. How is a civillian randomly roaming the street gonna get by then? Or how can you have a NPC sitting on a chair when you enter a restaurant? For this all player models need new animations. Those include: Walking, sitting (on a chair), picking things up from the ground (single player needs an animation when you pickup up dropped items), and optionally things like dancing animations (for NPC's in clubs) and other things.

Xonotic implementation: Partial / undecided. I heard people saying they agree with a walking ability apart from crouching. But Xonotic doesn't need dance animations, pickup animations (maybe?) and the others. At the same time, if they don't increase file size on models too much, it won't harm anyone to have them. So maybe this can be done in Xonotic, even if the code won't use some animations.

---- Features specific to my project (not for Xonotic) ----

Game-persistent bits (high priority):

Let's say that at the first level of my game, I have the choice to kill a NPC or spare him. Later on in the game, I want this choice to influence a dialogue or something that happens next. But that's about 10 maps later. For this I will need a bit system or array which can persist boolean values throughout the game. This can be done by having map entities that read and write global game values. So when the NPC in the first level dies, he triggers a map entity that sets a value called guy_dead to TRUE. Later in the game, I use another entity to see the value of guy_dead and filter the results accordingly. This can probably be done with a global array, using a system of the form (string entry_name, float entry_value).

Xonotic implementation: Xon has no use for something like this, so likely not.

Text-defined items (high priority):

In Xonotic, all items and weapons are hard coded. Weapons are all defined in their own qc files (eg: qcsrc\server\w_electro.qc) as well as items like the health_25. My project aims at being a fully flexible framework which doesn't require editing the code to define items. Therefore, there must be no weapons and items defined in the code, just hooks on how to define your own... no exceptions to this rule. Weapons would then be defined via either text files or cvars, in one of the following forms:

Code:

// cvar implementation, weapon example
item_1_name Shotgun // how the item is called
item_1_model models/weapons/shotgun.md3 // model of the item
item_1_sprite gfx/weapons/shotgun_icon.tga // sprite of the item
item_1_type weapon // is this item a weapon, health, or armor?
item_1_dropable 1 // this item can be dropped
item_1_intenvory_size 1 2 // the size of blocks this item takes in the inventory
item_1_held 1 // this item can be held by the player, and is activated with the fire button (otherwise instant on pickup)

//type specific settings for "weapon":
item_1_primary_type bullet // primary fire spawns a bullet, or a splash projectile?
item_1_primary_pattern spread // fire the bullets spread (shotgun), continuous (machinegun), or what pattern?
item_1_primary_ammo_type shells // which ammo definition to use
item_1_primary_ammo_amount 1 // how much a shot costs
item_1_primary_damage 5 // damage dealt
item_1_primary_force 10 // push force
item_1_primary_model models/weapons/bullet.md3 // projectile model to use
item_1_primary_sound_fire sounds/weapons/shotgun_fire.ogg // sound when firing
item_1_primary_sound_impact sounds/weapons/bullet_impact.ogg // projectile impact sound
item_1_primary_particles_impact smoke // particle to play when the bullet hits a surface
... etc ...

// cvar implementation, item example
item_2_name "Health 25" // how the item is called
item_2_model models/items/health_25.md3 // model of the item
item_2_sprite gfx/items/health_25_icon.tga // sprite of the item
item_2_type item // is this item a weapon, health, or armor?
item_2_dropable // this item can be dropped
item_2_intenvory_size 1 2 // the size of blocks this item takes in the inventory
item_2_held 1 // this item can be held by the player, and is activated with the fire button (otherwise instant on pickup)

//type specific settings for "item":
item_2_primary_type health // does this increase health or armor?
item_2_primary_amount 25 // how much to heal / boost the stat
item_2_primary_sound_fire sounds/item/heal.ogg // sound
... etc ...

The text file example would look the same but in an xml format or something else instead of cvars. Obviously, there would be a LOT more settings for each item than what I wrote above. Also notice how in my example, health is defined to go to inventory when you pick it up. To use it, you would select it like a weapon (and visibly hold it in-hand) then press primary fire to heal. Ammo of course would also be defined the same way. Then in netRadiant, you'd only place an item entity with the definition of your item name to spawn the item there. On the long run, I'd also want vehicles working the same way... but it will probably be a hell of an effort to get the Spiderbot working via hooked text definitions.

Xonotic implementation: This is a feature I want for Xonotic as well, so people can fully configure items and make their own mods that way. But as stated by the developers, I doubt it will happen.

Inventory system (high priority):

In Xonotic, you pickup items by walking over them. When you do, they are added as a bit flag (to self.weapons) and each weapon shows in a hard-coded slot on the weapon bar. This will by far not be the case in the SP framework. All picked up items go to an inventory grid, and the user drags each on a slot of the weapon bar to assign it to a keybind. If you're not familiar with the inventory in DeusEx 1, the one in MineCraft is almost the same, which is what I'm planning to use.

Xonotic implementation: Totally not something I think Xonotic needs and will have.

City & apartment models (low priority):

Although the framework is intended for creating any kind of single-player world (even something like Skyrim) the things I'm intending to use it for are urban missions and the like... where the player will be roaming the streets, entering apartments, and all that stuff. So I'll need models for things like trash cans, chairs, tables, furniture, bathroom / kitchen appliances, and all that. If someone could make some and post them in md3 format, that would be awesome.

Xonotic implementation: Xonotic likely doesn't have what to do with models like this. Though if a custom map will use them, they can be included in its pk3, so they will still serve Xonotic.

---- the end ----

This should conclude the list of major features I can think of right now. Like I said, there are a lot more, but those are the ones I will need help with. If this is done, I can easily add dialogue entities (with both voice and subtitle support), make enemy NPC's have awareness levels and respond to alarms or dead bodies, and what else I need.

If someone wishes to help with making this a reality, you can try to code those features into your own GIT branches. Those that my project needs but are acceptable in Xonotic can be merge-requested after they're ready. Those which are not for the normal Xonotic (just my fork) should be marked as "donotmerge" and their purpose should be clear. Once it's time to fork away from Xonotic, all of them will be merged into master on the new repo. I'm still wondering about the forking and how this should be handled (since some things clearly can't go into Xonotic).

There are more things I'm curious about, but I already made a huge-ass post so I'll end it here for now. Let me know what you think please, I'd like to hear more points!

Will be watching this project, would this sdk be available on mac as well as windows?

Will be watching this project, would this sdk be available on mac as well as windows?

That will depend on the engine. As with my other game (Vore Tournament) I need to rebrand darkplaces and change the game name (using div-stable nightly build). Otherwise the projects would use each other's server lists, the same user data folder, and stuff would break.

In VT I don't rebrand the engine for MAC, because its format is different and there's no way to test it or know what to do. But I rebrand for Windows and Linux. If for this project someone will want a MAC version, either they rebrand it or explain how I do so (I already know how to integrate a darkplaces.opt file in the Linux and Windows engine). For this project I'll likely do it together with other people, so hopefully we'll find a way for the MAC.

---

Ah... and since I realized I didn't link my existing attempt at doing this in Xonotic (a separate thread exists here). Here's a test map I did a while back which shows the atmosphere and system I wanna have in one of my worlds:



When I'll start a real project, the city will be much more detailed (and likely larger) and there will be a lot more interactions. But this was to see how close I could get to such an environment (aimed at exploring and story) and how it looks and feels. I really like what I came up with, and it makes me wonder what might be achieved in the next years.

This. Looks. Awesome.

This. Looks. Awesome.

Thank you... I'm glad that people like this. It encouraged me to work on the New York map again (planned as part of my story once this project will exist). Some images of today's new stuff here.

This is indeed impressive.

As for "Level switching with persistence": I guess one could (ab)use the save/load system for that. You would need to create savegames that are specifc to the map AND the game "session". A simple and stupid scheme perhaps may look like this:

Whenever a new game is started, an unique game "session" identifier is generated (e.g., a random string, whatever). I'd assume this can be stored in a cvar (used to preserve the identifier between map changes) and/or in some entity.

Whenever you switch maps you'd stuffcmd something like "save hub-<sessionid>-<mapname>". When switching back, you'd trigger a load command equivalent to "load hub-<sessionid>-<mapname>" and set the player position to a safe location (func_player_aftermapchange, whatever) that is closest to the last saved position (which would be in a map-change trigger, thus the repositioning).

Obviously that'd also re-load stuff like the inventory, so it perhaps it's necessary to dump this stuff into a text file before loading the savegame and then reading this afterwards to avoid losing your progress. Or whatever.

I think I had this discussion years ago with LordHavoc, and while I for sure forgot many important things, he for sure would know what would have to be done...

@ SavageX: For a default persistence, I'll need to do exactly what you suggested. I remember DeusEx doing something similar now that I think about it (when changing levels it would save a copy of the modified map then rename the save file into a map file). It's the best way to persist the position and state of every entity without having to write a ton of useless info to text files, and should certainly be used. I can write the code which executes a 'save' and 'load' command on each map change, using a file name of the format strcat("persistence_", map_name, "_", game_uuid); Only bad thing is that this still uses the data\saves directory, which should only be used for actual saves and not persistence (dunno if darkplaces allows overriding this and saving to data\maps instead).

Anyway, this alone will not suffice! Whenever you'd go back, it would simply restore the map as you left it, losing any progress you made in the map you were visiting. You still have to apply your changes at each map load (updated inventory, changes in mission and choices, etc). But it's better to apply them over the state in which you left the map rather than starting the map anew and applying on that... since again you maintain a lot more this way (like the position of physical objects and where each NPC walked). So both things will have to be done.

Another thing I missed: The same map could have multiple entrances / exits leading to other maps. Each trigger_changelevel will need the ability to specify a player starting point on the other map, instead of just loading the map blindly and letting the player spawn where he will. So if map1 has two doors, one leading to map2 and the other to map3, returning to map1 from map2 should place you in front of its door, while returning from map3 to map1 must place you in front of the door that took you to map1. Best way is to give the trigger_changelevel a target and the info_player_deathmatch a targetname, then have the map switching code persist the target string and after map change scan the player starts with that targetname.

@MirceaKitsune:

Yes,the problem with losing your progress (inventory, quests etc.) is why I assume you may have to dump some fields of the player entity (assuming that's where this stuff is tracked) into a temporary text file (or code things into a string that is temporarily stored in a non-permanent cvar) before map change and parse things back.

I would assume that the menuqc could filter out any save games with your "persistence_" prefix?

@ SavageX: Sure. But I remember hearing about a field in QC which is passed between map changes (IIRC if you use the 'changelevel' command and not the 'map' command). I made a note somewhere that this is called spawnparms, but don't know any more. Quake persists stuff between map changes, and Darkplaces still runs Quake 1, meaning the feature still exists and only needs to be implemented in the game code.

It will have to persist multiple players also. The framework will allow multiplayer as either co-op (players work together through the story) or against (players fight each other to complete each level, either free for all or in teams). Yes, this will have the disadvantage that one player changing level will change the map for everyone, but it's better than no multiplayer support. Anyway, this means it can't be done via cvar, since each player will have their own inventory which needs to be persisted, and you'd need a cvar of the format "persistence_playername_item" which would be very messy (a text file can do the trick at worst).

Ah, I totally wasn't aware that there is a mechanism to pass QC fields between map changes. Obviously that'd be better than dumping stuff and parsing it later on. Who knows, perhaps you can encapsulate all information on progress in one entity and pass that along.

Just a heads-up. I made some major updates to the city map in the last days, and posted a new video and more screenshots in its thread. The latest map is also available on GIT for those who wish to try it. I'm linking this here as well since I'm hoping it will motivate more developers to help with this project eventually (I'll be using that city but until single-player abilities exist it will be just a useless demo).

This has some real potential by the looks of the video you posted, I'll be keeping an eye on this

There's something I've been thinking about in the last hours. I'm pondering whether or not I might be able to add those features without forking away from Xonotic. In other words, if all of the changes proposed here might be accepted in Xonotic master, some of them as mutators... without harming Xon or turning it into something it's not. Obviously this would be a set of major changes, but if they're good I don't think they should be scary.

One reason I was thinking of forking is that Xonotic is an arena fighting game... with a fixed culture, weapon set, etc. Although balance can be changed, Xonotic is not a SDK. Making it usable for full single player might change this. From being a specific game only, Xonotic could partly become a framework for creating arena and single-player games alike. Features like the text-defined weapons would make it possible for anyone to create their own game from Xonotic without code changes... which was one of my project's main purposes (a toolkit for building and running games, not just another game).

It wouldn't change the existing Xonotic of course... just open its borders to new possibilities and purposes. It would not change the weapons, balance, and artistic direction it has now... since the "arena FPS" part would stay exactly as it is. However, it's possible that all those things could become "the default game Xonotic is distributed with", while the code and configuration might become a reusable resource for whole new "Xonotics". Again, I believe this would be a beautiful change, and could even be a small revolution in open-source gaming.

Second problem with implementing my ideas in Xonotic are the features I want in my toolkit. I listed the main ones above. Some of them are pretty susceptible for an arena FPS... like the inventory system similar to MineCraft / DeusEx. Of course, they can either be mutators or features that are disabled by default. But as with the other thing, they wouldn't get in the way of the existing Xonotic or change anything that is the way it is right now. But do the devs agree with carrying some strictly single-player features in master?

This toolkit and the games I wanna make are something I've been dreaming to do for many months... especially after being inspired by the OHRRPGCE's idea and architecture. If the important features are rejected, I'll make my toolkit as a separate project. If not, then just adding the features one by one to Xonotic would be best... but I need to know how much the devs agree with this. I prefer not forking because it's easier to stay updated, and most of all this doesn't risk splitting the efforts of the dev team between two projects (assuming someone else would take interest in this SDK and spend time helping with it instead of working in Xonotic).

I already discussed the idea of de-coding all weapons into text files, and turning all projectiles and attacks into hookable functions. divVerent and Samual didn't take it well (mostly because of the effort this would take) but I'll likely discuss it more in-depth inside another topic, since this is a major proposal. Even if I want scripted weapons for my game, they would be a beautiful addition to Xonotic too in my view. Think of the crazy ideas you could make by just editing a text file, like weapons that spawn stuff or trigger cvar aliases and what not. This is one example of a feature that would benefit both Xon as an arena game (because you can highly customize it) and stories using the single player component (since each could have its own weapons).

I'd like a review from the developers about the features listed in the above post. Do you approve those features, or want them modified in a specific way to be accepted? Like I said on IRC, please don't label any as "NEVER" yet... I don't think those ideas are that horrible and can surely be integrated without affecting the existing Xonotic in any way. I'd rather hear suggestions on what to change if something is wrong.

I see no harm in doing it. In fact... DO IT!

This is what I want.

You know, System Shock 2 and Deus Ex both come in at less than 600 megs and they have inventory, useable and combineable items, quest items, modding items in inventory.

It's just image files and a speadsheet or array of items in the world and in the inventory.

Old games did it with images and flat text files.
I'm pretty sure the engine can handle a gui.

I would use it if you built it, I just dl'd xonotic for just that, building SP maps

I'm sure someone must have some basic npc and monster entities
then you need a few simple trigger systems and quest data management

but at least a dozen great games achieved this without more than text and image files.

This certainly seems like it has a lot of potential... I'd love to help out with it!