Z-Kart discussion

[GooberMan]

I'm going to avoid a design discussion by now (although retelling Doom in the form of a kart race does interest me, like scaliano suggested in the original post). But I will offer tech commentary aside from my kart script. tl;dr - Not only do I program games for a living, but I've also worked on a game with a kart mode in it.

Track definitions
Player starts should basically be irrelevant, and boxed off somewhere. 8 map spots in each map will define actual starting positions. Players will be moved on map enter according to their current ranking. Current ranking on first race will be determined on the kart and cup select screen. All start points must be placed behind the finish line.

The actual track layout will be defined not just by level geometry. A looping path node will be created for each track. Each node must have the forward orientation of the track as its rotation. This path will be treated exactly like a curved camera path. A player's progress in the race will thus be checked with their current position versus the closet point on the spline in between the checkpoints they're currently on.

Shortcuts can be handled either in a similar way, or with a special that resets the player's position once they exit it. I'll think more on that one. Making a custom entity type with custom special parameters would be nice here, but hooking in to editor support for path nodes means you can just see the track flow in Doom Builder for example.

Anyone going off-course will thus be returned to the point on the spline that they're closest to.

Scripting guidelines
Script execution is going to be a killer for performance. Scripts should be as minimalistic as possible. The more event-based you can make your scripts instead of constantly-updating the better. The only ones that *really* need to constantly update every frame are the kart physics and the track position tracker. These scripts will be responsible for firing events at necessary times (say, for example, one player overtakes another which will require an event script to refresh the infinite-time hud message readout showing player positions).

Power ups
Best implemented as a Weapon. Allows complete user control natively. Also handles multiple powerups in one pickup natively.

Homing missiles can be intelligently made by following the track spline.

Boost
Best implemented as a PowerupGiver. Landing on a boost pad will give the player a boost item based on a PowerupGiver. Boost items collected as a power up will do a similar thing on fire - give the owner a boost item.

Kart differences
I can implement kart differences based on power output curves. Each kart will require two curves - one for normal, one for boosted.

Rubber banding
Now this is a big design point actually. At its simplest, the power output curves will be shrunk/expanded depending on your position in the race. But is that desired, or would a proper Doom-style deathmatch with everyone on equal footing be a better idea?

[TehRealSalt]

But is that desired, or would a proper Doom-style deathmatch with everyone on equal footing be a better idea?

Stay with the normal Kart rubber banding. You don't want to give someone who's already winning the best items in the game, or else they'd lose interest as they have no reason to try if they're going to get Lightning Bolts and Bullet Bills (or whatever they're equivalents will be).

[Captain J]

i thought this thread was talking about mario kart, not a twisted metal(even i really like your idea, though.).

[scalliano]

Bloody hell, 5 pages already? I came home from work expecting a handful of replies at best

I'll try and deal with as much as I can here. First up, Gooberman's last post.

First up, I''m very impressed with your POC mod for the physics. Given the issues with slopes, perhaps it might be reasonable to concentrate on Mode7-style (ie flat) track layouts until a workaround is found. That is, provided we can get everything else working.

Track definitions: Path nodes for track layouts were what I had in mind, but I'm no expert on them. The idea I had initially was to have them set up as things that players would collect, like the coronas used in games like Midnight Club or GTAV's editor, only invisible (we're on a circuit, anyway). The problem I foresaw with this method was that there would need to be some way of making them client-side only, so that everyone has their own set to collect, and I'm not even sure that's possible in Zandronum, let alone an SP-focused port. Then again, you clearly have a better understanding than I do!

Power-ups: Bang on the money here.

Boost: Also bang-on.

Kart differences: If this can be implemented/replicated easily, I would say go for it.

Rubberbanding: Despite how much I hate being blue-shelled three times on the last corner after leading the whole race, if characters are class-based (ideal scenario IMO), I'd say this is a necessity. Even if not and players are simply using skins, there would still need to be some form of catchup logic in regards to weapon weights as TehRealSalt said.

Now for the thematic/artistic aspects.

Character-wise, I'm honestly thinking anyone from the idverse that we can fit into a kart, so that would include the Raven and Rogue stuff. There are already complete sets for the Doomguy and Zombieman (Vader made the zombie, no idea who made the Doomguy sprites). so we at least have a base to work off of.

Map-wise, as I said at the top of the thread, I'm thinking IWAD themes, but not restricted to Doom/II/Final. Heretic/Hexen/Strife themes are also welcome, and I wouldn't rule out Wolfenstein or even Quake. However, what I would like to see eventually are maps based off of well-known mods, such as UTnT, Winter's Fury, etc.

And, as impressive as the splitscreen functionality looks, IMO it's a luxury, not a requirement. Let's get the game working first!

All in all, really appreciating the feedback so far. Maybe we can finally make this happen!

[SuperSomariDX]

Decided to screw around and make a quick, dirty and crappy map for just based on my own idea. Doom Center had some vehicles, so I actually had found an older release that worked in GZDoom. Decided to experiment with this and put them in my map.

Pointless Edit (Updated) : Hid some of those giant lines in the map.

---

Beware,this map is a very rough concept of some stupid idea I've had, and since I'm very, very bad with Doom mapping.. Well.. Don't try to judge "too" harshly.. Please.

Load both Doom Center and the map wad, and go to map 2.

Well.. You get the idea. https://drive.google.com/file/d/0B7KVa3rJCvDDTUxVMnhfaDBwbHc/edit?usp=sharing Hid some pointless lines and shiz. Still crappy though.

Stupid Pointless video of it instead, if you have a fear of downloading beginner's maps.

---

[GooberMan]

Someone with a better understanding of ZDoom internals than I have, answer me this please: What is the update order of things? Do players have priority or is it just in thing number order? Also, if a thing executes a script through decorate, is it excited immediately or do scripts all update at once? These are important questions in regards to how the race master will operate.

[edward850]

On order of existence. Player input gets handled first, as that's a separate process, then everything is "thinked" on a first come basis of when it spawned, including the player mobjs. This is all thinkers, so things like lifts are included in this pool.

Player movement->DThinker pool->stuff->player mobj thinker.

Scripts have two rules: If you execute a script, it'll run when the ACSVM runs. If you "execute with result", however, the script runs instantly.

[scalliano]

Zombie sergeant sprites are in the bag. Credit goes to Vader and whoever made the Doomguy ones on the top row.

[SuperSomariDX]

Zombie sergeant sprites are in the bag. Credit goes to Vader and whoever made the Doomguy ones on the top row.

Those are looking quite lovely.

[Average]

I've nothing of use to say other than those sprites and this whole idea is lovely!

[Captain J]

i think we're all hella adorably enough for vanilla doom monsters in a kart!

[GooberMan]

Scripts have two rules: If you execute a script, it'll run when the ACSVM runs. If you "execute with result", however, the script runs instantly.

Alrighty.

The logic for players currently runs through enter scripts, so they'll update first. Especially if I make a race manager thing that calls a script once per frame, I expect that should be put at the end of the execution list after those enter scripts. If you look at the kart scripts, you'll notice I use user variables on things quite a bit which basically makes for an object-oriented environment, so I can quite easily contain all logic to thing user variables instead of script global variables.

In a client/server model I'd let the client work out what place he/she is in the race and do all effects based on that. And then they'll cross the finish line and wait for the server to tell them what place they actually finished in, hidden by a "finished!" effect that makes no mention of place for at least half a second.

But since that client/server distinction isn't in ZDoom... I'll think about it some more anyway.

[edward850]

It's not really necessary in ZDoom to think about it any more then what's already there. The local node already knows everything there is to know about the game, and will always "start" when every other node does. In this situation, they cannot start or end a lap ahead or behind of anyone else. It's not fit for a racing game, sure (as is the rest of the engine ), but trying to change it to how racing games work will surely create more problems and confusion.

Unless you already knew that and I'm confusing your statement with something else.

The logic for players currently runs through enter scripts, so they'll update first. Especially if I make a race manager thing that calls a script once per frame, I expect that should be put at the end of the execution list after those enter scripts. If you look at the kart scripts, you'll notice I use user variables on things quite a bit which basically makes for an object-oriented environment, so I can quite easily contain all logic to thing user variables instead of script global variables.

The execution list is considered undefined behaviour (It can't be adequately predicted). It's based off of the order of the script table, which can be anything each time you compile a script. (Although there is a specific order for Hexen, for compatibility reasons.)

[GooberMan]

Well, mostly I'm just trying to think ahead for the inevitable "Why won't it run on Zandronum?" thing. The more I can anticipate lag in the core design, the easier it will be to run on Zando.

I think an enter script for kart logic in that case won't suffice. A modification to the player class to call the script with result each frame will get what I'm thinking of (and potentially help solve some of your network code issues?). It'll simplify the script slightly to do it that way too.

[edward850]

Nothing sans player movement is predicted at the moment, so no, it wont solve the prediction issue (actually it'll make it worse, because it'll be easier to predict a standalone script then the player frames).
The camera turning issue appears to just be a glitch with how moving cameras work, and is otherwise unrelated to anything presented here.

What will make things easier is if the player is made to be the kart, rather then a separate object.

Basically, I have this list of things todo:

• If possible, improve slope edge detection for any tracks that may want to use them.
• Isolate the player movement script and make it "predictable" in someway to improve movement response with network/dup latency. <-- Requires the player itself to be a kart, rather then a shared object
• Make an internal, configurable third person camera for mods to utilise, that can additionally be predicted if it's the consoleplayer's view point.