Z-Kart discussion

Archive of the old editing forum
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.

Re: Z-Kart discussion

Postby GooberMan » Fri Jul 04, 2014 9:58 am

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?
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

Re: Z-Kart discussion

Postby TehRealSalt » Fri Jul 04, 2014 11:48 am

GooberMan wrote: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).
User avatar
TehRealSalt
ヽ(◕ᴥ◕)ノ
 
Joined: 03 Apr 2014
Discord: TehRealSalt#6754
Github ID: TehRealSalt
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia (Modern GZDoom)

Re: Z-Kart discussion

Postby Captain J » Fri Jul 04, 2014 12:11 pm

i thought this thread was talking about mario kart, not a twisted metal(even i really like your idea, though.).
User avatar
Captain J
That's Amoreee
 
 
 
Joined: 02 Oct 2012
Location: A Year old Pizza Box
Discord: DiscussJ#3128

Re: Z-Kart discussion

Postby scalliano » Fri Jul 04, 2014 1:09 pm

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

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!
User avatar
scalliano
Socially Distant
 
Joined: 21 Jun 2005
Location: Ireland

Re: Z-Kart discussion

Postby SuperSomariDX » Fri Jul 04, 2014 2:02 pm

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.
Spoiler:


Stupid Pointless video of it instead, if you have a fear of downloading beginner's maps.
Spoiler:
Last edited by SuperSomariDX on Fri Jul 04, 2014 4:34 pm, edited 5 times in total.
User avatar
SuperSomariDX
wonders what the hell is a Horror Monitor.
 
Joined: 01 Jul 2014
Location: Stuck in Illbleed once more.

Re: Z-Kart discussion

Postby GooberMan » Fri Jul 04, 2014 2:49 pm

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.
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

Re: Z-Kart discussion

Postby edward850 » Fri Jul 04, 2014 4:22 pm

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.
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

Re: Z-Kart discussion

Postby scalliano » Fri Jul 04, 2014 5:20 pm

Image

Zombie sergeant sprites are in the bag. Credit goes to Vader and whoever made the Doomguy ones on the top row.
User avatar
scalliano
Socially Distant
 
Joined: 21 Jun 2005
Location: Ireland

Re: Z-Kart discussion

Postby SuperSomariDX » Fri Jul 04, 2014 6:21 pm

scalliano wrote:Image

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.
User avatar
SuperSomariDX
wonders what the hell is a Horror Monitor.
 
Joined: 01 Jul 2014
Location: Stuck in Illbleed once more.

Re: Z-Kart discussion

Postby Average » Fri Jul 04, 2014 7:17 pm

I've nothing of use to say other than those sprites and this whole idea is lovely! :)
User avatar
Average
 
Joined: 20 May 2011

Re: Z-Kart discussion

Postby Captain J » Fri Jul 04, 2014 11:34 pm

i think we're all hella adorably enough for vanilla doom monsters in a kart! :D
User avatar
Captain J
That's Amoreee
 
 
 
Joined: 02 Oct 2012
Location: A Year old Pizza Box
Discord: DiscussJ#3128

Re: Z-Kart discussion

Postby GooberMan » Sat Jul 05, 2014 2:10 am

edward850 wrote: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.
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

Re: Z-Kart discussion

Postby edward850 » Sat Jul 05, 2014 2:25 am

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 :P), 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. :P

GooberMan wrote: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.)
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

Re: Z-Kart discussion

Postby GooberMan » Sat Jul 05, 2014 4:37 am

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.
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

Re: Z-Kart discussion

Postby edward850 » Sat Jul 05, 2014 4:49 am

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. :P

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.
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

PreviousNext

Return to Editing (Archive)

Who is online

Users browsing this forum: No registered users and 5 guests