The controversial "mission mode"...
#1
It seems I never stop flooding this section of the forum with new threads... Well, lets hope this is the last one for now:

It shouldn't come as a surprise I plan to revive the "Demolition Mode" from stage2 (at some point around 0.8.0). But instead of just destroying everything, I plan on adding a specific target to destroy within a time limit in each "Mission". Destroy other stuff gives bonus points together with the time left. Run out of time and you fail.

Targets will be hard to reach (surrounded by walls and buildings in cities, protected by missiles, etc) but the car will be indestructible and equipped with weapons/tools as usual.

Just wanting to spark a discussion about what targets to create, how they will be protected (brainstorm! remember: almost anything is possible with this game engine!). And most important: their names. I plan on using parodies on different companies and similar we all love to hate... Some examples (ideas for their alternative names):

* Crapple
* Bony
* MPIG-LA
* Bullshit Software Alliance
* Micros~1 (need a better name here...)

Maybe pedestrians driven by an AI called "Ed"? That way, we can all run over the "Ed Bot"... Get it? Hmmm... Maybe I'll have him scream "Freetards!!!" if killed...Tongue
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#2
MicroShot? Wink

btw I dunno why it's controversial. Tongue

As for any specifics ... I can't think of anything right now and obviously I can't remember what it was I said on the old board. But maybe there should be a limit to the amount of hits the car can take before it gets considered 'wrecked' (thus failing the mission) or maybe to make it annoying if the car takes a certain amount of damage it gets respawned back at its starting point and has to drive back to the target (wasting valuable time)?
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#3
What about using Time and #Hits on the scoreboard? I don't have much patience for Mission Fails + Forced Restarts, (unless it's something integral like Canabalt) - but I like the idea of multiple fields on scoreboards, as it means all players can participate in the way they want, and there's also more room for competition - e.g. maybe it's really difficult to get all targets without getting hit - but there's a slow & stealthy way to do it?
Reply
#4
All good ideas!

I'll probably try to stick with indestructible cars, but counting hits together with bonus demolitions and time left would be nice for scoreboards.

And respawning on failure seems good (I'm playing with the idea of wormholes). I think one could split the track into several stations/subchapters: failure means respawning at the beginning at the current "chapter". Kinda like portal and halflife: fail and you get immediate retry without having to replay a lot. But also having a time limit causing complete mission failure would really increase the tension at the end, which is always good for boosting the gaming experience and time (but it could be added as an "expert setting" unlocked after completing the track in normal setting: in expert the timer will not get reset on respawn... or you might not even respawn?)

Some hints on my plan:
The tracks will be split into two categories: minions and bosses.
Minions: obvious stuff like shell/umbrella companies like bsa and mpig
Bosses: so far, I got two: crapple and microshot.
The first is probably going to be a spin-off from the last mission in carmageddon2, where you (with a time limit) break into a nuclear facility, destroy generators and open hatches to make you way into the center: a control room with a gigantic red button labeled "THE END" - pushing it sets of a thermonuclear war (or at least the explosives stored in the facility)... What I'm thinking about is the fact jobs said he'd start a "thermonuclear war" again google/android. So I'm thinking: lets interpret it literally: replace the bunker in a desert with a white building in the center of a city: you break in, go down a few stories and set of their storage of nuclear missiles. Wink

The other one is going to be a bit more original: a gigantic skyscraper in the center of a city. Yes... HL2 reference... But here's the idea anyway: it will be divided into several stations/respawnpoints:
1) Arrival: drive through the city and get on to the wall of the skyscraper
Farly easy, one respawn point at the start. Probably some ground-based vehicles and defenses
2) Climb: drive upwards the walls of skyscraper
Will be a _long_ distance to drive. Several respawn points. At this point you will have to avoid missiles from flying defenses, and some mind of intelligent mines moving on the walls (and detaching if you're underneath). Maybe some deathstar-ish cannons?
A little not about the scenery: the city around is going to be quite dark, and the sky will be filled with clouds. Towards the end of the Climb part, the player runs through the thick clouds and get a view of the sun for the first time on the track (yes, idea stolen from Matrix... but it will be beautiful!).
3) Battle: at the top there'll be a gigantic dome, which you break into through some glass window (the whole dome got an array of windows around it, coloured with the 4 well-known colours)
The respawn here will be inside the dome. And the challenge this time will be an AI controlled rollcage car (an ugly ms copy of the real deal) in a classc rc deathmatch (without point counting). I'm thinking the player should be put in a disadvantage here since he/she already got respawn and an indestructible car, and must instead outsmart the AI. The player could pick up turbo boosts while the AI picks up driller missiles. The whole inside of the dome should be accessible (driving on the ceiling and the inside of the windows not yet broken).
My idea is that the player has to trick the AI into following along the wall, firing a driller after the player -which the player avoids- and then get hit by its own missile (which has traveled around the room). This could either be enough (it it proves difficult enough to pull of), or it could lead to one more step: the player is made unable to pick up turbos, and the AI stops firing driller missiles, and uses turbos instead to try to ram the player out of the doom. At this point the player has to go bullfighting and fool the AI to charge right through a window and fall down.
4) Final: don't know what here (what will be the challenge?)... But I'm thinking it has to be something about the player running down through a tunnel/pipe on the inside of the skyscraper down to /or under/ the ground. And there cause the MicroShot Evil Energy Core ™ to overheat...

This could be the perfect point to move to an ending sequence (either animated or actually simulated in realtime). The camera could move out from the city, and obviously the gigantic tower explodes in a chainreaction of explosions (again, a little bit stolen from HL2... but I can't think of any better ending). In fact, the "Mission Mode" could serve as the final game mode in recaged. So this could be combined with a credit list roll. Eventually, I think the final scene (after the credits) could have the camera looking at the ground far away somewhere. The car the player was driving suddenly slams to the ground with broken lights, smoke coming of, and completely burned paintwork. There will be a few seconds silence (the classic hollywood moment of tension), and suddenly you hear the sound of the cars engines starting up, suspension rising and it drives away with the screen fading. Yes, I know I'm a hopeless star-gazer... But I'd like to have something like this for the ending, even if it's a terrible movie cliché.
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#5
... Sounds strangely awesome.


It could also be that if that particular section of the mission (fighting against the AI RC car) has a time limit (let's say the player has only a preset amount of time at that point to defeat the rival, before ... let's say the police or something show up to paste the room with liquid nitrogen (thus making the player's car undrivable, thus making them fail the mission Tongue)) then it could be that since both cars are indestructible then the player could need to hit the AI a number of times before the AI becomes 'angry' and begins to resort to using turbos to slam the player about ... which could probably be the point the player needs to try and bait the AI into using a turbo through a window.

I'm just thinking a little, although it sounds a little scripted (my suggestion, I mean). But, ultimately, this is a long way off so we have plenty of time to test and get this right.


Also I remember I had initially been writing a 'pilot' for the 'plot' of RCX (RollCageX ... will be my side of the game, since I intend to use the LUA-style stuff/raycasted wheels and therefore the emulated, original-style driving/handling characteristics). I don't know if anybody remembers it, although it should still be up on my webhost for download.

We all know that Rollcage started off as an extreme version of illegal street racing; according to Rollcage1, the cars were originally destructible, until one of the racers (Lothar I believe) discovered a way of making them indestructible using kevlar plating. But I digress. My idea was that by RollCageX - set maybe thirty-fifty years ahead of the original Rollcage, then the art of 'RollCaging' (driving these cars) had become an international motorsport (i.e. Formula 1).

What had started out as an adrenaline junkie's wet dream - driving cars at over 300mph through buildings and cities - ultimately became a tamer, international sport dominated by media corporations and advertising. What started as 6 individuals ultimately having some fun, became a group of 8 globally-funded teams pitting their cars against other teams on purpose-built, closed stadium circuits for the amusement of the masses.

And guess what? 'descendants' of the original RollCaging scene - the illegal racers - were sick of it. They had long infiltrated the racing scene under the guise of a legally-funded team - Team Nemesis - and intended to destroy the sport from the inside out, make the world remember what RollCaging really is ...

And the player just happens to be the best racer in the sport, and their first target ... knowing that if they have him on their side, they will be unstoppable.

-dum ... dum ......... DUM.-


So ... this 'story mode' could tie in with the 'mission mode'. The story mode could just be general racing with occasional situational moments (the player having to escape areas, rigged races (I remember talking about one where someone fucks with his jet system so it keeps cutting out on him), whereas the mission mode could be Team RollCage's side of their plot, where the other racers are causing havok around the world on all the big megacorporations like Crapple and Micro$hot who are to blame for RollCage becoming such a tame, everyman sport.


IMAGINATION. WOOOOOO. /football chant.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#6
Of course I remember! And as I've hopefully written before: I love it!

Also, the idea of making the AI angry would be nice:
0) meet the unexpected AI opponent
1) drive around avoiding the AI's drillermissiles
2) manage to get a driller to race around the room, hitting the AI from behind (ok, even I know that sounded dirty...)
3) AI goes into "mad mode" and starts ramming the player
4) player tricks the AI to crash through a window. and enjoys the camera following the car just as it falls out of the dome (in slowmotion, of course)

Also, an idea for respawn when climbing the tower: while falling, a wormhole entrance is automatically launched under the car - it will stop and allow the car to pass through after a few seconds. That way the player is respawned with some initial momentum (the downwards movement will be turned upwards). I mean it'd be hard to attach to the surface from a standstill. Also, I guess the car could have some maneuvering thrusters which turns its nose down and keeps it steady until passsing through the wormhole.
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#7
Or it could just be that a counter counts the distance travelled -up- the building and when the car travels specified intervals up it resets the 'checkpoint' to that height, so when the car falls off it respawns at the last passed 'checkpoint' with a momentum boost (maybe 250-300km/h or so.)

I do remember the Rollcage cars are actually pretty notorious for losing momentum up slopes (one of the scramble tracks comes to mind...) but we can easily bypass that. Wink
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#8
Yeah, just put a powerful jet engine on the carBig Grin

Will probably be using it for normal acceleration as well, to get improved handling...

Oh, I just remembered I have some references for the ideas for the microshaft mission:

The tower: (concept art for hl franchise)

Progressing along tower walls (rc will be 3d, of course): Chromium bsu (I found and tried it some year ago, after expecting the "chromium" package in debian to be a web browser... lol)

Also: I forgot to mention the triPod defense in the Crapple mission? The name should describe both what it is and what the joke will be... Idea nicked from a "scary movie"...


update: "police"? my vision of the future in recaged will be that everything has become extremely corrupt. ms would have their own safety personnel (or simply own the police). Anyway, my idea is that the mission modes will be preemptive strikes: in the crapple track the timer counts down until they start launching nuclear missiles (so you must break in and trigger their own missiles before they are launched), microshaft: I'm not sure yet, but it'll have to do with hypnotizing/killing/enslaving (or a combination or all) through their "Evil Energy Core ™" (so you must cause it to explode before the plan is finished!).
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#9
I've been working on a few illustrative renderings for some future goals for ReCaged. I'm finally done with them (more or less).

So this is the first one, illustrating the final Mission Mode tracks (against Micro-something):

   

It shows my ideas for the intelligent wall-walking "Mines" (which will try to intercept you, so either avoid them or take them out using a driller or chain gun), and "Hunters" (which will follow the car, or overtake and hover in the air a bit further up and constantly aiming/shooting missiles. When they are in front is the only point you can take them down using aimed missiles and drillers).

btw: once I've made the city below slightly more complex, I'll make a higher-resolution render and use it as part of a update homepage (with more transparency and a more stylish black-blue colour theme)
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#10
That Looks Sweet!

It's begging for a mod - "HalfCage" - watch out for falling MineCrabs!

I wonder how bumpy driving would be, if one of those, or something smaller, attached itself to one of the tires?
Reply
#11
There are so many thing I want to say in reply to what you just said...

first of all: the mod. This will be much simpler than you think! I'm going to try to explain the idea of "objects" in another thread, but basically: you can mix and use objects (like tracks and "minecrabs") in any way you want, the player can communicate with any object (either directly by sending messages in a console, or -more commonly- through a "remote control" which reads inputs and transforms them into messages&receives messages and displays info on screen). So there's no need for an all out mod here: just start the interface, start a simulation thread, tell the sim thread to load+spawn the object called "citadel" which is the track, then tell it (sim thread) to load and spawn another object called "floating arm with crowbar", let the interface thread load the "fps" remote controll and tell it to "bind" with the objectid of the floating arm. The rest will go automatically (the mines got their own AI which will guide them to attack some target, which can be instructed to be that specific spawned object (floating arm).

Also, the MineCrabs will be a bit large compared to headcrabs, and explode on impact, but that's not really a problem I think.

Finally... about the wheel attachment: I've been thinking about something similar. Not these mines, but rather a kind of "futuristic" foothold trap for the cars. Think something in the line of: police can't use normal what's-it-called-spikes-that-deflates-wheels and instead spreads, so at police barricades there will be a bunch of foothold traps attaching to the wheels making them bumpy and imbalanced. I originally planed for this to be a weapon for the players, but I think it's more of a comic inconvenience so it'd be better as part of the scenery perhaps? Obviously the traps will take damage for each impact with the ground and eventually fall of.
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#12
Just a (hopefully better) view of just how tall this tower is...

   

I actually had to resize the scene (scale 1:10) just to work around some problems in blender with too large scenes.

And this is just the start. This thing is going to be much taller. Basically the climbing will be a few minutes - lets say 5 minutes. And the car will be driving.... maybe in 300km/h minimum. Which gives 25km in height. I've already been looking at doing something like hl2: render a "background" scene in miniature (with camera position according), reset the depth buffer, and render the "foreground" in normal size. Since I don't think opengl is going to be ok with rendering this as one single chunk (with that far clipping level, there's going to be tons of precision problems with the depth buffer).Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#13
Well we have the 'draw distance' fog. O_o and we don't quite know whether we might need to scale the car models or anything.

Going from what I believe they did in Rollcage/Stage II the cars are maybe 1/3 their actual size so in reality the car might only need to do 100km/h (scales to 300km/h) which would mean the tower would only be ... about 9KM tall. Still tall, and I doubt once GLSL rendering and stuff is implemented that we'd be able to get a decent draw distance beyond 5KM without the game jittering badly. The fact that when driving up the building meaning that only the building itself should be getting rendered might help a little bit (unless the car turns around somehow, but then by then you might be high enough that the ground will be far enough away that it could just be rendered as a flat textured plane.

Dunno. The building would need to be pretty friggin' big anyway what with the planned AI fight on the top of it.

Also that wheel-clamp idea might be a funny weapon, although in regular races it could just last for only a few seconds. Something as simple as making them cosmetic and tilting the car suspension to make the wheel axis off-tangent might be physics-wise more reliable and predictable than physically attaching an object to each wheel.
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#14
The thing is: you can't really draw as for as you want. The choice of close and distant drawing range configures how fragments ("pixels with depth") are projected on the depth buffer. Make this distance too big and there will be a lot of rendering artifacts (but no performance problems, though). The way this was solved in hl2 (which needs to render a similar tower) is to have a miniature world a bit outside the map the player is in and first render that small world (like a 3D version of a skybox - it becomes a background) and then render the actual close scene. If you want to see how it works just get the hl2 demo (if you don't have the game), load the first chapter, wait until you get outside (so you can see the "citadel" tower), enable noclip and fly of. You'll notice the background disappears and somewhere there will be a small "island" of buildings floating, with a much smaller citadel next to it.

My idea (since you need to interact with this gigantic tower) is to just scale the same model of the tower and render it once for background and then again as part of the "foreground" scene (which will be at a normal scale and with more things).

I'm planing to have a concept of "scenes", so a track can set up several scenes to render with different settings (I'm actually not planing to add skyboxes, since you could easily model the entire sky+planet system in 3D and just use that as an interactive background instead!). In fact (now I digress) scenes can include other scenes, and themselves! So you can create portal/wormhole effects with just a few lines of (custom) lua calls.

As for the wheel clamp: No need to make it complicated. I think just adding another geom to the wheel body (like a small box or sphere offsetted to some position on the wheel) should be both easy, reliable and give good performance. And give the wanted annoyance. Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)