Saga 2.0

[RenegadeOfPhunk]

Hey guys,

 

My mod is now at the point where objective-style play is the last major thing left to build into it. So, I'm eager to run with the Saga 2.0 spec which was being discussed a while back.

Wudan - I know you started a thread in a different forum, but it appears that forum is no longer active, so I'm re-starting it here. I can't remember exactly what was in that other thread, so if you can remember anything important from that one, please post it in here.

 

First of all, of course, thanks to those who have enabled us to be at this point - Razor Ace, Tchouky Ask and Slunker. (Did I miss anyone out?)

 

I'm planning to dedicate ALL my time from now on to Saga 2.0. It will be my primary focus. I will start afresh from base JKII and create a dedicated Saga 2.0 mod with all the features we decide on. This has been suggested by many people already, and I think it's definetly the best way to go. And then mod makers can merge in this stuff as they like.

I'm willing to do all this stuff myself, although of course, if anybody else wants to help, they are welcome

Wudan, I know your already working on this stuff, but I'm not sure exactly how far you are along. For the moment, I'll assume that were all still specing this thing, unless you let me know otherwise.

 

I definelty see the need for standardising this stuff. I'm willing to discuss the reasons, but NOT in this thread. I would really like to keep this thread clean and easy to read. So please, if you don't see the need to standardise and see it as a pointless venture, then fine, but can I respectfully ask you don't distract the thread by posting that opinion here. (Start another one if you want)

 

Whoever is interested in at least trying to get this done, feel free to contribute...

First, make sure your farmiliar with the current SAGA implementation. If you haven't already, read though this thread first to catch up...

 

Also, I think one specific thing that has not been considered yet is LMS (Last Man Standing) play, which obviously is important for my mod. I think the requirements for LMS objectives and constant re-spawn objectives are sometimes quite different, and I'd like them to be handled in the spec somehow.

As well as proposing some ideas which are specific to LMS play (I'll come to those shortly), assuming we agree to support it, I will also use the LMS code from my mod and incorporate that into the Saga 2.0 open source mod as an option.

In short, I could extract my LMS source code from my mod and put it into the Saga 2.0 mod, so that it will be avalible to all mod makers to take advantage of.

[RenegadeOfPhunk]

OK, now I'd like to try and summarise where I think we are after reading what has been written already in both the first main SAGA thread, and the standardisation thread.

So far, we have a big old set of features which between us, we have come up with as possibilities for this new spec. To me, some seem like basic features which will be wanted by all. However, others seem like features which potentially might not be needed by all mods, and would end up making the spec possibly too big and cumbersome.

Basically, a relatively small-reaching standard will have a better chance of being implemented and used. However, we still want it to have enough scope to be cool to play

 

So what I suggest is that we split our current set of features into 2 STAGES.

Stage 1 features are those we all solidly agree we want in the standard. (Must have...)

Stage 2 features are any which we are undecided on. (Would be nice...)

 

We work on Stage 1 features straight away and leave Stage 2 features till later. Of course we can still discuss things as we go.

Once we complete Stage 1, we re-evaluate our position. We may feel that Stage 1 is good enough as is. We may decide we need just a couple more Stage 2 features to complete the spec. We might even decide to draw the line for Saga 2.0 there, and leave stage 2 stuff for - say - Saga 3.0.

The important point is we don't decide all this yet. We get on with Stage 1 features straight away, get the ball rolling. It will be much easier to make these choices once we have Stage 1 features up and running in front of us.

 

So let me list the features I've heard about so far, and where I personally think they fit into the two stages.

If I have included something in this list which is actually already in Saga 1.0, but I've missed it, apologies. Please feel free to correct me

 

 

STAGE 1:

--------

a. Order of objectives

At the moment, it looks like objectives can be achieved in any order. It should be a possible option to define a set order of objectives. i.e. you have to complete objective 1 before you can attempt to complete objectvive 2.

 

b. Objective 'area'

As soon as a player walks in a specified area of the map, the objective is completed.

I guess keep this to a simple rectangle? Defined by two points. Bottom-left-lower and top-right-upper points? THeir's probably an easier way than that to define an area of a map...

Input from mappers please.

 

c. Escort the VIP

An extension of 1 above.

Basically, it needs to be a specific player (the VIP) which enters the objective area. (Other players produce no result).

We need to decide:

 

a. How the VIP is assigned. (I would suggest randomly)

b. How the VIP is distinguished (I would suggest specific model name - could be packed in with the map, or a standard vanilla JKII model)

c. Whether the VIP's abilities are altered. (I would suggest not altering them.)

 

d. Timed use on fixed objective usable items

The ability to define an amount of time you need to hold the use button down on a particular item for that objective to be completed

This will somehow be represented visually. e.g. timer bar across bottom of screen

 

e. Carryable items

A new item type (like IT_WEAPON, or IT_AMMO - we'd have a new one. e.g. IT_SAGA)

Items could either be placed at specific parts of the map waiting to be picked up, or given to specific player(s) at spawn.

 

This could be an objective on it's own. (You just have to pick up the item), or - most likely I guess - you will need to couple this with another objective.

e.g. take the item to a specific panel and use it for set time, or take it to an objective area and use it for set time (bomb laying etc.)

When a player dies, the item can either be dropped at that point for another team member to pick up, ot if it has a starting point on the map, could go back there. This should be an option I guess.

 

I guess we need to decide if/how the 'carrier' needs to be distinguished. I guess the item model could be attached to the player model in someway? But this could get tricky if we are going to support all possible models, it'll be hard to find places on the model where it won't ever look wierd to attach. Not even sure this is feasible really.

 

Ideas please...

 

f. HUD enhancements

 

I would suggest the following HUD stuff:

 

1. Objective list

-----------------

A small section in a corner which lists all objectives for the map. (Short descriptions).

unfinished objectives would be in red, while completed objectives would be in green with the word 'completed' clearly next to them.

Objectives which can't be completed until others are completed won't be shown at all.

 

Here's an example using a simple two-step objective model. FIrst is to pick up the bomb. THe second is to take the bomb to a specific area and use it for - say - 5 seconds (to plant it).

 

First of all, the objective list would just have 1 entry:

 

1. Pick up bomb <in red>

 

Then, when the bomb is picked up, it would change to:

 

1. pick up bomb - COMPLETED <in green>

2. Plant bomb <in red>

 

If the bomb carrier is killed (or I guess we'd have a button to drop the item manually too), the objective list would go back to:

 

1. Pick up bomb <in red>

 

 

2. Compass

----------

This will probably be right next to the objective list described above. It will point the direction to the currently selected uncompleted objective - and I would suggest also showing the distance from the target too. (Completed objectives can't be selected). It will also be highlighted in the objective list.

(Below the compass could be a more detailed description of the currently selected objective...?)

 

If there is more than one uncompleted objective that could be a target at any one time, there needs to be some mechanism to decide which one is shown.

Nearest objective has been suggested already. However, I would suggest having a 'next objective' button, so that the user can flip between all the possible objectives and then decide for themselves which to go for. We could even have both. (Option for manual select, or always show nearest).

 

 

OK, so to summerise - Stage 1 features so far:

 

a. Order of objectives

b. Objective 'area'

c. Escort the VIP

d. Timed use on fixed objective usable items

e. Carryable items

f. HUD enhancements. (List, compass)

 

Do we all agree AT LEAST the above features need to go in?If so, I can get cracking on them straight away.

How about the kind of implementation I've talked about?

 

 

Here's some other stuff I've seen mentioned which I think should be left for stage 2 (for the moment):

 

LMS considerations (Counter-Strike play)

Forcing team models

 

you will notice that I have left LMS (the important one for me!) in stage 2. This is because, while it's important for my mod, I recognise it may not be important for others. Of course, I hope that by discussing it, we can decide it will eventually get into Saga 2.0 once the Stage 1 stuff has been completed.

I won't get into that just yet though. I want us to agree on stage 1 before we move on to stage 2...

 

Ok guys, let the specifying commence

[Wudan]

I developed a system for updating clients on objective statuses using trap_SendServerCommand and interpretting it on client-side in CG_ServerCommands

 

On server side, I stored objective statuses in level. and in cgs. on client side. I set the Maximum to 16, because each client gets the current objective statuses send on connect, but the system i have could be optimized using bitwise operators to be more efficient, ie just sending a word and then AND (&) that on the client side to tear it down into objective statuses.

 

However, 16 should really be enough.

[Wudan]

Hmm... been thinking about the 32 bit thing i mentioned. I determine status ownership:

 

0 = not completed

1 = completed by team 1

2 = completed by team 2

 

Which I guess puts me back down to 16 objectives per 32 bit word, which is still fine w/ me.

[RenegadeOfPhunk]

I agree - 16 is MORE than enough!

So let's set 16 as the upper limit.

(Personally, I think 4 should be enough for even the biggest, most complex maps...)

 

Are there any points about what I've written above for Stage 1 Wudan? I remember you taking about the UI before...

[RenegadeOfPhunk]

Wudan,

 

Are you talking about common objectives which can be activated by either team? Do these exist in Saga 1.0? If so, I wasn't aware of them.

I thought each objective was only triggerable by one team or the other...?

 

i.e. I thought you were talking about 16 max objectives PER SIDE.

So - 1 16-bit word for each team -> 32 bits used for objectives in total.

[Wudan]

I haven't actually tried to set one up, but you should be able to define an objective as 'bothteams 1'

 

By default, objectives were this way, which could have lead to problems of your own team mates completing opponent objectives, and objectives could have been triggered over and over again.

 

My g_saga.c is a horrible mess ATM but I'll post what I have when I can.

[RenegadeOfPhunk]

You mean the objectives are still split by team, yet EITHER team can activate them?!

 

That sounds like a nasty feature to me. I see too much potential for fustration with either n00bs or deliberate trouble makers on your own team who go around triggering the opponents objectives.

 

Do we really need this option?

I would suggest we take this possibility out completely. I personally don't see what point it serves - except to annoy...

 

If someone was to help explain how it's a good thing though, of course, I could change my mind on it.

(If there were objectives which were TRULY non-team dependent, then I'd see the point. Say you have 5 objectives, and it's basically a race to see who can be the first to trigger most of them. i.e. whoever gets to 3 triggers first for example...)

 

About the code Wudan, no probs. I'll be starting work on it immediately, but I can merge in whatever you have easiely enough when the time comes...

[Wudan]

The option is off by default. Having it as an option gives power to the map-maker, who should be the one who decides what he can do in his map.

[RenegadeOfPhunk]

Well, It's certainly not the end of the world if this option stays in, so I don't want to go on too much about it. If people want it in, then fair enough...

 

but I would still like to hear how it could possibly be a good thing.

If their is no good reason for the option, then the only power your giving to map makers is to make their map slightly worse than other maps as far as i can see.

 

But I could be missing something obvious here. Why would it possibly be a good thing for the rebel team to trigger imperial objectives..?! And vice versa...?

 

Remember, saga 1.0 wasn't finished by the devs. I don't think we should assume every feature in there was actually thought through and tested properly.

or maybe there was extra stuff they were planning to put in which would have given that option some better purpose perhaps?

[Wudan]

Lets say we want to allow the red team to advance forward in position by giving them a better spawnpoint place as a result of completing an objective - but the blue team should be able to capture it and take it back.

 

Red completes objective, they move up

Blue takes objective back, Red moves back

 

Of course, in your scenarios, they die, they are dead for the rest of the round.

[RenegadeOfPhunk]

Ok, now that makes sense

(I'm not just thinking of it in terms of my mod, I am taking into account all mods here...)

 

So, once an imperial objective is triggered by an imperial, it effectively turns into a rebel objective which can be taken back. That fine, I've got no problems with that...

 

Is that definately how it works? Has anyone tried making a map with this option on? What happens if, for example, a Rebel tries to trigger an imperial objective before it has been triggered by an imperial in the first place? Nothing I assume...

 

I'm going to attempt to try it out myself and find out what the deal is...

[razorace]

I don't know. I'm thinking that doing Saga 2.0 isn't worth the effort when it's almost sure to be in JKA as a fully featured gamemode, especially with the dismal lack of support from the public and from mappers when the Saga 1.0 was revealed.

 

I say spend your valuable coding time on improving the core gameplay instead of rehashing what Raven is doing with zillion x times the developer manpower.

[recombinant]

Question: Do bots understand or at least work in Saga?

 

I'm wondering if the Saga map might be an interesting way to simulate SP objectives. If I'm totally off base here, don't hesitate to let me know.

 

Any ideas or thoughts on that?

 

Thanks!

[razorace]

Yep, the bots do understand the objectives. They move towards them to attack/defend them.

[RenegadeOfPhunk]

Ok, I've tried activating the bothteams option, and it does nothing, at least on the anchorhead map.

 

I can see what it's MEANT to do, but I guess the brush on the objectives are set to only take 'use' commands from players on the appropiate team, because execution never gets to the code which is meant to implement this option...

 

I've just checked the original SAGA thread, and this is something that ASk added himself.

...this is starting to make sense now!

 

His idea was to have something like explosives which, say, the imperials needed to trigger, but which the rebels could also trigger 'accidently', thereby giving away that objective to the imperials.

 

I stand by my first statement on this - I don't like this idea. I think it has more potential for noobs and griefers to ruin a game than anything it could add to it.

(Sorry to critisise this feature Ask. I'm assuming you didn't overly ponder over this feature considering the consequenses, so I hope your not too offended...)

 

If we keep this option in, I think it needs to be more along the lines of Wudan's idea, or another constructive option.

 

A word of caution about your idea though Wudan.

A small number of objectives would work fine, but start making maps with lots of objectives, and I could see games going back and forth for a LONG while before any team actually manages to keep all their objectives completed at the same time...

[recombinant]

Yep, the bots do understand the objectives. They move towards them to attack/defend them.

 

Interesting.

 

 

...and this works in the shipping version of JK2, or is it not finished?

 

Are there any saga maps currently available to see this functionality in action?

 

(BTW, Sorry if you've already covered this... guess I've got to get up to speed here!)

[recombinant]

Regarding objectives, would it make sense to break the one common objective into two separate objectives (one per team)?

 

It was just a thought.

 

...and I'll shut up now since I really don't know what I'm talking about.

[RenegadeOfPhunk]

JediStone,

 

It'd probably be best if you ran through this thread first to catch up.

Anchorhead is the only SAGA map as yet. (As far as I know...). I think their is a link to it in that thread.

 

Razor,

 

I will reply to you in ICQ.

I'm not being rude, but like I said, I want to keep this discussion on topic, otherwise this thread is gonna get messy to try and work through for the important points over time...

[recombinant]

...ironically, I was reading through that thread presently to do just that.

[RenegadeOfPhunk]

JediStone,

 

OK man, I probably should have put the link up the top of this thread anyway

 

About your idea of simulating SP type play, I am going to say no overall, mainly because you won't be able to do things like scripted events etc.

 

Imagine a game of Assault in UT, or Counter-Strike - where one side are human and the other side are all bots. I guess that's the nearest you could get to creating a kind-of co-op SP gameplay experience with this system.

 

...maybe this is good enough for what you want to achieve though. Not sure...

 

 

Anyway, I hope to have a working demo of some of the Stage 1 features I've listed in about a month. Meanwhile, I'm going to get people interested in making Saga 2.0 maps...

[Wudan]

AotC:TC has one such Saga map nearring completion, I'll ask Anakin if I can let you see this when it's ready for Saga.

[RenegadeOfPhunk]

That would be VERY handy dude...

AOTC could - of course - incorporate any new stuff I'm adding, so it would directly help your mod...

 

I'm sure you understand this, but be sure that Anakin realises this too

[recombinant]

OK man, I probably should have put the link up the top of this thread anyway

 

No problem. A quick search revealed the topic very quickly (except the one in the mapping section, but razorace had included a link to Slunker's thread in ASk's, so it's all good...).

 

About your idea of simulating SP type play, I am going to say no overall, mainly because you won't be able to do things like scripted events etc.

 

I figured as much, but I'm always looking for workarounds and ways use what's already in the MP game so I don't end up reinventing the wheel when I don't have to. Our MOD, as most people know, is essentially an SP game, but of course we're using JK2MP to drive it.

 

Therefore, if there are ways in which I can cut some corners and use what's already built into JK2MP to simulate some SP features without going the full rewrite method, I'd like to take advantage of it.

 

Imagine a game of Assault in UT, or Counter-Strike - where one side are human and the other side are all bots. I guess that's the nearest you could get to creating a kind-of co-op SP gameplay experience with this system.

 

...maybe this is good enough for what you want to achieve though.

 

It's quite possible that it would work well. What kinds of objectives can we define? According to the Saga Specifications thread, it sounds like you have to have shootable objectives, but can you also have touchable ones (a la capture the flag)?

 

Anyway, I hope to have a working demo of some of the Stage 1 features I've listed in about a month. Meanwhile, I'm going to get people interested in making Saga 2.0 maps...

 

Awesome. Looking forward to it!!!

 

[RenegadeOfPhunk]

Don't quote me on this - I've only just recently started looking into SAGA myself - but so far I have only seen two types of objectives:

 

1. One-use fixed items - such as wall panels.

You walk up to them and hit the use key. This completes the objective.

 

2. Pickup items

As far as I'm aware, this can be set to be any pickable item. (Ammo, shields etc. - a Yamasilari is used specifically in the Anchorhead map...).

As well as getting the normal effect from the item, you also complete an objective.

 

Note, though, that the objective is completed as soon as you pick up the item. So it's not like, say, a flag which you pick up and THEN take somewhere else

This - as far as i'm aware - isn't possible at the moment...

So, I would like to have specific SAGA type items which need to be carried to a particular spot and used - to make things more interesting, as I've mentioned earlier.

 

Have a play around on the Anchorhead map if you haven't already. It'll give you a much better idea of what i'm talking about. Although be warned - it's a big old map. You'll have to spend some time searching around for the objectives... :/

 

Your idea of destroying specific items as an objective is a good one. And shouldn't be too difficult. I'll look into that...