yeah if you want new players you have to cater to them. few modern gamers want the classic quake look. with all of the modern texture, models, sounds, etc, a modern looking, yet faithful quake could be put together that satisfies both new school and old school players. if the classic players want classic, include a "classic mode" or something similar.
i'm not knocking one look or another, all i'm saying is if you are trying to sell quake to a modern crowd, you have to cater to their expectations, and sadly old school graphics aren't high on that list. remember, there are many fps's that bring modern, fast paced action. the same can be done for quake if touch ups are done in the right way.
examples:
Xonotic
Urban Terror
Announcement
Collapse
No announcement yet.
proquake *optional* replacement textures support
Collapse
X
-
actually, if we want to make quake appealing to the current generation of fast action players, we'll need to bring the gfx and sound out of the dark ages because even their little nintendo ds probably looks better. check out this article -- Fast paced FPS genre dead? Not so fast! Confessions of a serial game designer. and this -- Fast paced FPS games [Archive] - Steam Users' Forums, both 2012 write ups, this one starts off with:
"What happened? These games actually required skill and were fun."
"Controllers can't handle twitch gaming all that well, thus those fast games were replaced by slower-paced, auto-aim friendly shooters."
i was never a controller player, so didn't know they suck compared to the mouse + kb for fast action.
anyway, i think what truly separates quake from the others like alien arena is the match-based team play vs ffa ? i don't know as i've never tried aa, but the key thing for me is the match and supporting a team to victory -- essentially the same thing that are in most fps games (slow or fast), but those of us here just prefer things a bit faster and not restarting the level after a 2 min round ... but instead keeping the game going.
Leave a comment:
-
interesting info baker. i can tell you that all the guys i play with (myself included) have high end pc's and all the latest games, but still come back to quake -- the standard by which all others are measuredthe "feel" and pace of this engine has never been replicated by any other that just makes for addictive sheer fun gameplay. (others tend to shoot for hyper-realistic gfx and movement that gets boring after a short while.)
there are essentially two types of gamers - those that like fast paced action that tests your reflexes and where practice makes perfect, and those that prefer sit and snipe action or something more docile/slow paced. for instance, i showed a friend of mine -- hardcore black ops player -- a match i was playing and his head was spinning from the pace of the gamequake is for those type of players that first made it famous and there is *always* a current generation of players like this sort of gameplay.
anyway, i hope the momentum continues into 2013 and beyond.
Leave a comment:
-
Originally posted by killingtime187 View Postin addition to "optional" textures, i think all key areas should be optional/pluggable
I just happen to think the Quake engines in general will continue to evolve.
And I swear that 3-4 years ago, I honestly wouldn't have thought that would be the case. Especially the then extremely important Quakesrc.org site died, which was all about engine coding, I thought Quake engine coding was going to die ... especially when aguirRe (who did a once popular and important single player engine) switched from Quake 1 to interest in ... I think it was Quake 2 ...
But the Quake 1 community always seems to surprise.
That in itself is something somewhat fascinating.
Leave a comment:
-
in addition to "optional" textures, i think all key areas should be optional/pluggable -- for instance, i saw 5.1 sound in fteqw ... worked great with my 5.1 setup. anyway, ideally, the engines should able to give the user a feel of the original game with optional enhancements for sound, gfx, input (raw vs orig), etc.
Leave a comment:
-
Originally posted by Baker View PostWell, I'm kinda sorta trying to standardize some things a little. Hit some, miss some. But looks like some of the things I was able to do in 2012 worked out well. Mark V has worked out maybe a bit better than I expected. Engine X ... more work to do (mixed). ProQuake mostly forward, but with a little tuning needed to satisfying everyone.
Its a hit and miss world. I think I leveled up a few notches, which is nice since I used to struggle so much a couple of years back.
Leave a comment:
-
Originally posted by Spike View Postit would take less time if you were not working on all three at the same time...
tbh, three is just greedy.
Its a hit and miss world. I think I leveled up a few notches, which is nice since I used to struggle so much a couple of years back.
Leave a comment:
-
Originally posted by MH View PostConfirmed, yes. The mouse is polled as fast as possible, and client-side view updates happen in real time, but transmission from client to server still only happens at the default 72fps (so as to not flood servers and not generate huge demo files).
Interesting fact - Quake 2 also (kind of) does this - it runs the main event procedure every pass through the game loop, even if a frame would otherwise not run, and responds to (certain) input events as they happen, but will gather them up and update state, send them to the server, etc only if a frame will run.
and YES! the reason I enjoy the uber high fps in netplay is due to the LG / overall aim improvement it offers.
Q1 has come a long way from its roots, even ProQuake is heavily modified compared to our original quake.exe & q95.bat etc :F
Leave a comment:
-
Originally posted by Baker View PostDirectQ as far as I know untied the link between input polling and frames per second. This means DirectQ will poll your mouse the same (like as in fast, fast ...) no matter your frames per second. MH could confirm this, I'm only about 85% certain of this.]
Interesting fact - Quake 2 also (kind of) does this - it runs the main event procedure every pass through the game loop, even if a frame would otherwise not run, and responds to (certain) input events as they happen, but will gather them up and update state, send them to the server, etc only if a frame will run.
Leave a comment:
-
OT but wondering something...
What's the deal with the advertisements showing up in the posts?
Leave a comment:
-
it would take less time if you were not working on all three at the same time...
tbh, three is just greedy.
Leave a comment:
-
Originally posted by killingtime187 View PostGetting back on topic ... I think optional texture support in PQ won't be happening, given your responses. I'll keep playing with different settings and see how input is affected on various clients and possibly post my findings here.
Thanks for all the feedback.
All 3 engines have vast amounts of similar features (demo rewind, loc support, etc., ping is scoreboard) and I've been trying to bring them together into a single project where only the rendering is different. Mark V was an effort to add clean implementations bug fixes and conveniences in other engines, which resulted in a lot of ProQuake features getting rewritten from the ground up (one example, the ping in scoreboard in Mark V isn't from ProQuake, more of a result of looking at what DarkPlaces and ProQuake did and writing a short and crisp implementation).
It just takes a lot of time to get there ....
Leave a comment:
-
Hi Baker -
Got it. That makes sense since the input definitely feels different in the other clients mentioned, but ... it doesn't translate into ideal gameplay on netquake servers -- probably rocks on quakeworld and dp servers. Yes, I also think that DirectQ does a lot of things differently and possibly more efficiently.
An update to what I've been able to find so far ... I have decided to go back to the lowest setting and work from there upwards. As a result, I've dropped my mouse polling back down to 125hz and set my dpi to the lowest possible value on this mouse -- 800. I have maxfps at 500 and vsync off (tried vsync on and my system did not like it all ... it was unplayable). This seems to be working well so far. I think the high polling rate, dpi and other advanced mouse options are for games that really tax both the gpu and cpu's -- i.e. modern games like crysis etc. For netquake on the other hand, it seems that having "more" is actually detrimental to gameplay. This adds up with your statement about PQ's implementation and what you said above and since this is the bar which other netquake clients for tdm is being measured, I think this should be the general approach for netquake configuration -- i.e. leave the high dpi and super polling rates for the other demanding games. Of course, this might even be a personal configuration ... assuming others can get proper responses with netquake clients using the high mouse settings -- i.e. maybe my setup is not right for this.
Getting back on topic ... I think optional texture support in PQ won't be happening, given your responses. I'll keep playing with different settings and see how input is affected on various clients and possibly post my findings here.
Thanks for all the feedback.
Leave a comment:
Leave a comment: