1) Different scenarios have different rules. This makes the game world less coherent and "real" than it could be.
2) Some scenarios create an unlimited amount of short-lived Clonks. This overwhelms the memory of the player and makes them identify less with the Clonks than they could with a small group of Clonks.
3) Some scenarios immediately revive a "dead" Clonk. This makes the death of that Clonk feel more inconsequential than it feel.
I think we should make the afterlife work like this: When a new Clonk is bought or respawned, the oldest Clonk in the Crew that isn't either currently alive or was the last in the round to die is brought into play. For the typical melee or race with respawn and one Clonk per player, this would result in a two-Clonk-team which takes turns in the game.
What is the current method to respawn the "same" Clonk? How could that be facilitated via a C4Script function or parameter?
>IMO in games with respawns, you should always have the same clonk
I actually did this in most of my CR modifications. The players however didn't like it - "No I want my different names and death messages back". It took something from the crew.
However there's this kind of Skyrace scenario where more than 5 clonks die, and that just spams the crew.
>What is the current method to respawn the "same" Clonk?
GrabObjectInfo in CR, don't know if it still is in OC.
> IMO in games with respawns, you should always have the same clonk while in classic rounds, dead clonks stay dead. Makes sense no?
It might or might not make sense, but it has the problems I mentioned. I think it's better if a Clonk needs to take some time off after a death in a respawn round, and it's better if the mechanics that choose the name of a "new" Clonk work the same in every round. And the latter does in my opinion very much "make more sense" than different rules for different scenarios. Basic suspension of disbelieve: You can make the audience accept pretty much any rules imaginable, but don't break the rules you made up.
0) In "Kill the captain"-scenarios the captain should always be the same clonk with the same name (and picture): The crew leader. This crew leader can be changed in your crew, per default the first clonk ever created. Saves confusion over times and especially for beginners in cases in which the oldest clonk get's beaten in experience.
>2) Some scenarios create an unlimited amount of short-lived Clonks. This overwhelms the memory of the player and makes them identify less with the Clonks than they could with a small group of Clonks.
At first the crew is used up - if all clonks are dead the players must use "mercenaries". These are just clonks, which won't be saved to the players crew files. Temporary crew members if you think about it. But however, playing them won't add to the crews experience!
>3) Some scenarios immediately revive a "dead" Clonk. This makes the death of that Clonk feel more inconsequential than it feel.
In my concept I proposed a sort of menu which appears after a death. You than can select your next clonk from the crew, or if it is used up. The mercenary system also is a kind of punish for dying to often in "unlimited relaunch" scenarios.
Ah and for 1): The same menu will appear if you actually buy a clonk. So buying a clonk or relaunching would actually just be considered as the same thing. A rule could display the kind of relaunch (drop from the sky, revive or what ever).
"Mercenaries" are the same as too much normal Clonks regarding player identification, so can't solve that problem.
a) Do you want a new clonk which won't be saved to your crew? (klick on a mercenary)
b) Do you want to use another Clonk from your crew? Which one - Dunkelstein, your favorite?
c) All crew clonks death? Want to recruite a new one? (which will only appear if all b death, and will take their spaces)
We could even implent the revive option - each clonk which already died gets a timer, and can only be reselected after some specific amount of time. So penalty for dying is there - even in an endless relaunch scenario, but it isn't a big one.
In addition the feature is open to certain extensions for example a captains game feature: Every Player get's to choose the order of his 5 relaunchers, and can choose the specific time at which his captain (which is with the rule activated stronger than other clonks) will fight for him.
If I remember correctly I suggested different rank symbols and names for the mercenaries - so the identification woul be a little bit different.
>Adding a menu to the gameplay just for the Clonkname concentrates far too much attention on that aspect
So you don't want too much identification, but you do want some identification. That's some sort of paradox that will probably produce no solution.
>Forcing a player to make a choice that has no impact on the gameplay is just a bad idea. It does hurt.
This is NOT a principle! That's "just" not true at all.
You may think, that forcing an unnecessary option to the player is a bad idea because it complicates the game or something. But actually if the menu design isn't done too bad the players should get the picture at first sight and will benefit right away.
There is the graphical design in RPG Games - which impact on the gameplay does this have? Exactly none.
It just makes the player identify with his hero. So does a name, an icon, and the control of which hero should fight. And in rpgs this stuff is actually forced, and it prooved to be a very good idea. It's the exact same for clonk.
The crew of the player becomes a part of the game, it will be something the player actually controls. This will automatically boost the identification enourmously AND solve your other problems - and it adds nice possibility (Clonk Skins were mentioned in another Thread as well, or look at the captain talk in my post above).
There is another "false downside" to this at first sight: A menu which will pop up if dead is actually a small slow down gameplay wise. But in practice after death - often sudden death - the player needs a little bit time in which: 1) He can understand that his Clonk is now dead - and the controls he just hammered were not performed. 2) The landscape position has most likely changed, 3) As well as the whole situation - he may have lost the flag and the whole strategy should be changed - running to the battlefield again is rarely the best idea.
There are exceptions to this: Mini scenarios with static landscapes and very very much deaths and respawns for example. This kind of scenario would turn of the menu with an option (scenario.txt) - and it would still be in the sense of the players:
-He wouldn't need his crew in a scenario where every clonk lifes only a few seconds - there would be no identification - so random clonks will do.
-The crew won't get spammed.
>Most good RPGs do not force you to make choices without gameplay effects
>At most it's a name question, which at least has UI consequences that last for hours.
But no gameplay effect.
Every decision about the players' crew will also have at least a noticable UI effect.
Whether I named my character "Link" or "Joki" in the old Zelda GameBoy-games didn't have any effect on the gameplay. But still I wouldn't have wanted to miss that feature
except for that the player really has to concentrate on not getting killed again, so we shouldn't distract them from learning from their mistakes or reassessing the battle situation.
it wouldn't distract them at all, having a death-timer makes the player realise, "OK i made a mistake, what can i do differently NEXT time?" in fact it DOES give them some time to learn from their mistakes and reassessing the battle situation. and and i doubt it will cause enough trauma to make the player want to quit
lets say i have a 'HERO' that i've leveled up, he would cost more when purchasing a clonk, BUT like in the previous clonk-games, he would be able to jump farther, fight better, and all-in-all BE a better clonk then a normal one. i would love the chance to have a 'badass' clonk that i spent a little extra money on, and lots of time leveling up, it would give my countless hours playing OPENCLONK a little more meaning, and i would have something to show for it.
in previous clonks your main clonk was the one you started out with usually, and he was simply better than the rest, the one you have put your time into. and personally i LOVE having a champion. The fact is, once you've leveled him up enough, i'm pretty sure you will have enough battle smarts to know how to use him. and really all you have to do is SAVE before you put his life in jeopardy, and LOAD. thats a typical strategy for people who dont like to wait for respawns.
I do not say that this will happen often. But I am fairly sure that at least once in the lifetime of my (CR) player I had a scenario where I had >50 Clonks at the same time.
So the mechanic we are looking for should also care about that case.
With Guenther's solution you would still find all those Clonks in your Crew. My proposal would be that Clonks below a certain experience threshold are not saved in your Crew.
That would solve the issue that was the reason for why in ClonkRage the scenario developers decided to only use two Clonks in their melees and it would still make the loss of a dear Clonk a tragedy in a "standard" settlement scenario.
That would be the straight-forward method for me to solve this.
> My proposal would be that Clonks below a certain experience threshold are not saved in your Crew.
You're trying to solve something that is not a problem: 50 Clonks in the players crew that are almost never used take up a bit of space and nothing more. The player can and will ignore them without ill effects. Also, you'd introduce a severe problem with the risk of deleting Clonks that the player remembers. That's just not acceptable, and with the threshold high enough to avoid that, it would be mostly ineffective anyway. You could pile on another set of heuristics to work around that, but we have better things to do than maintaining a fragile set of hacks.
>You're trying to solve something that is not a problem:
Well, for me that was the only problem that actually was a problem in Clonk Rage: Spamming your player with Clonks you will most likely never need again.
That I had to play with new, unranked Clonks eventually in long settlement scenarios if I was not careful enough with my starting Clonks, was never a problem for me as the player.
I actually did delete all my unranked Clonks manually at least once. And I was not alone with that problem!
For you the problem is that you play with Clonks that are new to you at some point (and thus do not mean anything special to you) - at least that's what I understood.
But also you say that removing unranked Clonks could delete Clonks the player remembers. That means that playing with unranked Clonks may lead to the player remembering those Clonks and growing fond of them!
Isn't that exactly how you grow and develop a Crew that means something to you?
> That I had to play with new, unranked Clonks eventually in long settlement scenarios if I was not careful enough with my starting Clonks, was never a problem for me as the player.
It's not a serious problem, of course. Just like for example a mediocre landscape texture isn't a problem, but the game is still better with the problem solved.
>But those problems are with the data format of the player file, and should be solved by switching to a sane format.
Well, that's nice then!
>It's not a serious problem, of course. Just like for example a mediocre landscape texture isn't a problem, but the game is still better with the problem solved.
As I said: I don't want to judge your idea about the respawn and say it's bad in itself. However I do not recognize anything else than the spammed playerfile as a real problem.
I really think you should stop seeing your proposal as the solution to a problem, because that implies there is a problem. :)
> Spammed crew
How about an entry "PersistantCrew=1" in the DefCore to prevent "Camera" from joining your crew?
How about we have a more or less arbitrary time limit in there - Clonks can respawn only after being dead for, say, 10 minutes. We could reinforce that by removing the dead Clonk representation (do we have one anyway?) after that time. That would also solve the ridiculous mass graves we sometimes had in CR. Also, you'd have nice "Oh snap, now I have died so much that I have to fall back to my fourth Clonk!" moments.
> So if your second Clonk dies instantly, you still can force a very fast resurrection?
Yeah. But in that case, you have a bigger problem, namely a frustrating scenario design ;-)
I wouldn't call the rule arbitrary, though. In some sense, it changes the penalty box size from infinity to one. Both much less arbitrary numbers than a time limit. But arbitrariness isn't a fatal flaw, it just requires more design work.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill