refactoring of gamelogic

Release and discuss things you've made, including mods.
Post Reply
User avatar
velociostrich
Dragoon
Posts: 318
Joined: Thu Mar 08, 2012 6:24 pm UTC

Re: refactoring of gamelogic

Post by velociostrich »

freem wrote:

As some might have noticed on IRC I am trying to understand the code since 2-3 days (for now, I have only replaced some variables with arrays). Since the code is, pardon me, quite ugly by some places with a lot of hard-coded stuff,

I have to say that I agree with you that it can be rather ugly in places. I think this is partially due to the cruft accumulated by many, many years of development by many, many individuals and varying levels of code review (from the good amount that we have currently to the seemingly nonexistent amount of review of some projects we've inherited from) and we should make every effort to fix.

freem wrote:

[...] and since peoples does not seem to be against refactoring, I am thinking care about that design to make it easier to understand for newcomers as I.
If it is accepted, I could take the occasion to enhance internal documentation, by example by adding some doxygen comments here and there.

Go for it! I would suggest making your commits to a new branch, and splitting those commits up either by each individual function or at least by each individual file. (E.g., your commit message might read like "Add Doxygen comment to G_SomeFunction()", or "Add Doxygen comments to functions in g_local.h".) I would suggest calling your branch "doygen", and we could merge it with master periodically. That way nothing breaks accidentally and master doesn't get spammed relentlessly with commit messages.

freem wrote:

This will be a long job to complete, but it does not needs to be finished to be useful, I think.
What do you think about that?

I agree with you 100%. The more documentation the better, of course, but some documentation is always better than none.

freem wrote:

Any ideas of areas to work, by example?

Whatever area you are interested in working on, I think; it's hard to gauge what will benefit others the most (unless someone else on the team would like to request something specific). I have myself spent many, many hours trying to write Doxygen documentation for another project and got burned out from doing it, which is why it's important that you work on whatever you find to be interesting.

freem wrote:

Also, I think I will flood a little this forum (and optionally irc) to show which part of the code I will refactor, to avoid unneeded merging conflicts or dual working.

You should absolutely coordinate with us what areas you are working on, and just for that reason! And yes, IRC is probably the best place to do that.

freem wrote:

I guess that to ease this the first point to go is to split those big header files (like g_local.h) to have one header per implementation file (and include them in g_local.h in a first time to avoid breaking things).

Sounds like a good idea to me.

freem wrote:

I perfectly know that I have no possibility to use templates and real classes, but OOP is not a language-dependent feature, it is a way to think which I would like to introduce there, because it could really help to add/remove races/buildings/whatever.

Yeah, you mentioned "C++-" in one of your bug reports. Just to be clear (and for those who may not know what we are talking about), I assume you're talking about this pattern:

Code: Select all

typedef struct {
   // members
} PseudoClass;

void PseudoClass_DoStuff(PseudoClass *const basicallyTheThisPointer, /* args */);

whereby the first argument always acts as a sort of a this pointer, which is basically how C++ works in practice anyway (though MSVC usually sticks this in ecx instead of pushing it on the stack like a normal arg, but whatever, close enough).

Anyway, if you think that pattern makes sense in certain places—and more importantly, makes the code more easy to understand—by all means, go ahead.

User avatar
velociostrich
Dragoon
Posts: 318
Joined: Thu Mar 08, 2012 6:24 pm UTC

Re: refactoring of gamelogic

Post by velociostrich »

freem wrote:

Yes, I mentioned C++ in some bug reports... mostly because I am really accustomed to this language in particular now. But What I am really speaking about is using OOP, which can be made in C, too. It is a manner of thinking, not a language feature. Through IRC discussions, I know that C89 is used for the part which interest me the most.

You didn't read my post very clearly! C++-, as in C-plus-plus-minus, just like you said in your bug reports.

freem wrote:

I tried to do some work on that, the first step was successful (moving some vars in arrays) but the other was wrong (not made correctly in my own opinion so nobody have seen it: splitting g_local.h in various .h files and then refactor.... bad idea.).
I would like to discuss about the 3rd i have, to avoid loosing time for nothing.

Since splitting g_local.h in one time was too many work (and stupid, knowing the size of the file - more than 5000 lines - ) I think I should first move a structure outside his file, then moving the functions declarations using it in the same file. The only interest would be to merge the data structure declaration and the functions using it in the same file. Like in C++ (except that functions are declare inside scope of the class of course).
This first interest will have a subsequent interest, when all structs will be dispatched: responsibilities will be easier to understand. Currently, it is very hard to say which structure will access to another one, except if you know the source code very well.
Starting from that split, it will be easier to guess if some principles of the GRASP can be enforced. If not, documentation will be easier to write.

What do you think about that?

I don't want to be the one to make the call on this, because I'm not as well-versed with the code, nor is it my area of responsibility. Ishq or Fuma or whomever could chime in on this, though.

ComeWithMe
Posts: 2
Joined: Tue May 28, 2013 11:59 pm UTC

Re: refactoring of gamelogic

Post by ComeWithMe »

Refactoring ~ AAA standards and expensive. Its easy to write something that a computer can understand but good coding is when your codes are easy to be read by another human

The best example of this would be the Unreal Tournament 3 Bot codes.

The bot behavior was written within 100 lines.

User avatar
ViruS
Granger
Posts: 1020
Joined: Sun Mar 11, 2012 4:24 am UTC
Location: Antartica - West Australian Post shore
Contact:

Re: refactoring of gamelogic

Post by ViruS »

ComeWithMe wrote:

The best example of this would be the Unreal Tournament 3 Bot codes.
The bot behavior was written within 100 lines.

WUUUT?
*is shocked

What was so great about them? So far the best bots I've seen in an fast paced shooter that matches the game well is probably CPM, and they're not even perfect.

ImageImageYou[TubeImage

Omnipraesens
Posts: 8
Joined: Wed Jul 10, 2013 3:45 am UTC
Location: I am all-pervading, present everywhere.

Re: refactoring of gamelogic

Post by Omnipraesens »

I think the first step towards the final goal of reformatting all the code into a C++ Object Oriented style would be to make the entire thing compatible with the GNU G++ compiler, and I mean everything. The second step would be to ask the project heads if they are willing to change the project's official compiler to GNU G++, and make sure everyone knows how to use object oriented C++. The third step, I think, would be to actually do the refactoring. The fourth step, logically, would be to introduce other C++ features that are made possible by the switch. For C++ programmers like me, the refactoring would boost my productivity by a factor of 5, or possibly even more.

EDIT: Misread previous posts. Host ALU error detected.

User avatar
lamefun
Tyrant
Posts: 371
Joined: Mon Jun 04, 2012 10:29 am UTC

Re: refactoring of gamelogic

Post by lamefun »

I think the mods are compiled by the Unvanquished's own lcc C compiler into QVM pseudo-machine-code that's then translated to real machine code and run. For game logic, it would be necessary either to implement C++ in lcc (C++ is huge and implementing it requires large team and years of work) or QVM code generator for G++. Correct me if I'm wrong.

kangz
Programmer
Posts: 178
Joined: Mon Feb 18, 2013 12:10 am UTC

Re: refactoring of gamelogic

Post by kangz »

You are right, although we had plans to move to an LLVM bytecode for qvms and now we are experimenting with NaCl. If one of these work we could use C++ easily.

Omnipraesens
Posts: 8
Joined: Wed Jul 10, 2013 3:45 am UTC
Location: I am all-pervading, present everywhere.

Re: refactoring of gamelogic

Post by Omnipraesens »

I may be willing to assist with the move to LLVM or NaCl if one is chosen and my skills have developed enough by that point to actually be of assistance.

User avatar
ViruS
Granger
Posts: 1020
Joined: Sun Mar 11, 2012 4:24 am UTC
Location: Antartica - West Australian Post shore
Contact:

Re: refactoring of gamelogic

Post by ViruS »

NaCl?!? Why would someone abbreviate their language to a chemical ionic molecule name?

ImageImageYou[TubeImage

User avatar
killing time
Programmer
Posts: 162
Joined: Wed Jul 04, 2012 7:55 am UTC

Re: refactoring of gamelogic

Post by killing time »

ViruS wrote:

NaCl?!? Why would someone abbreviate their language to a chemical ionic molecule name?

Why not? Everyone does it. For example, the current engine is written in C = Carbon, though it is admittedly not ionic. If an ionic species is demanded, simply remove two electrons and then you have C++.

Post Reply