Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351347 views, last view: 12/09/2021 06:35

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#796: Re: "pistol" concept

by tentus on 06/06/2005 16:27, refers to #776

looks good to me too. what effect are you planning for it?

perhaps the "pistol" could be like the chaingun, but weaker and with some spread AND random kickback? that'd make it inaccurate enough to incline the player to get a different gun, but it wouldn't leave them totally defenseless. Alternatively, the pistol could be an existing weapon- has anyone considered the Slimeball or Fireball as a weapon? (side note: DCP's turret could make for a really good fire/slime/ice ball turret, it really looks the part).

Also, a short spawn invincibility could be implemented in order to give players a chance to get away from their spawn point. three seconds of directionless dashing has saved me many times from campers.


One final set of questions: if we do make turrets, what should they be like? Would they have their own health? Would they be fully armoured devices that the player is covered in, or more like DCP's turret, which is more of a gun on a stand? What kind of animations would they need? (inactive, active, firing, dead? anything i missed/ should have been more explicit about). Will they be directly based on the current guns or be more unique? Should I be making "broken" models for mappers to use? I've got some idea sketches made up, but i'm not quite sure what to be planning for...

reply to this message

#797: ..

by makkE on 06/06/2005 16:41

I was talking with aardappel about it, and he mentioned a real pistol would be more nice, since the exsisting weapons are _somewhat_ realistic.
So I am working on a pistol now :)

If anyone´s intrested in that gun I posted above (for a mod or whatever) you can have it. It´s just not unwrapped and skinned.

reply to this message

#798: ..

by remouk_ on 06/06/2005 16:45

I was thinking about the pistol when I had a strange idea : a hook (like in some CTF games). With this instead of a simple gun, you won't spawn with the useless weapon you find in many games, and it should be easier to escape campers.

I know it's a bizarre idea and it would change the gameplay too much, but I thought it could be fun. :)

reply to this message

#799: Re: ..

by jean pierre on 06/06/2005 16:50, refers to #797

Dont think about it Makke even i could make it simply by cutting the front of the Rifle

What a lazyness you just cutted the Rifle anybody can do that.

reply to this message

#800: ..

by makkE on 06/06/2005 17:42

This one shows once again, that our dear friend Jean Pierre doesn´t care about reading any posts, just glimpsing at some words, clicking on some link and then making up stupid and arrogant replys.

I think he is seriously starting to piss off people, especially people new to this board.
Sadly he is clicking refresh every 10 seconds...
Please ban him, warnings and explaining things to him, even in language suited for 3-year olds, doesn´t help.

I might be a little subjective at the moment, but he´s just cluttering up almost every important thread with his stupidity.

reply to this message

#801: Re: ..

by jean pierre on 06/06/2005 17:58, refers to #800

Are you working on a pistol anyway?

If so why dont you show us the model(even without textures)

reply to this message

#802: Re: ..

by SirLiveAlot(not at home) on 06/06/2005 18:47, refers to #798

A hook shot though requires more thought when making a map. Ir really changes how the hole game is play. I for one feel it belongs in a mod/specific mode, not in the main game mode.

reply to this message

#803: HookShot

by jean pierre on 06/06/2005 19:03

Genius idea i suggest it should be made in Sauer especially for people who are making Zelda Classic MOD or Metroid MOD using the hook beam that grapple's on GRAB entity.....or all walls but it would make it more interesting if it grabs on the GRAB entiy that looks like a medium box/cube just like super metroid

Good idea Sirlivealot :D

reply to this message

#804: Re: framerate smoothness

by Level52 on 06/06/2005 19:14, refers to #773

Aard:
Sauerbraten fps look perfectly smooth here (Linux, own build) and I sure am picky about smoothness. I might try logging frametimes later.

The collision physics aren't perfect, yet. It's very noticeable in the corridor on the map collisiontest.

You know what I think about the physics, especially gravity... I don't want to insult you or Gilt but I think it's a bad idea to have a friction that affects everything including gravity (nothing against a terminal velocity but this way there are strange side effects).

I (nearly?) don't get sparklies here (GeForce 4600) but on a GeForce MX it was quite bad with obvious Z buffer errors, too. So it seems like the new cards render more accurately.

reply to this message

#805: Re: HookShot

by tentus on 06/06/2005 20:09, refers to #803

as sirlivealot said, a HookShot would be a very difficult item to implement. as the person who did make a Zelda Mod (and if you could retain information Jean you would know that the project has been restructured, at this point LoZ:Cube no longer exists), i did a fair bit of reading trying to figure out how to make one, and the best i could up with was an item that temporarily made a teledest and teleport when it collided with something. In order to make such an item work without destroying gameplay, a lot more code and mapping would have to go into it, mostly by making only cetain surfaces hookable. entities would not be a good solution, because the amount of accuracy needed would increase immensely, and hence undo what remouk_ was trying to accomplish.

that said, an accelorator gun could be more conceivable. point the gun at a surface and anything touching the surface will move/slide around. this could be used to oust your enemies from sniper positions or make your own path easier to tread on. as a fighting weapon it wouldn't be much use, but it could provide some very interesting gameplay.

also, jean, if you would actually look at that screen that makkE put up you would see that is not a simple edit, but there has been some effort there. when you post your "horror mod" or anything of interest at all, i'll listen to you again, but so far that roughshod gun is better than anything you've shown us. please don't post if you don't have something constructive, productive, or deductive to say. (translated into simpler english: don't post unless you're saying something nice, helpful, or intelligent. especially the last one.)

reply to this message

#806: Re: framerate smoothness

by RealNitro on 06/06/2005 20:22, refers to #804

(reply to #804): I did a build of the last release of Sauerbraten today too and tested it with my ATI card. Everything works. Even the ATI bug seems to have disappeared. :-o

reply to this message

#807: Re: HookShot

by jean pierre on 06/06/2005 20:57, refers to #805

OK......Zelda is no longer continued but he can make something else let see.....i leave it to him or some other guys for MOD'S however the hookshot weapon may or may not exist in Sauer as the only hookshot FPS games i know is Metroid prime due to the grapple beam samus gets and i liked it and so for Sauer :P you know to increase the fun :) that only graps to some block's called the GRAB entity's that are shaped as medium sized Cube's.

reply to this message

#808: weapons

by Zer0 on 06/06/2005 22:36

i think, that all weapon and projectiles should be defined via some kind of text file like this:

// weap_name (
// shooting_mode(
// sh_sound;
// ammo_within/on_pickup;
// max_ammo; ammo_per_shoot; reload_time;
// projectiles_per_shoot;
// recoil_vector; spread_angle;
// kick_damage; projectile_name)
// another_s_m(
// ...
// )
// )

weapons
( PUNCH
( primary
('punch.wav'; 1; 1; 0; 250; 1; 0,0,0; 0; 50; none)
)
rifle
( primary
('shoot.wav';10; 100; 1; 800; 0; -10,0,0; 0; 0; rifle_bullet)
)
)

// proj_name
// (flying_sound; explosion_sound;
// lifetime; //in seconds
// type; //can be infinitive ray or partcile
// lauch_vector; //initial speed for particle_sooting weapons only
// spread_angle; //or should it be in weapon description?
// does_it_explode_on_scene_impact; //grenade does not
// accel_vector; //acceleration/gravity vector for ballistic or wired weapons =)
// raydamage; splash_radius; splash_atteuation_func; splash_damage; splash_kick;
// flying_animation; // spawn some particels or someting else
// explosion_animation; // nothing, exlposion or someting else
// spawn_on_impact() // list of particles or another projectiles (nuclear missle with splitting heads =)
// )
projectiles
( rifle_bullet
// flying_sound; explosion_sound;
(;'bullet_hit.wav';
// lifetime; //in seconds
1;
// type;
ray;
// launch_vector;
1,0,0;
// spread_angle;
0.5;
// does_it_explode_on_scene_impact;
yes;
// accel_vector;
0,0,0; // no gravity
// raydamage; splash_radius; splash_atteuation_func; splash_damage; splash_kick;
10;0;none;0;5;


// flying_animation;
particle_line;
// explosion_animation;
none;
spawn_on_impact();
)
)

imho it`ll be easy to describe a lot of of weapons without editing the engine code.

reply to this message

#809: Re: weapons

by Pxtl on 06/06/2005 22:53, refers to #808

Well, there are a few things that would have to change before that happened. For example, currently there is a single ammo box bitmap, and the textures for each box are selected from that bitmap. For a proper system, the ammo boxes each need their own texture. Also, the rocket netcode is very weak. Right now everything happens too fast for the other players to easily dodge a rocket - but if the rocket was slower moving then problems with ping and the fact that rockets appear to be intangible would cause real trouble.

Plus, there needs to be a documentation system built-in. Whenever you have custom weapons, you make it very hard for the user to understand what each gun does. They have to relearn the gameplay each map, and if the guns are not documented, they must do it by trial and error. Now, in games where mods are big conversions, this is not a problem, however on games where little weaponmods are plentiful, the player frequently feels totally lost.

A good easy-to-use doc system for playerrs to have access to in-game (maybe even popping up a weapon-by-weapon readme on arrival of a new weaponpack in-game on-screen, similar to an MOTD) or somethign similar would have to be used for this system to be anything but horribly annoying for players.

reply to this message

#810: Re: Gilt: need some help

by Gilt on 06/07/2005 04:43, refers to #793

yeah I'll look into it. one question: does it matter if the edges around the faces are 'jagged'? or do they all have to combine to create a triangle (or two)?

and on a different note; we need some way of telling what the material a cube volume is, when editing.

reply to this message

#811: Re: Gilt: need some help

by pushplay on 06/07/2005 05:45, refers to #810

Yeah, I was going to ask Eihrul to render clip materials with a translucent colour/texture when I saw him. I was thinking of trying it, but then I remembered that my understanding of opengl is redimentry at best and I should leave it to someone else. :)

reply to this message

#812: brainfart.. sauerbraten models

by Aardappel_ on 06/07/2005 06:54

Here's an idea. When eventually we do things like an RPG, we are going to need potentially tons of models for items and such. This may prove to be a real bottleneck, as good modellers/texture artists are few and far between.

But what if we used Sauerbraten itself for modelling? Maybe it is not ideal for items like a real modelling package, but at least everyone will be familiar with the interface, and we can whip out items quickly this way.

You would edit them at a larger scale, select them, say save_model or something, and it would write it out into a custom format. This format would then be available in parallel to md2 for defining any kind of object.

Since this kind of object we could store in the same octree format as the rest of sauerbraten's geometry, this means that potentially we use the standard physics on it when used as a static mapmodel. This would also save in mapsize, like in roughinery where certain objects are copied in multiple places. Lighting might be harder, it could certainly cast shadows, but making it receive them would be trickier.

It might be better to store it as a mesh instead of octree nodes if it is only to be used for items.

reply to this message

#813: Re: brainfart.. sauerbraten models

by Pxtl on 06/07/2005 07:38, refers to #812

That would be wonderful for items and weapons (which are mostly static objects anyways). I like the idea a lot, because there are always tons of mappers and few modders, and this would provide an excellent convergence.

I'm not sure how it would work for the HUD weapon models though.

reply to this message

#814: Re: brainfart.. sauerbraten models

by Aardappel_ on 06/07/2005 08:51, refers to #813

it's not ideal for everything, that is for sure... but there will always be md2 (and maybe md3) parallel to it.

reply to this message

#815: Textures and models

by remouk_ on 06/07/2005 10:53

Hi,

There's a new opensource FPS called Nexuiz (http://nexuiz.com) which license is GPL (code and content). Maybe you should use its models (weapons, players) and textures for Sauer since they are really nice. I don't know what you think about it, but Cube's models and textures are getting old and I believe it needs more polished ones.

By the way, take a look at Nexuiz, it's a pretty cool FPS too, based on the Darkplaces Quake Engine. ;)

At last, I maybe could help with HUD's and ammo box's graphics if you look for something cartoonish (like in Cube).

reply to this message

   Board Index