Llyr
Forum Members-
Posts
83 -
Joined
-
Last visited
Llyr's Achievements
Sergeant (3/6)
0
Reputation
-
@serge 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: 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: 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 ^^)
-
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...
-
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...
-
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...
-
@ 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...
-
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...
-
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
-
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...
-
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???
-
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 ** 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...
-
is it possible you just don't really understand OOP?
-
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: 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*
-
hmm... it doesn't not seem to happen with svn version though... has this been fixed already??
-
i played around a bit, and that's what i found out about the crc error: it never happens if there is no shooting. you can do anything else. it does not happen every shot you make it does never happen with shots that dont hit tiles (go out of the map) it is more likely to happen for shots at greater distance whenever the error occurs following happens: player A hits tile X and destroys it. then switch to player B and watch modus: you can see player A hit tile Y (some other tile than tile X) another detail i noticed: if you can see your shots flying through walls, without hitting them, the error is sure to occur. conclusion: the problem seems possibly to be caused either by the collision detection, or by the flight path randomization. hope that helps more findings: just shot 5 soldiers from only one square distance. doing hit point damage (which is randomized too) does not cause it, so it has nothing to do with random number generation. if you turn down the shot speed in your options to 5, it never happens. the faster you set shot speed, the more likely the error is to occur. (!!!) conclusion: changing the speed of the shots, doesn't only change the display rate but also calculation depth, and therefore accuracy!
-
and these are from the game i just played... after first crc error, i did sometimes shoot through walls and stuff like that. and while the other player was playing, chat was displaying "___error in NID___" many times... need that stuff too? # Connected to server: lxnt.info:2001 # as user: Llyr # Start networkgame with: zeke * * Battlereport: 2006-01-27 23:59:59 * # Turn end: 1 # wrong wholeCRC: crc=55499, bcrc=48866 # Next turn: 2 killed: VSS killed: KPAL # Turn end: 3 killed: (+.+) killed: (^.^) killed: (>.>) # wrong wholeCRC: crc=5321, bcrc=25348 # Next turn: 4 killed: Shz3 # Turn end: 5 # wrong wholeCRC: crc=62477, bcrc=27956 # Next turn: 6 killed: Shz2 killed: Svh 3 killed: KPAS # Turn end: 7 # wrong wholeCRC: crc=2644, bcrc=20146 # Next turn: 8 killed: Shz1 # Turn end: 9 # Summary: YOU WIN! crc_error_2644.txt crc_error_5321.txt crc_error_55499.txt crc_error_62477.txt