thanks, se-sss and Spike

@Spike ~ Considering that in today's world of computer sciences almost all schools of thoughts goes towards object oriented design models, I am going to assume you're toying with me a bit here. If we must travel this path together and digress to such points of triviality then let's take the guru of Quake engine design, John Carmack, and see which road he travelled because it would make sense that his evolution in design allowed him to reflect and even help stimulate the gaming world as it is today. I am not proposing that Quake be made in its entirety a game that reflects all the features we see in blockbuster games with bleeding-edge gameplay and features. Let's think about the impact of something I already stated, if say EZQuake's architecture was in C++ in an OOD, I could easily add full md5 with full shader support in under a week and compare that to it's current state, it might take me months to do the same work. This statement isn't coming from some half-assed programmer who deludes himself with fanciful ideas in game development. I have education and real world experience.

It is self-evident to myself that this implication would be understood to mean a whole range of features beyond graphics but incase anyone needs clarification I will say it means every aspect of the engine; audio support, UI, AI, physics, in-game tools etc., etc. To be honest your comment makes me wonder if you even went to school to learn programming as a trade or if you are purely self taught and are indulging yourself on primitive concpets derived on hacker type mentality. Also, I would naturally assume from experience anyone who is capable of refactoring Quake's structural 'C' into an OOD C++ is well beyond writing spaghetti code. Also I'm not saying refactoring from C->C++ is enough clearly there would have to be a solid Object Oriented Design model in place.

You are correct in implying that effort is a key element in all this but and a big "but" here, if someone was to do to this task developers interested in the game would naturally add features that would greatly revolutionize QuakeWorld. Why? Because it would be easy for them to do so an anyone with even moderate programming skills could do so quickly. It's that simple. I would also further say that based on these responses attitude is the biggest killer in any change. It is not beneficial to think I am going to take on the responsibility of making this engine code into an object oriented environment so that it can emulate all the features seen in games today, rather you recognize a problem and deal with the task that's in front of you. From what I can see based on my own game development this is the biggest problem QW has today in it's survivability and thus deserves much attention if we would like to see this game attracting new participants and still being actively played a few years from now. Right now the attitude is pretty much it's a dead project and QW is on it's last legs barely holding its head above water. I have offered a solution and I really feel if implemented features and expansions to the game would naturally occur. An analogy is to build the foundation and the rest will take care of itself meaning people will now have the power to add new features that are cool and exciting quickly and easily so they will.

@se-sss Developers who like using free open-source engines will see it as attractive to introduce advanced features for learning purposes and pretty much every C++ tutorial out there on game feature implementation will also now apply to Quake. Existing developers in the QW community would now be able to jump all over the engine with their ideas adding all manners of features and new developers would now be attracted to the engine.

Anyways, I'm not trying to step on any toes here, it's how I see it, take it for whatever worth you want but just don't be surprised that this attitude of it's a dead project, developers lack effort, hopeless to attract new players becomes a self-fulling prophecy and in the course of 2~3 years the game is dead. The problem is, as it stands, there just is no where to take QW from here until a new foundation has been built to expand upon. At least that's how I see it and no one has changed my mind in the slightest of this.

>>quake will never match todays games.
Which modern game can match quake? I see no such game among shooters.
(Flashpoint and Armed Assult are great shooters but completely different genre).

I do not say if in wouldn`t be nice to have QW rewritten completely with nice code, fancy new graphics and models.

Without marketing and money it worth nothing.

QWTF community did it in another way. They created tf mods to all popurar games (cs, unreal, wolfenstein, q3).
But it splitted people (different physics etc.) and everything is almost dead.

@se-sss That's a good question. To clarify what I mean, QW is not meant to match any games, it is its own game, but rather capable of matching features seen in other games that have proven successful from years of trial and error. These are features that cannot be introduced or is very difficult of being introduced to QW due to its limitations in design.

f00b4r Please name some of those features.
I can suggest feature like "buy quad for 1 gold". It is modern

@se-sss I know this sounds vague but think of any feature to just about any scale out there that currently seems beyond the grasp to implement into QW now and it becomes possible. If you like I could elaborate later but as time permits I have to go. I will be happy to entertain some possible implementations later.

I still don't see the point. Most people that play qw don't use fancy graphics, nor want it. Don't want any "radar functions", don't want teamoverlay, don't want physics to change, don't want it to be anything else then what it is.

There is 2 parts though were I see this could do good, and that is for the OSX and Linux platform only to increase compatibility and functionality to become as good as under win.

What is it that is so major that people would want, that isnt availible today in qw?

People do want md3/md5 models, it's one of the most requested features.

yeah, please add md3/md5 support to ezQuake

@f00b4r: developers who like using free open-source engines will use quake3 as a base, if purely for marketing value. Hey everyone! My game is based on a really old game! yeah, like that's going to get them players.

ezquake has so so many quake-specific hacks in it, that it would need a complete rewrite to get it to a stage where it would retain its user base and be useful for anything else. don't get me wrong, those hacks are genuinely useful, but you have to accept that they are still hacks.
You look at it, and say that its written in C. I look at it and say that its written in hacks - spagetti hacks. It doesn't matter what language its written in, what matters is the myriad of dependancies all over the place. OO will make cvars a little nicer, and make alternative pathways for different model formats slightly cleaner, but on the other hand, alternative pathways are a hack too.
> 'I could easily add full md5 with full shader support in under a week' 'current state, it might take me months to do the same work'
If you feel that it would take you many months (of actual work, rather than playtesting or sleeping) to add md5 support to a quake engine, then there are other issues than just the lack of OO.
But the real question I have for you, is why 'md5 *WITH* full shader support'? If the engine was written cleanly, that would be 'md5 *AND* full shader support'. If you wanted a clean extensible engine, the renderer would care only if it was skeletal, with the loader doing the special case work. This would also reduce your special cases in the lighting routines where you apply your lighting shader, giving a consistantly lit world.
If you were envisaging it as a special model_md5 class with separate load/animate/querytag/renderbase/renderlighting/rendershadow/getsize/cliptrace/delete member functions, then you have twice as much code as you actually need.
Models are already objects. Making them into C++ classes instead will not save you months, unless you have no idea to write code without making everything a class.

You assume that anyone who is capable of rewriting quake to be OO C++ is also beyond rewriting it badly? The number of hacks and special cases required to retain compatibility will undoubtably result in cut features or spagetti, neither of which will aid in prolonging quakeworld.
What I assume is that anyone capable of avoiding spagetti code will not wish to put the time in to rewrite ezquake, when they can just use a quake2 engine.
I also assume that half of the people who contribute to quake engines in general have no formal programming education, and do not work as programmers. I am also of the skeptical opinion that these aforementioned people are prone to writing spagetti code, in whichever language they are using. OO design encourages inheritance and polymorphism above reuse of code. Having to read 5 classes instead of 3 functions is an example of greater spagetti, even in correctly written code, especially where you don't know which class it actually is without breaking in to a debugger.

C++ is almost entirely a superset of C, C is not taught in any universities while C++ is, yet C retains a lot of popularity, arguably surpassing C++ (depending on who's stats you look at).
It is code quality that matters, not language (assuming everyone involved knows both languages in question to the same level).
For my job, C++ is not a practical option, for the most part, so I agree that I'm a little biased in that regard, so I just wanna say that C++ is, on average, evil.

If you want to look at a quake engine which has been refactored into a more OO design, look up fodquake.

But yeah, feel free to add support for md5 to ezquake, though properly working md3 would be more useful right now (I don't actually know of any publically available quake-targetted md5s, so yeah, md3, much more useful).

@Spike ~ Okay Spike I absolutely refuse to go down these paths of thought with you. I understand you have your way of thinking and I think you are being honest about your feelings on this matter and that much I can appreciate. I can tell you right now us debating these points is not gonna get us any closer to progress being made in these matters. You are right in that you believe you are right but I can tell you with a different mindset you are completely wrong. Attitude of developers is also what keeps me from working on engines like Quake because how can you work with people who are so driven on concepts of failure in order to achieve success? The smartest people I work with and have gone to school with have one very simple attitude, "IT'S EASY!" This attitude shines spectacularly in the effectiveness, timeliness and quality of their work. I'm sure if you look even at your own work place you notice this - the more people are focused on shortcomings and how hard things are the more they are banging their heads against the wall to get things done.

If I was someone looking at an engine to use to add features like md5 AND shader support (for possibly learning/portfolio experience), if Quake had a OOD I would choose it above Q3. Why? For many reasons; 1.)It has a simpler code base 2.) There's not any support in the engine of it as of yet so it would put my skills to the test 3.) Because currently there is no support for it so it would benefit players of the game and benefit them while also providing me some recognition which might look good on a resume 4.) etc etc

Anyways, I'm digressing here as I said I refuse to debate you on these points. I will agree with you that there would some areas of major rewrites necessary in the engine to support this goal but so what? You're a smart guy, it's EASY right?

I must ask out of curiousity, these stats you have for structural versus OOD design model architectures, are they based on applications or games? Because to my knowledge there is not one blockbuster game that has come out in the past 5 or more years designed for the PC that doesn't use an object oriented design.

@fog ~ rather than asking me that question why don't you ask yourself that question. Put on some chill music, close your eyes and then imagine features you see in games today in Quakeworld. Don't put limits on what is possible because of artists, effort and such and such. Literally challenge your imagination to go places you wouldn't normally go that anything was possible. Without trying to sound too Zen-master, because it's not, it's really an exercise in imagination, what do you see? That is really what is important here because the developers are not the target audience to make the game successful, the players are.

@Spike I feel silly explaining this but incase you were really asking and not just jesting with me, OOD principles are fairly standarized today. In inheritance the mdl, md2, md3 and md5 models will all inherit from a base model. Then you derive new classes from that base class to define new model types. In creating these blueprints we can assume that the md2 class should be derived from the mdl class because the md2 is likely to contain all the functionality of the mdl and more. This method allows us to save memory in variables and methods when deriving. If this is not true then it would be wise to refactor the code so that the md2 class branches off in the hierachy and is also derived from the model class. So our hierchy would look as follows:
Base Object -> Base Model -> MDL -> MD2
or
Base Object-> Base Model -> MD2
It is important to remember that through Polymorphism we can override base methods so that MD2 has the same method name but has a redefined method function. So long as we're using all the variables in the base class and they aren't just being defined and used for one class then there is no reason to derive classes off of lower classes, although we are also going to inherit all the functionality of MDL in our MD2 through inheritance as well so it's up to you whichever you think is cleaner. The important thing is we can cleanly type-cast from base model either way so long as all of our method names are the same. Some people think it's even cleaner to be able to type-cast any class from Object. Doing it this way you would then define all your method names in your base object as virtual functions designed to reflect any object type created whether it be for sound, models or sprites then type-casting can be done from anywhere in the engine code by just type defining the classes you are referencing.

I am beginning to think f00b4r is a troll... albeit a very clever troll who knows just which 'buttons to press' to anger programmers.

@raz0: Nah it was in response to this:
I was merely showing how inheritance would be working so that twice as much code would not be needed. Of course in this hierarchy the lighting, shadowing etc etc would all be handled in the same way. Classes can also be defined and type cast within other classes so I am pointing out that code duplication is not a problem. Code extension would be necessary but not duplication. It is a silly thing to point out from one programmer to another programmer but it dawned on me from his other comments about his working primarily in structural 'C' that perhaps Spike has little experience with OOP principles in C++ so further clarification may of been necessary. Infact if done properly far less code would be needed than in structural 'C.' With a good design the EZQuake code would become greatly condensed as much as 50% or more, not in memory but in lines of code.

I is completely incorrect to use non-standard features.
You create map with some md3. What should do people with client that does not support it?
Do not suggest to change client. It is OK for him.

Generally I see no need for using md3. 14 years without them were just OK.

It makes sense if you completely rewrite game. But probably rewritten game will have much lower fps (like Warsow game)

The current code is unmaintained 15 years old code with several problems:
- mixing of concerns
- breaking of encapsulation
- many thing have many responsibilities
- one responsibility is handled in many places
- OpenGL usage pattern is archaic
Resolving all these is much bigger job than just adding OOP (classes & c++ compiler) on top of it. I guess that's Spike's point.

On the other hand, OO languages can bring some benefits. Basically they can help in more advanced scenarios. Emulating objects in C is easy (e.g. serverscanner in FodQuake, ...). Emulating inheritance is also possible (e.g. ez_controls in ezQuake, ...). Emulating polymorphism... possible, but with greater amount of service code (more code = more chances for bugs). Polymorphism opens the door to design patterns. DP help to make the code more organized on the higher level. It helps for future reuse. I believe that's f00b4r's point.

You can write encapsulated code in C. We even have internal guides for that in ezQuake. But C++ offers more. You can encapsulate, you can restrict how your objects will be created (private constructor), you can define how your code can be reused (inheritance vs. polymorphism, visitors), and so on. You can somehow do that in C too, but it's simpler in C++ and the code becomes more self-explanatory. The language helps you.

Everything that is possible in C is also possible in C++ and C++ undoubtedly offers more. From this point it does not make much sense to stick to C in the long term.

@foob4r if you had any real knowledge of mdl and md2 formats, you'd know that the only real difference between mdl and md2 is that md2 has per-frame scales, while mdl does not. There are some differences with texture coords too, but mdl is really not favourable to gl so this ought to be fixed at load time anyway. You would achieve less lines of code by not using polymorphism for rendering, but by just assuming that both models have per-frame scales with mdl having the same per-frame scale on each frame.
md3 on the other hand, has fixed scales (1/64th), and shorts for vertex coords. It also has multiple meshes per model, and tags.
While md5 is skeletal, with animations stored externally to the md5mesh.
If adding support for an extra format requires you to change your polymorphism hirachy, then you've spent time rewriting that instead of adding useful features, hence the difference between 'a week' and 'months'. This is true whether its C or C++.
For my part, I recently added support for psk/psa to my quake engine in 2 days. It would have only taken 1 if I had remembered to generate an absolute skeleton for the base frame when calculating the vertex transforms, doh.
A modern commercial game engine would only support a single such model format, and would thus not benefit from polymorphism in regard to models. (Quake3 supports md3+md4, but any more recent ones will support only skeletal formats, as it means 50% less shaders to compile at load time and is thus faster - q3 didn't use glsl).
Rewriting the entirety of ezquake to be C++ would likely kill all current enthusiasm for modding it, regardless of resulting coding style, resulting in some half-broken half-oo mess - that's not going to help retain players.

@raz0 There is not much difference between a zealot and a troll - both claim others to be deluded.

@Spike ~ Now you're speaking of something else entirely but somehow trying to tie it into the original topic of discussion. As I understood it you said that twice the code would be required and I showed that it wouldn't. MD2 could be derived from MDL but it is likely that the MD3/4/5 classes would require another class in the hierarchy as a base or its own class entirely. And the same amount of work would need to be applied to not just models but everything in the engine. The payoff would be a cleaner more extensible engine that's easy to code in, permits a much broader range of features and an engine that is revelant to today not 12+ years ago. As for enthusiasm to further mod engine, that's the beauty of the whole thing, you wouldn't need to. You now have a clean working engine that any programmers/modders would be happy to pick up where you left off and do the rest of the work. If you choose not to see the ease in which it is to work in a OOD and the flexibility it has to offer then that's your cross to bear.


Well that really depends on how well someone did their job isn't it. Are you implying that if you did the job that's what the engine would amass to?


Wow, I really don't appreciate being called a zealot or a troll but if this is where we digress to then I can see this discussion is going nowhere. I do wish you guys success with this but I'm gonna take this as my cue to leave. Cheers!

F00b4r, I can appreciate your point, but the hurdle of: 'stop everything, we are going to make this boat of steel not wood', brings trepidation to many, and the place we are going to is Gilligan's Island anyways... i guess..

BUT fear not my fine fellow friends! Hasn't ZQuake already converted to C++ in some manner? Hasn't DirectQ (http://directq.codeplex.com/) been born not only a directX tangent but also C++? Cant these projects lay path to where you wish to go? Flop down some features in Zquake and let eZQuake catch up, in the meantime eyecandy fishes can bite them hooks!

Look at it this way, at least the QW media, with its low polycount is portable to hand-helds, there's a future yet!

I meant this to be a silly non-obtrusive but meaningful post.

@JohnNy_cz ~ I do apologize, somehow I overlooked your last post. It wasn't my intention to ignore you Here is a quote from an article as to why OOP really is such a powerful way of programming in large-scale applications such as games:


This is absolutely true when it comes to games which is why 99% of game developers in the past decade use OOD designs. Encapsulation is a beautiful thing because you can instance objects such as models, players, sprites, sounds, etc, in their full functionality without knowing anything about those objects. It just works and you need not know why it works. What is also nice because it creates a hierarchical code base that's based on deriving classes for you to create new definitions of class types, the underlying clean version of the EZQuake code base need never be changed. Any new features could be designed to only be derived off the "clean" base leaving the underlying engine code perfectly intact. I hate to reference something Spike said again but he stated that C++ is built on C but I strongly disagree. The principles of C++ are actually how C really work. When you instance a type such as int, float, char etc etc you are actually instancing class definitions of those types. The underpinning of how C works is actually based on a OOD class like structure. This is one of the many reasons why C++ is so powerful and intuitive, it is basically just modelling how the underpinning of C really works.

C++ and intuitive used in the same sentence? *chuckle*

f00b4r: thanks for the reply, but I'd be rather skeptical. Firstly that paragraphs sound like some general marketing article Secondly, such a "clean" approach you describe can only be seen in standard libraries (C++ STL, Java libraries, ...), I doubt any engine, be it free+open source one or some strongly successful commercial one has it's objects and classes designed in a such a clean way, a way that forces "abstraction" and "future reuse" everywhere.

But yeah, I agree that OO is basically "good" and that it can't be fully achieved in C, my last post was about that.

Small offtop.
Have you heard the legend about computer war game where animals had weapons due to inheritance?
They were given no ammo to disallow shooting to enemies.
http://ljmob.ru/read-ru-/user/burrarum/32707

Ok ok.. the Mac zealot has to tune in.. how about Obj-C?! ;-)

The id Software games have licenses that allow stuff from them to be used in add-ons as long as they are free of charge. That's two restrictions; the used materials must be tied to the game they're from and they can't be exploited commercially.

The sources were released by John Carmack, specifically, and not id Software as a whole. Initially, when he released the source code for Wolfenstein 3D and then DOOM, he had chosen licenses similar to the ones applied to the games. Later, in 1999, after some fruits from released sources were lost, most notably an OpenGL version of DOOM erased when the author's hard drive failed, Carmack, an avid supporter of the "hacker" culture and free software, chose the GPL, which requires the user to release the sources of anything he makes available to the public.

The licenses aren't compatible but that means that id Software can still profit by selling the games, because the resources retain their original "only we can profit from this" license, while Carmack can make his engines available to anyone, even companies wanting to make commercial games with them, while ensuring that what is done with their sources remains available in the communities that worked on them.