Full single player system

[Sepelio]

Looks like Flying Steel got some more of his plotline up:

http://forums.alientrap.local/viewtopic.php?t=5130

Last post.

Oh and as a suggestion, to make co-op more squad based and interesting why not implement the class based mutator for it.

[Flying Steel]

1 - Single player is not a match. The architecture of the current gametypes is for players to fight each other while completing sport-like objectives, while in single player the objective is to advance from point A to point B while fighting characters on the way. The scoreboard for instance displays how many players there are, how many frags you have done, etc. which in SP it would need to be different. The player would have to start the map from the beginning when dieing, not just respawn like nothing happened... and no "You have fragged X" message when you kill a monster. I also don't see health regeneration belonging in single player.

On the contrary, that would make for an incredibly old school, incredibly boring campaign, imo. Moving from point A to B, micro mananaging health packs and tripping over 'monster spawns' and then having to restart the whole damn map when you die, would just be uber dull.

What you want is a mixture of objectives (survival, assault, onslaught) and AI opponents (some monsters, some bots), which change from one level to the next along with game rules (like low gravity here, vampire there and character classes there).

2 - Biggest issue of them all: The current bot system does not allow any gametype to be used as single player. The only way one could poorly simulate a singleplayer map would be an assault map containing one player start for the real player and several other starts only for bots. And since the player is to be all alone against monsters like in most SP stories, the cvar bot_vs_human needs to be settemp-ed for each level too.

Again, having the player alone the entire campaign is extremely outdated and boring. He should have alone levels and squad levels.

Second problem is that bots are spawned randomly so you can't place a certain bot in a certain point on the map, nor can they be given different start weapons, health or skills (eg: a guardian guarding a door with the shotgun and another with the uzi). Imho no map can be truly called single player when bots are spawned randomly and are not individually configurable.

Like I mentioned in one of these threads, we could use a specialized bot spawn system, one that gives you control of the quantity and timing or trigger of spawns in a particular location. That would help alot.

A second bot system would be needed for singleplayer, in which every monster bot is placed as an entity on the map. The normal bots can remain as they are while bots spawned by a monster entity are monster bots which have totally different rules. The entity would have all bot characteristics as keys, such as:

- bot_model - Points to the .zym model of the character to use.
- skin - The skin.
- pants_color
- shirt_color
- name - Name of the bot... can be "Guardian" if it's guarding a gate.
- health - How many hit points this bot is spawned with, separate from a normal player's health cvars.
- damage / skill - Damage overrider, to offset how much damage the bot can do from the current weapon's damage, allowing different bots to be stronger and bosses to be the much powerful then anyone else.
- pickup - If the bot should be allowed to pick up new weapons or health / armor, or if only to use what its given at spawn time.
- weapons - The weapons the bot spawns with, completely separate from g_start_weapon_X cvars which are for players. Would probably default to "laser, shotgun" and one can also empty it to leave a bot unarmed by default.
- respawn - How many times the bot may respawn. If 0 the bot is dead forever once its killed, and higher numbers would be how many times the bot respawns after death (one can set it to 10 to have to defeat 10 soldiers in a room). -1 would be an infinite spawner.
- team - If the bot is an ally or enemy of the player.
- follow - In case the bot is not an enemy, it follows the player everywhere after the player approaches it. eg: freeing a prisoner who then follows you everywhere and helps you.

No, we should use the character class system for bots, as well as the player on alot of levels. We shouldn't duplicate code work.

There could probably be more, such as monster bots dropping special items upon death. Bot entities could also trigger events once all bot spawns are defeated, such as defeating a guard for a door to open. Another crucial possibility would be virtual teams, the player belonging to team 1 so a bot can be either an ally if team 1 too, or if not be an enemy to you and other bots who are from different teams.

What would be the difference between one team and two teams on the same side though?

b]3 -[/b] A feature which is always good in single player is a dialogue system. When the player approaches a bot which is not an enemy, he could press an action key and a message is printed on the screen. Dialogues could contain whole discussions of the form "me: clicked the bot - bot: answering! - me: answering back" (like in old console games ). A further addon could be players given many choices of answers (such as yes or no) in dialogues, each answer triggering a different event.

That could be helpful, but as long as we have somekind of "cutscene" even if it is just text to start with, we can advance the plot. One thing that would be useful though is to have custom audio/message triggers, so that when the player reaches a certain point or something happens in the level, it triggers a text message and an audio clip.

4 - A single player system almost always has the ability to load another map when reaching a certain point in the current map, while keeping all of your weapons and other items you are carrying through. Such a system would also need to include a save game ability, save and load anywhere. The system in the classic Unreal is a perfect example of what I mean. This can be replaced by the current campaign system, but a system to freely travel back and forth between maps with savegame ability included would be much better.

Checkpoints that just saved your progress through the level would work well enough too, if that is less work.

I know that's an annoying list of big features and all, but I wanted to say my 2 cents and hear what others think of this. Since I player the old Unreal I've been thinking about writing my own game stories in a system which would correctly allow going through maps and facing configured enemies in each point. I shall try to see if I can start by copying a current gametype into something else, then if I can create entities that can spawn monster bots. But yeah... is this possible to do, and is it wanted by other players as well?

Some new features specialized for a campaign mode would be very helpful, but must be mixed with gametypes, mutators and features of the wider game to mix things up from what would otherwise just be a late '90s era slogfest campaign.

Specifically:

1) Cutscenes or textscenes and triggered in-game special audio clips to advance the story.

2) Quantity limitable, triggered bot spawns.

3) A checkpoint or more advanced in-level save system.

[Flying Steel]

Oh and as a suggestion, to make co-op more squad based and interesting why not implement the class based mutator for it.

BTW, I am building the 3D character models that will fit that purpose. 12 planned, 3 started. Squad based combat and character classes I have been planning to use use on many levels spread throughout the campaign.

[MirceaKitsune]

I agree with Flying Steel, but maybe it would be best if these were a choice on each map (eg: if dieing in that level means you start from the beginning, how many player teams there are). Some like the oldskool way where the player is all alone fighting monsters and finishes when reaching the last map... I think it would be fair to support all ways if possible. That would also allow squad levels then alone levels like you said

Domination has dom_team for specifying such properties... maybe single player could have sp_team where one could choose how many teams there are, if players start all over again when they die, if to use a scoreboard, etc. That would allow any style of story to be created.

In any case I think monster bots would be the base characters one would face on such map, but as you said by using entities that spawn configured bots in each spot (what I meant by a "second bot system", more correct would be a second bot -spawning- system but without showing monsters on the scoreboard imo). Checkpoints would be great, probably even better then savegames if they would work.

[Vordreller]

I'm all for it.

[Flying Steel]

I agree with Flying Steel, but maybe it would be best if these were a choice on each map (eg: if dieing in that level means you start from the beginning, how many player teams there are). Some like the oldskool way where the player is all alone fighting monsters and finishes when reaching the last map... I think it would be fair to support all ways if possible. That would also allow squad levels then alone levels like you said

Domination has dom_team for specifying such properties... maybe single player could have sp_team where one could choose how many teams there are, if players start all over again when they die, if to use a scoreboard, etc. That would allow any style of story to be created.

Yeah.

In any case I think monster bots would be the base characters one would face on such map, but as you said by using entities that spawn configured bots in each spot (what I meant by a "second bot system", more correct would be a second bot -spawning- system but without showing monsters on the scoreboard imo).

Yes that's a good catch, the scoreboard should not show any other stats beyond the player's. It could also show the level objective(s) instead, that would be very helpful.

Checkpoints would be great, probably even better then savegames if they would work

Either would be enough.

Checkpoints could be simpler to implement, if they were just a counter much like the level counter Nexuiz currently uses for its campaign. This tracks only the last checkpoint the player triggered, not how much armor and ammo he has and all of those details, instead each checkpoint defines those things.

A full intra-level savegame feature that stores all that information could be good to have, but also could require alot more code work to implement, I think.

[h3dge]

Things to keep in mind for Single Player:

1. Scripted Events - An event system is probably needed to trigger scripted actions that are used to tell stories (earthquakes, destruction of items, Flybys of Jets, etc). You want certain things to happen at certain times...

2. Obviously a beginning and an ending to a level

3. How to handle death (checkpoints, starting level over, etc)

4. Cut Scenes (either through playing video, or In-Engine)

5. Enemy models that are larger or smaller than player models - this is actually a subtle change, but would make a big impact. We are all used to seeing models roughly the same size...imagine walking in on a 3 story tall mech or swarms of beetles.

6. Doors, Elevators, Vehicles, movements other than walking. This adds variety to gameplay

7. Enemies focus on tactics, cover, working with other enemies - instead of twitch response and running in guns blazing...

8. Enemies have distinctly different strategies - some are distance fighters, others do melee damage, others use stealth, etc....a variety in the way you are attacked....

9. Weapons distribution - typically you start out with weaker weapons an slowly acquire larger ones.

10. Weapons are designed around enemy weaknesses - certain weapons work better with certain enemies

I'm sure there are many more....

A single player game type that would work well with Nexuiz and would be easier to implement quickly would be something similar to Serious Sam. SS has various closed arenas which spawn huge amounts of enemies that you must survive. Once you clear a certain space, a door opens and you move on to the next arena. Co-op works well with this type of game, and you can build suspense by starting with smaller arenas and working your way up to larger ones. SS is also a *great* example of how enemies with different attack movements add variety - there are the bombers that run right at you and self destruct, the galloping skeletons that leap, turn, then leap again, the frogs that move in swarms, the bulls that run very fast but can't turn very well, the massive Mechs, and the simple soldiers. None of the AI for these is very complex, but add them all together in different combinations and it results in some fantastic gameplay....

[Sepelio]

All good points h3dge. Nice first post.

[MirceaKitsune]

Indeed, +1 h3dge

As for the cutscene system, best would be an in-engine one imo. It would likely be both easier to implement and to work with. Recording a video to play when reaching a point in the map would be a lot of work for the mapper, and modifying something in the map would require the video to be remade as well. Just snapping the camera in another spot as bots walk through or a door opens would be perfect I think.

Some of these events already work with current triggers, but SP would need more. Another type of trigger I was planning to bring up on the dev tracker is a cvar changing trigger, which would be useful for both SP and the current gametypes in Nexuiz. When someone touches that trigger, a server cvar can be changed to another value. That can do a lot... gravity triggers, enabling / disabling some mutators from switches...

[Flying Steel]

As for the cutscene system, best would be an in-engine one imo. It would likely be both easier to implement and to work with. Recording a video to play when reaching a point in the map would be a lot of work for the mapper, and modifying something in the map would require the video to be remade as well. Just snapping the camera in another spot as bots walk through or a door opens would be perfect I think.

The limitation of that method is you don't have very interesting camera control or character animations unless you add alot of support for them. When you use pre-rendered cutscenes, all techniques available in the content creator are available for use in cutscenes, because they are ultimately exported as simple raster images in the end anyway.

Not saying this is a better way to go though, just filling out the pros and cons.

(BTW, I believe UFO:AI is based on the Quake engine like Nexuiz is and it recently added somekind of cutscene support)

Some of these events already work with current triggers, but SP would need more. Another type of trigger I was planning to bring up on the dev tracker is a cvar changing trigger, which would be useful for both SP and the current gametypes in Nexuiz. When someone touches that trigger, a server cvar can be changed to another value. That can do a lot... gravity triggers, enabling / disabling some mutators from switches...

There's definitely some interesting things that could be done with that.

When you say triggers, that includes timed triggers too right?