Content
Status:
Lead coder in Defence Alliance ( http://www.planetunreal.com/da )
And I've written a little tool for html documentation creation ( undox was a bit too buggy :/ )
( http://www.uni-ulm.de/~s_dwaldh )
I like the output a bit more than that from uncodex. But I guess uncodex's parser engine is superior to mine. Maybe I'll try to make a real parser once, not that I already have enough things to do.
Well that statement is a few months old, I actually wrote a parser. It parses almost everything besides defaultproperties and code.
Rant about the Unreal engine
Although I haven't seen source of Unreal 2 or any other newer Unreal based game besides UT2003, I'm quiet sure that they all share a big portion of code. I'm seeing Unreal running in the wrong direction (codewise).
- The weapons... While the idea of havin firemodes doesn't look too bad after all, the implementation is awful. There's a lot of native code calling the different functions on the firemodes. Also, the number of firemodes are limited to 2. I guess only those 2 are handled native. Then again the attachment of the weapon which produces third person effects is also called natives (function broadcast which is a bit complicated in unrealscript). I assert that they were in a great hurry and therefore decided not to introduce new language features but hack it in native.
- The GUI... I liked the UT menus much more ;) But it's not only that, also the defaultproperties "inner class" hack. Real inner classes would've been a nice addition. At least they introduced delegates which, I think, is a inferior concept. Well I might be biased of being java coder and not C# one. In addition to the hacked "inner class" stuff they also made hacked "object instantiation" possible. As I already said my hopes are that they were in a big hurry.
UT1 had a much clearer concept for its time. While it's clear to me why the used unrealscript in Unreal 1 a switch to java in UT might have been a good decision. The would've had the decision of using a real java vm or use a bytecode interpreter just like with unrealscript. Of course it'd have been a brutal switch, and a lot of work to generate a new codebase. But...
There are alot of java compilers already out there which do their job very well. Not only compilers, all sorts of tools which makes the programers life easier.
I think that's also reason why there are more quake engine based games and mods out there. Now don't get me wrong, I am still coding in unrealscript but it's just the nature of people like me to complain lol.
There was also some "rectangle extends square" OOP thingy here earlier which might be useful to know when reading the discussion below.
Discussion
EntropicLqd: A lot of the ideas within the Unreal Engine are pretty good but they always seem to break them when they implement them. My fave example is the Controller-Pawn mess. It could have been a very nice, clean separation of master and puppet - but noooo they had to duck-tape the master's fingers to the puppet strings, and tie the puppets head to his hand.
- Delegates in UnrealScript are very cool. I've not had the chance to play with pointers to functions (a blast from my C past) for a long time so it's nice to have that facility back It's a shame they didn't make more use of them in the main stream of the code. I've always been of the opinion that InnerClasses are just plain ugly although I understand the rationale behind them.
- There are more Quake engine based mods around for two reasons I think. Firstly, overall the player base is larger - which means there are just more people around to make mods. Secondly the mods are written in C/C++ and compiled down into DLLs (at least they were last time I made a mod for the quake engine - Quake 2). Programming in C/C++ is perceived to be way more "cool" than programming in Unreal Script. Especially as most games companies want people who know C++.
Mychaeel: Welcome to the Wiki, Danke. :-)
Tarquin: hi there. :D welcome to the Wiki.
ZxAnPhOrIaN: Welcome aboard and welcome to the wiki! :) :tup:
Dante: Oh guys, you're too fast ;)
ZxAnPhOrIaN: I look at the Recent Changes, at average, every 15 minutes! ;)
EntropicLqd: There is only one true style of coding your barbarian - it's mine - Mwhahahahah ;) Once you realise how pointless arguments about coding style really are they can be used to great effect on a Friday afternoon when basking in the afterglow of a lunchtime visit to the pub. "Why aren't you lot working?" – "We are, we are discussing some problems with the coding standards". :)
Tarquin: Seeing as a square is a special case of a rectangle, I'd say that specialization would agree with you, and have rectangle as the parent class of square. (and Quadrilateral as the parent of rectangle ;) )
Dante: Yeap, but Specialisation says: A rectangle is a just a square with one side-length differing from the other. It may not make sense in this case, but specialisation rule tells to do so...
EntropicLqd: What rule book on Specialisation are you reading Dante? I'd be interested to see the justification that a rectangle is a special type of square rather than the reality, which is that a square is a special type of rectangle.
Dante: Those aren't my rules, and I wouldn't do it, but it's what I learned from "practical computer science". Specialisation means, to add "information" to an sub-class. And storing a square needs less information ( 1 var ) than storing a rectangle. Thus a rectangle is a square with 1 additional side. It's not the way I would do it, but that is the way to go if you follow specialisation-specs. ( Which was what we had to do in exams ... ). I don't mean to say that specialisation is bad, but taking square and rectangle as example is dumb.
Bjorn: What about the "is a" relationship that should exist between an instance of an object and its class and all the superclasses of it? Like a PlayerPawn is a Pawn. Surely, you can say a Square is a Rectangle but not that a Rectangle is a Square.
Mychaeel: In OOP, that's a bit tricky. In fact, in OOP you'd rather subclass "Rectangle" from "Square" since the concept "rectangle" extends the concept "square" by the ability to have different side lengths...