Jump to content
XCOMUFO & Xenocide

I'd Like To Help


Llyr

Recommended Posts

yeah... uhm...

 

whats going on with that source code?

 

there are no classes at all!

 

if you look at main.cpp the first thing you get to see is several pages of declarations of global variables...

 

the very very first function (yes, it does not have a class! its neither private nor public, its a if-you-see-Kaying global method) starts with lines like this:

 

void show_time_left()
{
   int time_left = g_time_left;

 

uhm... so the function does NOT take parameters, but in its very first line it takes over a GLOBAL variable into a local one...

 

void gameloop() is more than 600 lines long! and contains everything: keyboard input handling, game mechanics, loading from data files, game menus....

it mainly consists of it's more than 100 IF causes... oO

this is 100 lines out of 600 only IFs...

 

there comes some file called "HACKING" with the source code... reading this i found following lines:

==============================================================================

== Good rules of programming

==============================================================================

 

1. Copy/paste is a bad habbit, better create a function containing reusable

code

2. Hide implementation details for classes (use private members when possible)

and modules (use static functions and variables). It makes the interaction

between different parts of code more obvious and easier to understand.

3. Avoid the use of global variables, as they are visible from just anywhere, you

never know for sure when they can be unexpectedly modified.

4. Don't add anything that "can be useful in the future". The code that is not

really used tends to contain bugs and makes the sources harder to maintain.

In addition, when the future really comes, there is a good chance that

this code will need to be rewritten anyway :)

5. If you have to add some dirty hack to make a quick fix or workaround

some weird problem, always add a comment explaining why you did this.

Otherwise other people (or even you after some time) will have problems

understanding this code in the future increasing a chance of breaking it.

6. Comment every nontrivial function, input arguments and return value,

interaction with the rest of code if there are some issues. If you find

that something is hard to comment, that's an indication that this code

is probably written wrong :)

7. More to add....

 

ad 1.

100 if-lines speak their own language...

 

ad 2.

classes? what if-you-see-Kayin classes???

i ran a search on several files, and didn't find one single "private" declaration anywhere...

 

ad 3.

EVERY if-you-see-Kayin variable is global... EVERY LAST ONE OF THEM

 

ad 4.

dunno, didn't really read the code (how could i...)

 

ad 5.

compared to this mess even the dirtiest of all workarounds would still look antiseptic to me...

 

ad 6.

haha, funny thing. functions don't take no input arguments nor return values... everything's handled with globals...

 

ad 7.

how about:

7. please keep at least to rules 1. to 3. !!!

 

 

oh my god, oh my god, oh my god, oh my god, oh my god, oh my god...

 

i feel like jumping outta the window...

may the nice hard pavement, seven floors below me, bring an end to my PAAAAAIIIINNN

 

*screams*

Link to comment
Share on other sites

haha, i felt the same way the first time i had to use procedures as well.

was just about 13 or 14 years old back then, playing around with plain old basic...

 

i thought procedures where a pain in the donkey. using labels and goto commands was much more flexibel since you could jump from any one point to any other point in the code.

with procedures execution always had to step back to exactly that part of the program, where you called the procedure...

oh yes, i knew enough about procedures to know i didn't like them...

 

until i found out that once the program got a little bigger i started to completely loose overview with all the confuse jumping around of gotos, and there was no way to know all possible paths execution through the program could take...

 

but who would still use GOTO nowadays? are there even programming languages that still support that command? except for assembler of course... on base of machine code everything is done with GOTO jumps...

machine code is the HEART of programming. and yes, IF is an operation known to assembler, so its very very basic. same is true with GOTO !

 

i felt exactly the same way the first time i had used a function. why use arguments on a function? why use a return value... just store everything in globals and you don't need to mess around. you never have the problem that functions only support one return value, and you can still use local variables for stuff that should not be returned.

i really knew enough about function to know, that i didn't like them.

 

until i found out that with arguments and return values i could use one single function multiple places with any different variables i liked... i hadn't to copy paste the whole procedure for any variable i'd like to use it on...

 

and arrays... guess what? i didn't like em!

what use was it to group variables together to packs, and instead of an understandable name that helps you knowing whats stored inside, you gotta reference it by some number...

i did know enought to know i didn't like em...

 

but know what? i found out then, that i could do loops with some increasing index-variable to access all variables inside the array, one after another.

 

and recursive behavior... gosh, i sure didn't like that one at first. procedures calling themselves, calling themselves, calling themselves, calling themselves... that surely made my head spin around.

it was hard to imagine at first that each new call of the same procedure created some sort of new "instance" of that procedure with its very own local variables, and then giving back its return value to the older instance of itself, that still was using its own, old variables...

but i found out, that enless recursion produced even nicer hangs than endless loops... "not enough memory to load dos prompt" was quite a nice error message *LOL*

 

and pointers... oh my god, how i hated pointers!!

i had to do sorting of double chained lists (is that the proper english expression for that? only know its called "doppelt verkettete listen" in german...). and i really tended to always end up in a mess. nice loops possible there too... but even better: you could loose whole parts of these lists somewhere in memory, with no chance of ever accessing it again, and also no chancing of freeing up the use memory again...

 

believe me... i could go on with this listing forever...

 

and theres one more thing you have to believe me:

it was not different with OOP at all... i really didn't like it... but by that time i had already learned not to judge it based on personal resentiments..

the step from procedural to object oriented programming was a quite hard one... all the things mentioned above where really really easy compared to that... and there was so much more overhead in the code, making everything feel so different than what i was used to...

 

but guess what i found out!

from a class i could create as many instances as i needed, at runtime!

i wouldn't have to create data structures that could hold all attributes and stuff for 10 different soldiers, but only for one! i just need do it one single time, and then create 10 instances out ouf it.

and if for any reason some day i decide i'd rather have 15 soldiers... no need to change all the data structures so that every array is able to hold 5 more entries, and that every loop is run through 5 more times...

just make 5 more instances and done.

for fact i don't even need to state any number of soldiers within the code.... just have the game create new soldiers as needed on runtime. okay, at some very high number of soldiers there would suddenly be problems with memory...

but you could easily fix the number of soldiers to some constant that is read from an configuration file each startup... if you ever want to have even more (or maybe less?) soldiers again... just change the value in some .lua or .ini file and your done. no need for any changing code or recompiling...

and with classes you can split your programm into a whole bunch of more or less independent working parts, just interacting with each other. so different people can work on different parts of the programm simultaneously, without interfereing with each other and effectively breaking the code...

this reduces bug probality significantly, and if some bug occurs its muuuuuuch easier to hunt it down.

of course, as long as a program is small enough that it could fit into a single class, there's absolutely no need for and even no use for any kind of object orientation...

but compare "space invaders" or "scorched earth" with "diablo 2" or "halflife2" or "c&c generals"...

games are getting bigger and bigger, and they are getting more complex and more sophisticated.

and so do the tools to create them.

the bigger your code gets, and the more and more functionality you add, the better your methods of structuring and modularisation need to be.

 

and multiplayer ability alone does expand ufo far far beyond its original borders...

 

the times where you could do a game entirely in assemlber are long gone...

Link to comment
Share on other sites

whats going on with that source code?

 

What would you expect? That's a normal state for the sources when a lots of code was written by non-professionals. I have written that HACKING file, and it reflects my experience in software development and that is my normal coding style (except for the braces style). This file is suggested for reading for all code contributors in the hope that it will be useful and that will help to improve overall quality of new code. But if I tried to strictly enforce these coding standards, almost all the patches would have to be rejected and I would be considered a badass :)

 

And your complains are a bit naive, in a real world you can't develop software with a perfect design and implementation. Constantly changing requirements, unavailability of highly skilled developers and other things make this impossible. There is a trend in gradual reducing quality of microsoft software and the games produced by commercial companies.

 

About ufo2000 development model - it is heavily inspired by extreme programming methodology. That means frequent releases, constant integration, iterative development, so that features get implemented in the most simple way which works. Special care is taken for automatic errors diagnostics and reporting. And of course refactoring - replacing the old stinky parts of code with a better one (so we may have a hope after all) ;)

 

About the sources and programming paradigm: it is mostly a subset of c++ which is sometimes called 'c with classes'. That means we use incapsulation, but don't particulary have any need for inheritance and polymorphism.

 

And don't forget about lua scripting support - it hides a lot of implementation details and provides a reasonably safe environment even for inexperienced programmers for modifying the game.

 

Well, if you don't like our source base, you can start your own project or join some other which you consider better. If you really want to help, we may find a relatively isolated task for you so that you can impress all the rest with your outstanding skills.

 

And some references:

http://www.xcomufo.com/forums/index.php?showtopic=4045

http://www.xcomufo.com/forums/index.php?showtopic=242024773

Link to comment
Share on other sites

fact is i just don't have that outstanding skills.

 

i was quite good i'd say way back with 13 years, and i kept good speed at learning until i was 18. i would say i was as good as someone who visited a technical school and had interest for programming, but with the difference that my knowledge was all self-taught.

 

university broke me, and i just quit my computer science studies last year, since i was getting nowhere. all that outdated stuff we learned at university didn't help my skills at all, and since i had much learning to do for the exams, my interest in digging into the same stuff during free time ceased to exist, so stopped teaching my self, i'd say.

 

also most projects i ever worked on, where my very own, or with a team i was part of from the very beginning, so i definitely lack experience about how to get into something already that far commenced.

you definitely need to be a very expert on this matter to be able to read that code, and then you would still have to take a lot of time.

 

after hunting down that crc-bug i felt like downloading the source and just taking a look at it, just to see if i was able to fix it on my own. after taking some first look my impression was that i would definetely need to spend several weeks before i'm able to change anything in there... (surely someone else would be faster)... although some charts showing dependencies among the more important and more central parts of the game could help...

 

fact is that i wrote some little scorched-earth like game (but in realtime) back when i was fifteen... my coding style back then even was not as bad as some things i've seen in this source... and the most important difference is that this little game was about 800 lines i think... i'd like to show you, bat afaik the source got lost with some head crash of my hard drive years ago... i had a back up on some floppy disk... but you know... floppy disks... the game's not good at all, but i'm still proud of it, since i was only 15 ^^

 

the problem is i got my next exams closing in, end of march, and since i have to earn my living completely on my own i have to go to work next to studying, which doesn't leave me with too much spare time. so i guess it would take me months to understand just the most basic "structure" of this piece of software, so that i'm even able to search for some isolated piece of code...

 

one thing you must admit... that code is some messy patchwork...

so there's no need to feel pissed cause i'm shocked it works at all...

 

edit: and i've read that article from netscape why it's not wise to rewrite code from scratch. the messag is basically, that all the messy parts of the software are actually bugfixes, made to make it work on all kinds of systems.

but i really don't believe that this:

void show_time_left()
{
  int time_left = g_time_left;

is any kind of bug fix...

and that there would be any trouble with the game, if you replace it with:

void show_time_left (int time_left)
{
  ...

and call

 

show_time_left (g_time_left);

 

instead of

 

show_time_left();

 

 

or do you think that's a bugfix???

Edited by Llyr
Link to comment
Share on other sites

That's a normal state for the sources when a lots of code was written by non-professionals. [...]

And your complains are a bit naive, in a real world you can't develop software with a perfect design and implementation. Constantly changing requirements, unavailability of highly skilled developers and other things make this impossible.

 

so you think the fact that there are no highly skilled programmers available makes it impossible to create high quality coded software...

 

you may call me naive if you like, but i think its exactly the other way round.

go to the sourceforge site and browse through the software map, and take look at some sources. there are quite some high quality open source projects out there, and they got skilled programmers... where do they all take them from, if they are not available, and how do they make their software so good, if thats impossible to do??

 

couldn't it be that there are highly skilled open source programmers out there, and that they rather choose to participate in well-coded projects than in other ones? isn't it like that, that they are only unavailable to projects with far too messy sources?

 

so what about DaiShiva?

WHY doesn't he help programm anymore?

is he so unskilled? or rather so unavailable?

i guess he is with some other project now...

Edited by Llyr
Link to comment
Share on other sites

You could instead, make a map editing suite. Thats the one thing we need real bad addon wise and it'l give u a chance to format your code the way you want it.

 

Would sure beat complaining and would (im sure) be extremely apperciated throughout the community

Link to comment
Share on other sites

so you think the fact that there are no highly skilled programmers available makes it impossible to create high quality coded software...

The number of highly skilled programmers is really limited (this is true for any profession), you can't have only experts in your team. It is impossible to create absolutely perfect software. But if you want to get high quality, it will cost a lot more than just getting acceptable quality. Anyway, I'm not going to discuss this matter anymore :)

 

you may call me naive if you like, but i think its exactly the other way round. 

go to the sourceforge site and browse through the software map, and take look at some sources. there are quite some high quality open source projects out there, and they got skilled programmers... where do they all take them from, if they are not available, and how do they make their software so good, if thats impossible to do??

If you go to sourceforge, you will notice that the majority of the projects registered there are abandoned, have pre-alpha status and their sources are in a very bad shape, sometimes they are even not compilable :)

 

There exists a number of high quality projects. But most of these projects belong to mission critical category (e-mail clients, browsers, video players, ...). So they get enormous attention, lots of developers, donations and other resources. Entertainment is not a critical area, so you will not see many good quality open source games.

 

http://www.osnews.com/story.php?news_id=8146

 

couldn't it be that there are highly skilled open source programmers out there, and that they rather choose to participate in well-coded projects than in other ones? isn't it like that, that they are only unavailable to projects with far too messy sources?

I'm fine with that. Let them choose to participate in a well-coded x-com remake, or start a new one, or whatever... If you find such well-coded project, just let me know, maybe I'll join as well ;)

 

so what about DaiShiva?

WHY doesn't he help programm anymore?

is he so unskilled? or rather so unavailable?

i guess he is with some other project now...

He may have his own reasons for not helping with programming. But I don't really care. He was provided with all the information he might need to add support for more skins to the game. He did not help us with this task, but nevertheless support for skins was eventually added. And it did not require a complete source code rewrite.

 

People who do not have confidence from the very start, usually do not help much. That's just like fighting, they already lost, and this has nothing to do with the skills. And I don't feel like asking them to change their mind.

 

As for current ufo2000 project state. While I'm still here, I can ensure that ufo2000 engine works and does not get broken. I'm working in software industry long enough to be able to solve almost any programming problem for a small project such as ufo2000 (but unfortunately I don't have much free time available, so if nobody helps, the progress is extremely slow). If you accept this fact, you can close your eyes, forget about sources *ugliness* and help the project in some other way :)

 

Some global tasks that do not require touching tactical engine are the following:

* online repository of ufo2000 addons

* advanced map editor

* geoscape

 

Arguing and having long discussions is really pointless. So I'll just ask one question: what do you really want? Any constructive suggestons?

Link to comment
Share on other sites

what do you really want? Any constructive suggestons?

 

you say that i want to have PERFECT software, and why i complain about just having "acceptable" code.

 

i say ufo2k code is far beyond acceptable, and i don't say i just want perfect code, i want code that is STRUCTURED and READABLE (and thats still way from perfect...)

 

both is personal opinion and since i don't believe in absoluts, including absolute truth, these are two relative statements, that can't be proved right or false...

 

what do i want...

i am not talking about a complete rewrite from scratch. i know youre not going to do that. but i would like to make people think at least a little bit about coding style, since it seems to me that this cared for much to little. i was harsh, but i had the feeling like kicking someones donkey after seeing that. sometimes it helps getting kicked in ones donkey.

 

i know that programming something in clean code is more work than just doing it anyhow, and that this extra work is some especially annoying one. i can understand you don't like it.. i don't like it much either. but i think it's worth it!

 

you all think the code is good, because it does work, and theres no need to clean it up, to do any restructuring, or take care of style at all, when making changes. thats my opinion. i got that opinion while looking at the code, and i think, that all the answers in this thread here prove me right.

you all have a right to oppose that oppinion. but the same way i do have the right to state my opinion.

 

what i want to achieve is to make you rethink that. is there really no need to clean anything up? is it really fine the way it is?

wouldn't be some improvements of the internal structure be of benefit to the game, and also increase the chance of attracting new people to help?

 

everybody now reacts like:

"there's no need to rewrite anything that _I_ have coded", or like "the game I like soo much, DOES have good code"....

that was to be expected...

 

but still i think, the next time someone who read this will touch the code, he will remember this discussion. and that's enough. if he does, then he is thinking about good style like coding, and i have achieved something.

 

so, now you know my intentions, besides the itching urge to share my shock about the code with others... (which played an important role too, i admit)

 

 

constructive suggestions:

 

a little clean-up maybe?

 

whenever making new functions, doing everything with arguments and return values, and not reading from globals?

 

whenever you do already change some part of code, and so are already into it, maybe spend a little extra time to also streamline it a little bit, and get rid of some mess? (shouldn't be a problem to find some...)

 

keeping in mind that - people who'd like to help will take a look at the code first, and that the code can make them change their mind - while coding

Edited by Llyr
Link to comment
Share on other sites

quit complaining and structure it yourself. Weve all got better things to do then argue over trivial stuff Edited by Sporb
Link to comment
Share on other sites

quit complaining and structure it yourself. Weve all got better things to do then argue over trivial stuff

 

if could read that stuff... give me several months for studying the code than i may actually be able to change something in there...

 

that's what it intended at the beginning...

 

but actually.. that code scares me off...

i don't fell like actually spending that much only time only to see through that mess. guess what! i think i've got better things to do, than that...

 

and don't be so hostile. if you really think the code is really that acceptable, you should be able to withstand some criticism. if i believe in something, than "pointles, trivial" criticism would bounce off of me, without even scratching me...

so, don't behave like i did insult you personally. i criticise the looks of the code.

your insulted behavior makes me think i did hit some weak spot..

 

edit:

i really did not expect that everyone round here seems to think the code is absolutely fine, and theres no need for any structural improvements at all...

that's really surprising me!

i expected some people to say "that's no true! all lies! what nonsens", and i expected somebody would say "then just if-you-see-Kay off and leave us alone", but that there isn't one single person who's able to admit, that some restructuring would benefit the code and the whole project... that really, really surprises me. i never would have guessed that. since i'm part of the crystal space newsgroup, and there are some if-you-see-Kaying freaks around, that do stuff that is far beyond my skill and understanding. and their code is consisting almost entirely of exchangeable plugins... graphics canvas, renderer, game loop, input, sound, event handler, etc. etc. etc.... everything is kept totally seperated and therefore exchangeable and reuseable. and if you ask some lead programmer there about their code they answer you with a if-you-see-Kaying endless list of things that need to be "optimized"... although everything does look already perfect to me... they seem to spend equal time on polishing up old code (without changing its functionality) as they spend on implementing new stuff. or maybe even more?

and still they say the enginge is far below its possibilities since they haven't done any speed optimizing yet at all. they say that will have to wait until version 1.0...

Edited by Llyr
Link to comment
Share on other sites

you all think the code is good, because it does work, and theres no need to clean it up, to do any restructuring, or take care of style at all, when making changes. thats my opinion. i got that opinion while looking at the code, and i think, that all the answers in this thread here prove me right.

you all have a right to oppose that oppinion. but the same way i do have the right to state my opinion.

How did you get this impression? Nobody told you that source code is good. We are constantly working on improving the quality of sources. Your suggestions are are right and really don't add anything new to what is already written in HACKING file. The problem is that nothing gets magically fixed itself and needs time, that's why you see the difference with what is written in HACKING instructions and the real state of the sources.

 

I'm not telling you that the sources are good, but you are really taking that to extreme. In fact the game has some structure if you bother to see it, it uses classes, parts of its code are well commented (other parts will be commented sooner or later, we are working on that). If you want to get some introduction to the sources, you can check http://ufo2000.lxnt.info/files/ufo2000-0.7.988-doc.chm (this file is built using doxygen tool). If you don't understand someting, you can just ask, and that will be explained to you and more comments added to the sources as well.

 

Now you wonder why we can manage to succeed with such sources? I can explain it if you want a bit later (now I'm really out of time).

 

PS. I'm sorry, I totally missed your post #7 first and only just noticed it.

Link to comment
Share on other sites

@ SERGE:

 

you think there is any chance to get the source of which should be the tile-engine crapped together enough so it's reusable?

 

since an editor should preferably be wysiwyg there would be real need of a working tile engine, and using the same tile engine than the game itself does make sense in many ways...

 

.) doing two engines parallel is unneccessary extra work.

 

.) using the same engine ensures that levels will really look the same in the editor and in the game.

 

the best approach (imho) would be to have the tile-engine working indepentend enough, so that an editor can include the files of the tile engine (and of course all other files it depends on) and then link to the very same object files as the game itself does. but the editor would still stay its own seperate executable and not be included in the game itself. (that's for example exactly the approach blizzards famous starcraft editor took... and i still think its one of the best tileset-editors...)

 

but fact is, to be usable in two different projects at once, the tile engine needs to be quite modular and independent. it may not access any global variables. it has to be coupled with all the data it needs. having it as a class which keeps all its data private and only publishes the methods needed to communicate with the rest of the game would definitely ensure that reusability. but all the other files that the engine itself is depending on, would have to be seperated from the main game in the same way.

 

and that seems to be something that's absolutely unachievable, since people don't even want it...

 

so there's no way not to have to seperate tile engines, is there?

 

except for including the editor to the game mainloop by using large numbers of "if (mode == "edit")" clauses... which is a way i absolutely don't want to go, since it complicates and messes up the game code in there even further, increases the possibility of bugs, and decreases the chances of finding them quick, and makes maintaining both, the game and the editor harder... and i think that method has been used on that code already way to often...

btw. i don't want to break the game everytime i possibly break the editor.

 

i'd love to have a tile-engine with all additional stuff like initialisation, reading (and writing) map files, drawing to the screen, etc. with a high level interface so i don't have to worry at all about any low level tasks the engine has to make. if that was possible, creating an level editor would really be easy work...

the tile engine is there, but it surely is not modular enough, it could be used anywhere else...

 

but creating another engine for the editor to use, would increase the work needed for the editor by several hundred percent...

Edited by Llyr
Link to comment
Share on other sites

May I state that it's pretty much possible to build an independent OOP tile system, basically for the editor and then inserting it into the game.

 

From what I understood, "We won't rewrite code" is not a law. It's mostly to let people know that a complete source code rewrite from scratch is not a good option given the time we have to put on the project (especially the chief programmer).

 

For example, I'm going to work on a loading screen for the connexion and the mission planner, which will mostly end up with the version comparision check being completely flushed and replaced by a little "classified" thing with a few methods. I am concerned with this screen being able to be used just about anywhere so it will be OOP.

 

There's nothing stopping us to make future code modular and reusable, and we not only can but should also clean up and rewrite old stuff in the process.

 

I'm really a newbie to C++, blue in OOP, but I'm quite experienced in web-based programming and I know how useful reusable code is, so I do get your point.

 

If POVs differ on this, it's mostly about when stuff should be rewrote. If you want to help, do it your way! If it works, players will be happy, if it's cute source code and well done, programmers will be happy. If your code is a total mess, the patch won't make it. But if your patch doesn't add a feature, players won't care, if it removes a feature, they might scream for having it back.

 

As long as future programmers care about both the players and those who will read them / try to use their work, both parties should be happy. Now if someone wants to slowly nest classes and move ufo2000 to cleaner source code, he should go for it since it will help in the future as more things get to be added, and why would source improvement patches be rejected anyway?

 

As for Serge, I understand his point of view too.

 

But, fact is there is no :Speach: truth.

Edited by nachtwolf
Link to comment
Share on other sites

so things start getting interesting... creating a tile-engine is challenge compared to which doing the actual "edit-stuff" is only some little add-on.

 

in that case there's no chance i don't need to worry about the (rather) low level stuff... i've never worked with allegro before, so i would have to get myself some knowledge there, but i'd like to ask some question first...

since learning to use allegro or learning to use any other sprite-engine doesn't make much difference for me, i'd like to know if we absolutely wanna stay with allegro, or if there's some possible alternative that may be even better, but since switching to something else would have needed a tile-engine rewrite, the very idea of swapping sprite engines has always been dismissed.

 

now would be the time...

Link to comment
Share on other sites

hm.

 

map is some class already, but i'm not yet sure how to use it for my purpose... there are lots of references to other stuff, and i don't know know what all of this does yet.

 

will need to read into that much further...

 

'Map' class is not quite map, but more like a 'World'. It is too big and will need to be split into some smaller parts in the future.

 

You can look at 'Map::draw' method, it is used to draw map image to the screen. For a map editor a lot of the code that is used there is unneeded - no need to track field of view, lighting levels, smoke and fire animation, units walking animation, explosions and lots of other things. Also it handles a cursor in a special way depending on whether we are in targeting mode etc.

 

So the code which is needed for a map editor is not so large and it can be obtained after stripping that 'Map::draw' function and also 'Map::draw_cell_pck'. Map editor will require its own handling of selection cursor (for adding walls and other objects on the map).

 

Also check TerraPCK class, it is responsible for loading tile information from external files (either x-com *.mcd or ufo2000 *.lua). Each map cell can have 4 objects (2 walls, floor, central object), each object is encoded as an index in 'm_mcd' array, which contains all the information about that map object including its sprite. X-com *.map files is just a 3-dimentional array of 4-byte data. Each byte is that index in mcd array. So everything is quite simple. One of the future improvements is to extend that *.map format because it has an obvious 256 different tiles limitation. It is already not enough for some of the more advanced maps.

 

While working on the editor, it is possible to try making some kind of abstract map view rendering class. In that way it could be used to make a 3D frontend in the future if we want one (in addition to current 2D tile based frontend now). The reason while this map displaying code is not in its own class is that this code was quite simple in the beginning. Only later more features like smoke, explosions, lighting, and the others were added. It is now obvious that the code is not quite well structured and we can see the ways to improve it. But at that time, the requirements which would be applied to that code were not quite clear. And even now we don't quite know what will be required next and can't make an universal design which would be able to withstand any future improvements without being modified. So instead of writing code as good as possible code 'once and for forever', any developer should be ready that his code will be improved later, excess polishing code and spending more time than it is necessery on it is not very efficient. Most likely there will be always another iteration. Here is some interesting link: http://home.earthlink.net/~huston2/dp/run_rite.html

 

About allegro. It is not strictly required to use allegro in a map editor (though using allegro we may integrate a map editor into the game and reuse TerraPCK class at least). Actually it probably would be easier to use MapView sources to make something based on them if daishiva agreed to release his map editor open source. Allegro is historically used in the game and there are no serious reasons to change it for some other library (as long as ufo2000 remains 2D, but it is also possible to use OpenGL with allegro). One of the alternatives is SDL which is more popular in linux and has more platforms supported. But SDL is not that much better and its performance is comparable. And in fact allegro is easier for programming, has good documentation and has active and friendly community.

Link to comment
Share on other sites

ive already sneaked a peek into allegrogl lib... but didn't pay enough attention to really find out what it does...

 

it seems to replace the functions of allegro which are actually responsible for drawing to the screen and such stuff. basically allegro with 3d hardware support i guess. still dunno if this would change the interface of allegro, or if the changes are transparent so you just get some faster allegro (with some extra function maybe?)... no idea ^^

 

i know that code is likely to get changed later on, thats one of the reasons i think clean programming is so important. i will try to make the code as expandable and as dynamic as possible. i would like to have as little hardcoded limits as possible, so that the class is very adaptable at runtime. that's at least what i would like to do... i hope this doesn't conflict with what i am actually able to do ;)

 

but i will try. the worst thing that could happen is that i fail. that's acceptable risk, hehe

 

but that could take some while. some exams are closing in, so i will have to spend some time on learning that stuff too...

Link to comment
Share on other sites

Please keep in mind we still need a .lua replacement for the .map files, that should be a priority issue IMHO. As a summary, .lua replacement for .map files need to support beyond 256 tiles (2048 would probably be enough... 1024 might be short...), ideally beyond 4 levels (feature asked by a lot of people, I support the idea), and while we're at it, beyond 6 x 6. :P.

 

The idea behind this is not having 120x120 x 160 levels maps becoming a standard, it's more about map devellopement flexibility, 4 levels is too tight for map making (think of cities), 6 x 6 is too small for large map amateurs, 256 tiles limit is simply ridiculous.

Sure 6x6 makes longer battles but when 2 players crave for a long game in a large map, agree to make a large battle and want to play in 10x10 for instance, the option should be available.

 

BTW, a basic webbased tileset editor I develloped is already available and helped creating Nappe's moonbase map. It has limited file management but works very well if you know how to copy/paste.

Edited by nachtwolf
Link to comment
Share on other sites

Yes i agree - My urban tileset is running out of room both Tile wise and in usable height. I also like the idea of being able to have larger maps for Epic battles (always fun imo). The urban set is intended to be a detailed map but i'll need far more than 256 tiles to do that. For example a small car would require at least 12 tiles and a bus would require double that. Then there is the need for damage too, a burnt out car will take the same number of tile so thats instantly 24 tiles per car (roof spouting and lots of flashing neon too, all of which require damage tiles!). Then theres map height, 4 levels is not nearly enough to make a cool tower and that'd be a main theme for urban set since it's set in a depressing urban future city environment. As for map size, it's all well and good to have 6X6 maps but they just cant provide engough landscape when it comes to epic warefare bigger is better in some circumstances. Edited by Sporb
Link to comment
Share on other sites

@serge

 

So instead of writing code as good as possible code 'once and for forever', any developer should be ready that his code will be improved later, excess polishing code and spending more time than it is necessery on it is not very efficient. Most likely there will be always another iteration. Here is some interesting link: http://home.earthlink.net/~huston2/dp/run_rite.html

 

hm. i think that text does allow for some different interpretations... imho it would mean:

 

1. make it run (that should be clear i think...)

2. make it right (make it modularized, readable and easily modifiable [transparent?] code)

3. make it fast (and last two may include forgoing some good architecture for the sake of speed and size...)

4. make it small

 

 

especially look at that sentence:

Resulting

context: Efficiency doesn't unduly compromise good architecture and product design.

 

so you should keep to that rules because you don't want to compromise good architecture by efficiency measures.

 

does sound like: "do it oop, even if its slower and bulkier than otherwise, just to keep the code clean, seperated and easily readable because very modular..."

 

i think this little text does exactly fit my opinion about nice coding... no messy patches just because they run faster (or maybe just because they can be programmed faster?), no compromising of the _good_ architecture unless absolutely neccessary...

not neccessarily the fastest or smallest code... but surely the most easily readable and modifyable one... isn't that what i was talking about from the very beginning?

 

 

------------------------------------------------------

 

@sporb und wolfi:

 

i will try to make the code as expandable and as dynamic as possible. i would like to have as little hardcoded limits as possible, so that the class is very adaptable at runtime.

 

that would mean having x*y*z size map, where x, y and z are defined per settings or lua in this case.

this would give full power to map designers (including the power to eat up too much memory or making the game run unbearably slow or otherwise unplayable...)

with power comes responsibility...

especially having many floors could become a big problem concerning map-drawing time i fear...

 

that's the plan. realization of that could still be somewhat limited (either by technical aspects or by my skills or by the technical aspects of my skills, or by my skills concerning technical aspects or wathever ^^)

Edited by Llyr
Link to comment
Share on other sites

  • 1 year later...
  • 1 month later...

Serge

 

I'm going to pick up on this very old thread because ... ah well firstly some history

 

Like many posters here I like XCOM and haven't seen anything really match it never mind improve on it. I am pretty excited by the current code base in terms of what it achieves. Hats off to those poor sods who've given up large chunks of their lives to get it this far. I'm not sure most people appreciate how long coding takes. I'm a professional software developer (business not games) so I've got a good idea just how much effort is involved.

 

I'm also interested in helping out though time is limited by other things in life - predominantly invoving earning a living so I can have food and shelter.

 

I'm picking this thread up because trying to follow the code was pretty hard for me (and I've got over 10 years of c++ experience). I wanted to make some comments that had some relation to the original post. I'm not trying to criticise or to suggest anything radical - I would like to provide constructive points. And to put my money where my mouth is by offering to sort the things I'm raising. I'm going to raise the points because I think that with the code as it is, it is too complicated for most hobby codes to get to grips with. It's too scary and too intertwined. I think that you will do the project a great favour if you start to "tidy" it up.

 

The OP had made some good points regarding code and Serge and Hobbes and others made some good points about not wasting time coding for the future when it all might change. I think one thing that has been missed in all this is that refactoring code is a good thing. Martin Fowler (a major party in the creation of the Agile method of which XP is a part) was first and foremost a proponent of refactoring. Basically if you are going to go with an evolving design & code base you need OOP. I think it was Fowler who said "if it ain't broke, fix it". Basically refactor the design to do things better with hindsight and that allows you to progress to the next problem more easily. It stops the build up of crud.

 

On to my list of points and they are all technical rather than functional...

 

Global variables (as Serge comments in the code) need to be removed as a matter of priority.

 

The includes are also in a bit of a pickle such that changing any header file tends to cause a recompile. Many coders use older boxes with linux installed as a cheap dev box. Sorting out dependencies would be good for both compilation times and for code clarity.

 

Each class should have as few responsibilites as possible and be encapsulated behind functions. That way things evolve without breaking things unexpectedly. If you have exposed externals (through overuse of friendship or public data) then you cannot safely evolve things. It becomes too difficult to automate any testing. Agile dev requires rapid releases on the back of automated testing. Without the later you cannot guarantee safe releases. Probably breaking apart the map class is the biggest issue. There's the terrain management, the lighting management, fire/smog,explosions, critters (the soliders) running around looking at and blowing things up.

 

Friendship also needs reducing/removing. Initially it can be replaced with get/set methods. These are not ideal and almost go against the grain of OOP. What they do give you immediately is encapsulated data. From this you can then move on to refactoring large methods to spread the work into appropriate classes. As an example a lot of the LOS/LOF/Smog/Fire stuff can be pushed into Cell out of Map so that map does not need to constantly examine and twiddle with data inside the many instances of the Cell class.

 

Documentation - some of the comments are just plain wrong - probably due to code being inserted between comment and code. I hate documentation and prefer variables, functions and class names to say what they do explicity. Only convoluted algorithms need comments as to what they try to achieve in my book. Doxygen comments in the header files however are a real help to newbies. Problem is, no one wants to do it so it gets put off. Which attracts fewer newbies. Which means the developers are too busy to document.

 

 

If it all sounds way too much like "theory" think for a moment about the idea of adding IR or low light goggles to equipment. If the vision code is nicely encapsulated then adding a new kind of vision is much easier and should not involve changing [do x] by by cut and paste to [if IR do x-IR else do x]. This is where inheritance comes in to play. Also consider inventory and armoury and cell places - all have some different functionalities that require some if ishand() or suchlike beforehand to use what is effectively one interface with 3 or so different implementations. Those implementations also have additional seperate functionality for special cases - only the hand place can "fire or throw" stuff.

 

 

Okay - enough for now. I'm sure some cages will have been rattled. Written words/Emails/Blogs/Forums are the most sure fire way of getting two or more people to miscommunicate.

 

As I said - I'm happy to do the work for what I've moaned about. I just need to know it will be worth the effort to start things rolling. I've already started within my own respository more as an experiment of the work involved. I'm happy to continue to do my own thing until I get bored but it would seem sensible get involved with this code base.

 

Let me know.

Andy

Link to comment
Share on other sites

Guest Azrael Strife

I'm not the one to talk about this, but my opinion is that if you could do this it'd greatly benefit UFO2000. Right now the code is a mess, a huge one, I think it goes against all programming conventions and rules of style I have ever read, including the non-usage of global variables, which this thing does on every opportunity. I'm sure it has scared away more than the occassional programmer who came with all the will to help.

 

Good luck =b

Link to comment
Share on other sites

itd be fantastic if someone cleared up the code. It will be most beneficial to programmers working with the code at the moment because they wont have to tip-toe around everything for fear of braking something completely unforeseen.
Link to comment
Share on other sites

Some kind of graphical overview of the source's hierarchies would rock too.

 

I like to do documentation myself. I've found it clears up my thinking. When I write some complex stuff I can put comments on what it generally is about, if it's not obvious from the variable names (usually you think something is obvious when it's not). I've done mostly C and Java lately and C++ has been on a bit of a back burner...

I think the most important improvement would be fixing the memory leaks, I guess that requires refactoring.

I hope it could be done, just hope that it can be done in some manageable sized steps so we don't have to go back to original with lots of work wasted.... (I guess the XP method aims to do this...)

But the real ufo2000 coder guys can give a real opinion. :)

Link to comment
Share on other sites

Hi AndyS,

 

I'm a professional C/C++ software developer myself and also with 10 years of experience already. I'm also not a game developer, but develop a highly optimized noninteractive data crunching engine (which makes hobby game development an interesting way to learn something new and gain more experience).

 

I don't want to comment on what you have written just because I agree with most of what you said. I wonder if there exist any professional C/C++ developers not using agile development methods or some its variation nowadays ;)

 

A good share of my efforts working on the ufo2000 codebase was spent on refactoring and making design more simple (that means removing global variables, hiding implementation details by changes visibility of some class members and methods to private, etc.). That was not so easy technically, as I usually did not have long contiguous chunks of time to work on the game (an improvement had to be completed, tested and all the work finished during weekend for example). Having long pauses is inefficient as you need time to catch up and remember everything before you can continue work (so two weekends have less value than 4 free days in a row). Working in small bursts resulted and difficulties doing heavy refactoring - I could not change too much in a single iteration. When having long holidays or vacations, I could do a lot more (check here for example: http://www.xcomufo.com/forums/index.php?sh...=5305&st=51). In addition, the game still needed user visible improvements in new releases, otherwise we could lose our already small user base. Also I tried my best to always have more people joining, that was much more fun than working alone :) They all had their vision, ideas and patches to code. As not everyone is a professional software developer here, some of the patches reduced code quality while introducing new features. It was my responsibility to review the patches to ensure acceptable quality of code. The hard situation was when a patch added some new nice feature, but had a lot of global variables added or exposed and used internal implementation details - in other words made design worse. Rejecting it completely could make contributor angry, explaining what exactly was wrong with the patch asking contributor to fix it sometimes worked, but sometimes did not (if the person simply did not understand the reasons). The last option was to fix the most obvious problems in patches myself and I did not always had enough time for this. So sometimes applying patch with no modifications (or minor modifications) and a hope to fix code later seemed like a reasonable solution. You can see my commits in SVN as 'serge' and later 'ssvb' login.

 

So I agree with all you have posted here, but not everything is so easy on practice. Maybe you will succeed in this crusade better :) In any case, having a help from a professional C/C++ developer is always welcome, it may revive the project. Now I almost don't have any free time at all to work on ufo2000, so the last release supervised by me was 0.7.1062. In next releases a lot more features have been added, but I heared that reliability degraded a bit. If I find some more time, I can have a look what's wrong with it. Anyway, I had also created a branch '0.8' (based on 0.7.1062 sources) and backported some bugfixes from later SVN revision, so this branch should be the most stable now. The plan was to release '0.8.x' version from it (where x is the head SVN revision number at the time of release), but unfortunately I never had enough free time to do that.

 

As for the game architecture, adding AI opponent is very important (in spite of some users telling that we don't need it :)). Not only that will add a new value to the game, it will also allow us to do automated testing when two AI players fight against each other. The game already has some error diagnostics code (and a lot of assert's here and there), the problem is that it requires human testers to do a lot of work and not everyone can analyze and reproduce the problem. Automated testing using AI opponents should make quality assurance much easier (though automated tests will not cover all the features that can be exploited by human players). Unfortunately, adding AI is not so easy, it will require some rather heavy refactoring more clearly separating control (right now it is either user interface with mouse/keyboard input, or a sequence of network packets coming from the remote host) and the code responsible for executing of these control commands.

 

Maybe even the whole engine architecture should be changed. Right now we have a state of game world stored on both client computers and it gets changed by getting network packets or executing user commands locally (always keeping game state in sync). A benefit is that network traffic is low. But we need precise synchronization and also this design is exploitable by cheaters (who can modify the game to see the whole map for example). Probably changing to a true client-server architecture makes sense now, where everything is simulated on the server and game clients work only as terminals. In this case we will need higher network traffic (which got a lot faster and cheaper over the last few years) and quite a capable and fast dedicated server. With a good design, both methods of client-server-client communication could be also possible (if the engine is properly isolated from the rest of code).

Edited by Serge
Link to comment
Share on other sites

<Snip> That was not so easy technically, as I usually did not have long contiguous chunks of time to work on the game (an improvement had to be completed, tested and all the work finished during weekend for example). Having long pauses is inefficient as you need time to catch up and remember everything before you can continue work (so two weekends have less value than 4 free days in a row). Working in small bursts resulted and difficulties doing heavy refactoring - I could not change too much in a single iteration...

 

Serge - I completely agree with the issue of small bursts. None of my comments were meant as a disparagement towards those of you involved with the code. I'm very impressed with the quantity of functionality in the existing product and the fact that bugs are few and far between. I came at my comments from the point of view of someone who wants to help but is concerned about where to start so as not to break stuff. I imagine alot of less experienced peeps who'd like to help are also in the same or worse position. If I can help with that, I'd be well pleased.

 

otherwise we could lose our already small user base.

 

Caught between a rock and a hard place - wanting to make the code easier for more people to work on but having to do a lot of the work to review input. Not a position I envy.

 

Also I tried my best to always have more people joining, that was much more fun than working alone :) They all had their vision, ideas and patches to code. As not everyone is a professional software developer here, some of the patches reduced code quality while introducing new features. It was my responsibility to review the patches to ensure acceptable quality of code. The hard situation was when a patch added some new nice feature, but had a lot of global variables added or exposed and used internal implementation details - in other words made design worse. Rejecting it completely could make contributor angry, explaining what exactly was wrong with the patch asking contributor to fix it sometimes worked, but sometimes did not (if the person simply did not understand the reasons). The last option was to fix the most obvious problems in patches myself and I did not always had enough time for this.

 

Yeah - the big problem. Keeping code to a high standard but keeping people involved is, I imagine, really hard. I enjoy mentoring people but I acknowledge that sometimes people cannot grasp the reasoning first time around. It took me a long time to absorb OO for example and I still feel like I'm learning - one of the things I'm hoping for with helping out is that I keep my OO skills at an acceptable level or try to push them further. However computing is a career for me so I'm keen to push myself technically. Others are more interested in adding features the best they can - I have to admire people for going to the effort when it's only a hobby.

 

So I agree with all you have posted here, but not everything is so easy on practice. Maybe you will succeed in this crusade better :) In any case, having a help from a professional C/C++ developer is always welcome, it may revive the project. Now I almost don't have any free time at all to work on ufo2000, so the last release supervised by me was 0.7.1062. In next releases a lot more features have been added, but I heared that reliability degraded a bit. If I find some more time, I can have a look what's wrong with it. Anyway, I had also created a branch '0.8' (based on 0.7.1062 sources) and backported some bugfixes from later SVN revision, so this branch should be the most stable now. The plan was to release '0.8.x' version from it (where x is the head SVN revision number at the time of release), but unfortunately I never had enough free time to do that.

 

Nothing is every straight forward. All I can hope is that I can help out.

 

As for the game architecture, adding AI opponent is very important (in spite of some users telling that we don't need it :)). Not only that will add a new value to the game, it will also allow us to do automated testing when two AI players fight against each other. The game already has some error diagnostics code (and a lot of assert's here and there), the problem is that it requires human testers to do a lot of work and not everyone can analyze and reproduce the problem. Automated testing using AI opponents should make quality assurance much easier (though automated tests will not cover all the features that can be exploited by human players). Unfortunately, adding AI is not so easy, it will require some rather heavy refactoring more clearly separating control (right now it is either user interface with mouse/keyboard input, or a sequence of network packets coming from the remote host) and the code responsible for executing of these control commands.

 

Maybe even the whole engine architecture should be changed. Right now we have a state of game world stored on both client computers and it gets changed by getting network packets or executing user commands locally (always keeping game state in sync). A benefit is that network traffic is low. But we need precise synchronization and also this design is exploitable by cheaters (who can modify the game to see the whole map for example). Probably changing to a true client-server architecture makes sense now, where everything is simulated on the server and game clients work only as terminals. In this case we will need higher network traffic (which got a lot faster and cheaper over the last few years) and quite a capable and fast dedicated server. With a good design, both methods of client-server-client communication could be also possible (if the engine is properly isolated from the rest of code).

 

I guess this can come later when all contributers feel more comfortable with the direction things could take. Hopefully we can get to the point of providing an AI. I'm not worried about it at present , just that I know that I'd like to get there eventually.

 

Andy

Link to comment
Share on other sites

Okay

 

So I have 24 patches (diff files) extracted from my own repository, which was based on the 1086 checkout. Each is best applied and checked to make sure the code compiles. In most cases this is sufficient testing as the changes make no change to functionality - simply the build. Some might want a little testing - often making sure the hotseat game works seems to have found most problems for me. However if my respository is the same as the trunk at the time of commit they should be okay.

 

Serge - let me know how best to achieve this. In some discussions I've seen comments about where to send diffs but found that the site was down. I notice however Mantis is back today.

 

Cheers

AndyS.

Link to comment
Share on other sites

any progress is good progress even if it isnt readily visible from the outside.

 

Yes, and repairing Mantis so that new users may report bugs and add comments would be extremely useful.

Why not have the forum and Mantis use the same DB so that people dont have to apply for an account twice ?

 

And also out of curiosity, I would very much like to hear about those 24 patches.

I guess they will not be merged into the trunk any time soon, as I think all the full commiters are busy with the personal stuff at the moment.

So if you dont mind giving out some details, it would be nice to learn sth.

 

I am also a full time dev of commercial apps with 2 yrs practice in c, c++ and java.

So this project is also my side "game dev experience".

 

And if anyone of the full committers went through my patches and has some problems with them, please let me know so I can correct.

Link to comment
Share on other sites

Guest Azrael Strife
any progress is good progress even if it isnt readily visible from the outside.

 

Yes, and repairing Mantis so that new users may report bugs and add comments would be extremely useful.

Why not have the forum and Mantis use the same DB so that people dont have to apply for an account twice ?

Because the database of the forum belongs to xcomufo and the admins are somewhat difficult to get a hold of.

Link to comment
Share on other sites

Okay

 

So I have 24 patches (diff files) extracted from my own repository, which was based on the 1086 checkout. Each is best applied and checked to make sure the code compiles. In most cases this is sufficient testing as the changes make no change to functionality - simply the build. Some might want a little testing - often making sure the hotseat game works seems to have found most problems for me. However if my respository is the same as the trunk at the time of commit they should be okay.

 

Serge - let me know how best to achieve this. In some discussions I've seen comments about where to send diffs but found that the site was down. I notice however Mantis is back today.

Yes, ufo2000.xcomufo.com is back online now (it was down because of some issues with hosting). Attaching patches in mantis is the preferred method right now. And don't hesitate reminding from time to time if your patches seem to be ignored, it really helps :) Anyway, if you go to ufo2000 bugtracker, search for word 'patch' and check issues with attachments, you will see that most of them have been resolved or there was some valid reason why the patch has not been applied yet.

Link to comment
Share on other sites

Yes, and repairing Mantis so that new users may report bugs and add comments would be extremely useful.

I understand your pain, surely reporting a problem with bugtracker because the bugtracker itself does not work for you is hard :) But please either contact me via PM next time (preferred way, though not quite obvious for sure), or start a new thread regarding this issue, I'll try to help you with solving this problem (most likely you have misspelled your e-mail, so just deleting your account if you want to keep the same login should help). Asking for support here just moves discussion to offtopic.

 

Why not have the forum and Mantis use the same DB so that people dont have to apply for an account twice ?

ufo2000.xcomufo.com and xcomufo.com are not completely the same, they are hosted on different servers.

 

And also out of curiosity, I would very much like to hear about those 24 patches.

I guess they will not be merged into the trunk any time soon, as I think all the full commiters are busy with the personal stuff at the moment.

So if you dont mind giving out some details, it would be nice to learn sth.

Well, you never know for sure, your guess may be completely wrong.

 

I am also a full time dev of commercial apps with 2 yrs practice in c, c++ and java.

So this project is also my side "game dev experience".

Great. It is really good to have more experienced people around.

 

And if anyone of the full committers went through my patches and has some problems with them, please let me know so I can correct.

Well, it would be much easier if I could find them in some way without doing extensive search. I'm sorry, but I rarely read all the new forum posts here on xcomufo.com. It just happened that I'm subscribed to notifications from this particular thread.

 

Anyway, I think it it is quite obvious that ufo2000 will benefit from getting more skilled developers with commit access rights who are able to move the project forward :)

Link to comment
Share on other sites

any progress is good progress even if it isnt readily visible from the outside.

no visible progress is always suspicious unless you have a firm confidence in the skills of the developers doing the work :)

Link to comment
Share on other sites

Okay

 

So I have 24 patches (diff files) extracted from my own repository, which was based on the 1086 checkout. Each is best applied and checked to make sure the code compiles. In most cases this is sufficient testing as the changes make no change to functionality - simply the build. Some might want a little testing - often making sure the hotseat game works seems to have found most problems for me. However if my respository is the same as the trunk at the time of commit they should be okay.

 

Serge - let me know how best to achieve this. In some discussions I've seen comments about where to send diffs but found that the site was down. I notice however Mantis is back today.

Yes, ufo2000.xcomufo.com is back online now (it was down because of some issues with hosting). Attaching patches in mantis is the preferred method right now. And don't hesitate reminding from time to time if your patches seem to be ignored, it really helps :) Anyway, if you go to ufo2000 bugtracker, search for word 'patch' and check issues with attachments, you will see that most of them have been resolved or there was some valid reason why the patch has not been applied yet.

 

Serge

 

Okay - so the patches I've worked on fix none of the bugs so how do you want me to raise a "bug" in mantis for "general code tidy up" and then add the patch files to that bug ? Or would you prefer me to raise a series of bugs, one per patch with details in the bug covering what the patch is trying to "tidy up".

 

I'm aware that some of the patches will conflict with stuff that is pending - i.e. the lighting in map for example, because I've modified most of the key classes albeit gradually patch by patch.

Link to comment
Share on other sites

Okay - so I've rolled all my local patches into one and checked they apply to 1086 and still build. I've raised a bug in mantis and added the patch file (all 9500 lines). It's a large patch.

 

Not everything in the patch was necessary - I've occassionally duplicated functions (when I didn't spot the existing one).

 

Note the layout.formatting will be incorrect in places - I think my eclipse environment is set to use tabs. I should have changed it back when I had done and reapplied the K&R formatting. I forgot. A quick sed 's/^\( *\)<tab>/\1 /g' should fix this (where <tab> is a tab character typed at keyboard - not all sed flavours accept \t) - sed .... file > newfile. A similar trick will work in vi.

 

I've started on the real work - moving x,y,z coordinate paramters to a class (cartesian3DPos - which is already in the patch) and hiding all the logic of x,y,z deltas behind vectors (using the same class). I've also introduced a cartesian3DGrid class that is templated. I see this class providing a container to be wrappered by the lighing interface, the troop movement interface, the terrain interface etc. Ideally each of these becomes a seperate class providing features to map rather than map being the bloat it is now. That way if you want to modify lighting (or fix it :-) ) then you'll know where to look.

 

Polar3DPos isn't used yet but it's there as a start point for hiding the shooting / raytracing stuff away.

 

Feedback appreciated but given it's non-functionality changes I don't expect anyone is that interested....

 

 

Andy S.

Link to comment
Share on other sites

Hi,

 

I would like to help with this project but I never explored the realms of programming. What should I learn first to get started?

 

Lud

 

Do you want to program or do you prefer messing with graphics etc. If you want to get in to programming choose a language. This project is based in C++ but that's not the most friendly language for beginners. If you want to learn C++ go with something like the book "c++ from the ground up" by Herbert Schildt and get Mingw and eclipse cdt. Mingw provides a free compiler (gcc) and eclipse gives you a decent graphical front end for development. Google for the later two software installs. Otherwise I'd suggest picking up a book on Java and starting there to learn about OO and programming in general before "cross-training" to C++. Either way don't rush things. Keep it simple and don't be dissapointed that you can't write the next big thing after just a few months. We all started somewhere - even if for some of us it's so long ago we can't remember where :-)

 

If you want to help with graphics or sound or level design then someone else is best placed to advise.

 

All the best whatever you choose to do.

Andy

Link to comment
Share on other sites

I'd like some comments about a major flaw I saw in this game even tough I know noting of conventional programming. That makes me unsure if its important or not. I noticed the game was slow on my computer and I think it might be because the application feeds 40 fps on average when it is totally unnecessary 99% of the time because it is a static, turn-base game. To save that huge amount of processing we might want to try to feed some kind of interactive-empirical virtual image instead of live video feed.

 

I'm not even sure if this makes sense but I felt it was worth the try.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...