New Age "Quake" Engines Specs

[dreadlorde]

It depends on what you're trying to achieve. Sometimes the appropriate tool is a database engine, sometimes it's a text file, sometimes is a binary file, sometimes it's something like the Windows Registry, and sometimes it's something else.

I suppose I agree with you there, although I find it hard to believe that windows registry has ever done any good.

My specific example of visible edicts could be well served by a database engine, primarily because they can be freely added to or removed from on a frame-by-frame basis and they need to be sorted on multiple different keys (model type, textures, translucency, distance) for efficient and correct rendering.

You're may be right, I don't know.

Just saying "worse is better" and closing one's mind to the possibilities means that you'll be forever stuck in 1972 here (and with severely limited skills, knowledge and experience to go with it). There are other tools available, and using the most appropriate tool for the job you want to do is what I believe in.

I don't close my mind to anything else, I evaluate whether the added complexity is worth it and choose where to go from there.

[mh]

...I find it hard to believe that windows registry has ever done any good.

Your evaluation of it is obviously based on prejudice, lies and FUD spread by Weenix Loonies and Jargon File readers rather than on any concrete info then. It's fair to say that it's reputation is probably beyond redemption owing to the bad name it's acquired (and - in total fairness - it was a PoS back in the old days) but in the NT world it's a nice stable fast hierarchical database for central storage of settings on a per-user or per-computer basis, the ability to merge admin defined settings over a network (and if you have no experience of Group Policy you really shouldn't be commenting on the Registry at all), flexible storage of multiple well-defined strongly-typed data types and lots of other nice, useful and good stuff.

Also - again in total fairness - I have to confess that I did set you up for that one.

[dreadlorde]

Not really FUD:

Over time, it's fair to say that I've grown to hate the Windows Registry. How do I hate it? Let me count the ways:

The registry is a single point of failure. That's why every single registry editing tip you'll ever find starts with a big fat screaming disclaimer about how you can break your computer with regedit.

The registry is opaque and binary. As much as I dislike the angle bracket tax, at least XML config files are reasonably human-readable, and they allow as many comments as you see fit.

The registry has to be in sync with the filesystem. Delete an application without "uninstalling" it and you're left with stale registry cruft. Or if an app has a poorly written uninstaller. The filesystem is no longer the statement of record-- it has to be kept in sync with the registry somehow. It's a total violation of the DRY principle.

The registry is monolithic. Let's say you wanted to move an application to a different path on your machine, or even to a different machine altogether. Good luck extracting the relevant settings for that one particular application from the giant registry tarball. A given application typically has dozens of settings strewn all over the registry.

http://www.codinghorror.com/blog/2007/0 ... -idea.html

There's articles like this all over the interbutts.

Centralizing configurations makes it difficult to back up and recover individual applications.

Because the Registry structure is contained in files which are not human readable, damage to the system registry may be difficult to repair. Because information required for loading device drivers is stored in the registry,[3] a damaged registry may prevent a Windows system from booting successfully. While damaged configuration files can have the same result to other operating systems, the damage can be more easily repaired by booting to another operating system, and using a text editor.

Installers and uninstallers become more complicated, because application configuration settings cannot be transferred by simply copying the files that comprise the application.

Applications that make use of the registry to store and retrieve their settings are unsuitable for use on portable devices used to carry applications from one system to another.

Since an application's configuration is centralized away from the application itself, it is often not possible to copy installed applications that use the Registry to another computer. This means that software usually has to be reinstalled from original media on a computer upgrade or rebuild, rather than just copying the user and software folder to the new computer.

http://en.wikipedia.org/wiki/Windows_Registry#Criticism

[frag.machine]

Having an embedded relational database would be useful in many situations. Imagine a deathmatch tracking system: for every frag in a game, you save all sort of info - who killed, who died, the causa mortis, the weapon, where, when, etc into a single table. And you can use it for regular scores, for example:

Code: Select all

select killer_name, team, count (*) as score from frags where time between :start_match and :end_match group by killer_name, team order by score desc, name

or, you could filter the player with more gib kills to print something like "%killer_name is a butcher! %score gibbed players!":

Code: Select all

select killer_name, team, count (*) as score from frags where time between :start_match and :end_match and killed_health < -40 group by killer_name, team having count(*) >= 5 order by score desc, name

Or, imagine you want to implement that irritating TF2 domination detector:

Code: Select all

select killer_name, killed_name, team, count (*) as score from frags where time between :start_match and :end_match group by killer_name, killed_name, team having count(*) >= 3 order by score desc, name

Not surprisingly, TF2 sends all this info to Valve's databases, and this allows then to detect a lot of interesting information - for example, the maps "hot areas" (where people use to kill/die more), preferred weapons and classes along the game, etc.

And these are just some examples for regular deathmatch. I could imagine a lot of cool uses for coop or single player - like complex dialogues for npcs or monsters that remember how you use to kill them and learn to anticipate and avoid your attacks.

So yeah, an embedded database fits quite well into a game like Quake, despite your beliefs.

[revelator]

earlier versions of ms registry was indeed total fubar no question.

later versions as in vista/win7 are quite a bit more stable and in most cases it wont destroy your machine if you do something your not supposed to in the registry.

the reason is that ms decided to take a more unixy approach by also
saving all seettings in (you guessed it) an xml database.

the downside is size. i cant remember the folders name but its somewhere in system32. my win7 install takes at mint condition (fresh install) about 15 gigs ouch. well after installing the ms compiler and a few other things i ended up with it taking about 45 gig 20 gigs where
xml data, and believe me deleting "ANY" of that will break your pc

as for win7 you cant even delete it no matter what you do and there are certain areas in the registry that will deny you access even as admin (mostly os stuff needed for it to run) but there are a few things like securom that are also protected.

that aside i agree a database can be a wonderfull tool for a lot of matters.

sqlite is one option another is gdbm if you dont like the sql syntax.

[qbism]

The touchy-feely social aspects of this New Age Quake are the features most likely to get folks exited.

How feasible would it be for an engine to upload stats to an online database, by automatically logging-in to a php website? Not continuously logged-in or realtime, just at the end of a level or some interval.

Thinking of single-player games- Players can compare stats and achievements while developers can collect info. The host can be a basic php/mysql website. This is more or less how Flash games do it (Flash Quake should, too!) but it could work on any platform that also supports an internet connection.

Creating a social aspect to single player quake would fill a unique niche. The only thing close AFAIK is Aftermoon's CoopOrDie for Q2.

[goldenboy]

Haha Oohhh, that rings a couple bells...

Before anyone goes all activist over these things, you might want to consider waiting a little. Things are already waiting to happen, but need to be set up correctly, and for any sort of standard base, remember we'll need a reference implementation.

[r00k]

#25: Mouse Driven Menu Support.

[frag.machine]

How feasible would it be for an engine to upload stats to an online database, by automatically logging-in to a php website? Not continuously logged-in or realtime, just at the end of a level or some interval.

Thinking of single-player games- Players can compare stats and achievements while developers can collect info. The host can be a basic php/mysql website. This is more or less how Flash games do it (Flash Quake should, too!) but it could work on any platform that also supports an internet connection.

Creating a social aspect to single player quake would fill a unique niche. The only thing close AFAIK is Aftermoon's CoopOrDie for Q2.

This looks more and more like the original QuakeWorld concept, where a central master server would gather tons of data from online games and spit out a global ranking with several aspects. Having a local, embedded database in the game server to buffer the data would aleviate the stress over the master server, or even turn it totally optional. And it's feasible: Valve already does exactly this with their games for some years. Granted, they have more resources in terms of hardware than any of us could dream, but still can be done in smaller scale. The idea of achievements has a great appeal to the current generation of players, too.

@r00k: yes, mouse driven GUI is a must.

[leileilol]

We have no proper mouse-driven GUI even though there's been attempts at it, it's mostly just the basic menu cursor being moved around and it's often tacky and clumsy in every implementation i've ever seen. Try FTEQW(!!!)'s mouse driven menus sometime.

[mh]

Problem is that Quake's default GUIs aren't really designed well for working with a mouse. A tiny little font with everything rammed as tightly as possible together does not really equate to a positive user experience in the mouse-driven world.

[goldenboy]

If some mod included a new gui, complete with a sort of easy way to customize it, and mouse support in the engine, and maybe freetype support, I guess something could start rolling.

I don't think that csqc based guis are hard to modify once a codebase exists in the first place. That's not to say it couldn't be done engine side or using a scripting language, but why add a scripting language on top of what already exists? Isn't that overdesigning it?

Unless the GUI script is a simple (!) text file.

Still, you're going to want to manipulate parts of the gui from qc, so why not use qc in the first place.

[Spike]

nexuiz/xonotic has fully mouse driven menus, and at least some versions have a way to change how it looks with external script thingies.
its written in qc, of course.
sadly, I don't see much happening since this 'some mod' was released, in regard to other engines...

1 degree of seperation makes cross-engine implementation muuuch easier, and much more likely to be standard at some point. Change too many different source files and you will get porting issues and noone will bother. This is the problem with csqc, and menuqc for that matter, such that I suspect neither will become truely standard.

[revelator]

hmm maybe this is of some use ? its largely incomplete though.

tenebrae2 has an xml based one, i tried to post the code but its pretty darn big so wont fit here.

[r00k]

Without modifying existing menu code, a separate routine could handle the mouse pointer, and a look-up table for [page][x][y].function() when the mouse button is selected.
The table could be a simple ascii file

//trigger page x1 y1 x2 y2 function
mouse1 1 25 25 75 75 menu_single()