Remastering
Andrew Jenner
Wow, I didn't realise there was so much discussion on the Sopwith.org
message board or I would have checked it more often. Unfortunately
I've been pretty busy lately (moving house) but I'll try to check more
often.
First up, Jornand de Buisonjé has apologised to me in email for
insulting the Digger source code - I'm sure he didn't mean to be nasty
(although his message on this board did come through sounding a bit
like that). I am entirely in favour of constructive criticism,
although, like anyone, I prefer it to be interspersed with praise for
the bits that don't need criticising. :-) We're all on the same side
here - we all want the same things.
And if the truth be told the Digger source code is in a bit of a state
at the moment - the documentation is out of synch with the code, the
code is all tangled with #defines because most of the ports share the
same codebase, and the 16-bit DOS version is difficult to compile
because of all the optimisations. The only reason that the Digger
source code isn't clearer is that I don't have the time to sort it out
at the moment. I won't make any apologies for keeping parts of it in
assembly language (since translating it into C would not yield any
portability advantage - those are the low-level non portable bits -
and would just make it larger and slower). It can't be that bad,
anyway - since it has been successfully ported to several other
platforms.
I also won't apologise for not using C++. Don't get me wrong, I love
C++ - I've been learning it this summer and I think it's far better
than C for most purposes (particularly large projects involving
multiple programmers). However, there do not seem to be any C++
compilers conforming to the latest standards which tuned for making
small, efficient, 16-bit DOS executables (hardly surprisingly - the
market for any 16-bit DOS compiler is very small). I genuinely did get
a 40K DOS executable with BC++ 4.52 for "Hello, World!" (and I did
turn debugging information off). The problem is that the libraries
aren't written well - there are a lot of static objects so parts of
the library which are never used get linked in even though they are
not needed. In my opinion making the program the most useful for the
most number of people is more important than making life easy for the
programmers (at least, while there are more users involved than
programmers!). I don't remember saying any insulting things about C++
in general, though. If I did, I take them back.
> 1) Will the source code to the new Sopwith be clearly written, as
> opposed to what happened to Digger (where the source code could
> have won several awards at the International Obfuscated C Code
> Contest)?
I'll do my best. I tried to enter the Digger source code to the IOCCC
but it's too long :-)
> 2) Will there NOT be any sort of fake object-oriented hierarchy
> illusion by creating a substantial amount of header and source
> files of which their meanings and relations are unclear?
Not really sure what you mean by this. I will try to set out the code
in a logical way. I'm beginning to think that it would be a good idea
to make 2 versions of Sopwith 3 - a minimal version for 16-bit DOS
(using more-or-less the current C and assembly) and a full version for
all other platforms (rewritten in C++, and possibly some assembly, for
some platforms).
> 3) Will assembler instructions be limited to the absolute minimum
> necessary (for example for keyboard addressing schemes), and if it
> does will it be seperated from the game logic, so that porting will
> be relatively easy?
Absolutely.
Jornand wrote in an email:
> I think my e-mail address works this time. It took me 6 days to find
> out that you couldn't reply and that you decided to respond directly
> in alt.games.sopwith
I wondered how long it would take you to notice!
> The purpose of reverse engineering, as far as I think it should be
> in this case, is to determine the exact and complete functionality
> of the game. In Sopwith we fully want to determine the workings of
> (at least) the following three features in particular:
> 1) How the multi-player was supposed to work in the first place. I
> guess this is more out of curiosity than necessity, except maybe if
> you want to achieve 'historical' accuracy when remastering the game.
Historical accuracy is something I am aiming for.
> 2) The plane physics and aerodynamics. This is probably the most
> important part, because it directly influences the (sacred) game
> play. In other words we want to get the exact same feel out of the
> new game as with the original (which you already mentioned in your
> thread).
> 3) The enemy player logic (and the auto-pilot). To many persons in
> the world, this must have been their first contact with a reasonably
> sophisticated AI. It's obvious 'we' want to see it back (and
> hopefully improved) in a new version. By the way can you give me an
> abstract description of how it's implemented, does it use production
> rules or something similar?
It's basically a minimax algorithm - the computer calculates all the
possible things it could do (nothing, climb, fall, accelerate,
decelerate) and looks at the outcome of each. If the possibility
causes the plane to get closer to its destination, that possibility is
weighted high. If it causes the plane to crash, it is weighted low.
The highest weighted possibility is the chosen one. There is a
complication, however - the destination the plane aims for isn't
necessarily it's final one - it is a point in front of the plane (if
it's going in the right direction) at a certain height above the
ground if the plane is far away from it's final destination. There are
many other subtleties, and the algorithm for Sopwith 2 is different
from that of Sopwith 1.
> As you can see, none of the above refers to a specific code. This
> means that the reverse engineered code isn't holy on itself. It
> should, in my opinion at least, merely be used to determine the exact
> working of the program. The next step then should be to construct an
> abstract specification of the program (a human readable, yet formal
> and unambiguous description of the game) based on your code. Based on
> this abstract description you can rewrite the program from scratch
> using any programming languages you like.
You think I should translate the code two more times before using it?
That seems a bad idea to me - every time it gets translated, errors
can creep in. The only use for this "formal description" method is in
clean-room cloning. Since there are no intellectual property issues
with Sopwith this is not needed. I do intend to rewrite most of it,
but in a gradual fashion, so that I can find bugs as I make them by
continual testing (such a pain in the neck, having to test it at every
stage... :-)
> This gives the added advantage of easily implementing improved
> graphics and sound, because, with all due respect to your coding
> abilities, adding them ad hoc to existing code which originally
> wasn't designed for such features will inevitably result in
> spaghetti code.
Only if let it. If I rewrite it a lot, that shouldn't happen.
> A third advantage is, that others can also write different
> implementations based on your 'respecification' and that the game can
> also be ported to different platforms with relative ease.
I don't think portability will be a problem. This "respecification"
would be of some use in porting to different *languages*, but not
different *platforms*. C(++) is what I know, and is pretty portable,
so I will stick to that.
> In other words, I recommend
> you should change from an ad hoc to an top-down approach.
My method isn't ad-hoc. I am planning ahead and trying to figuring out
the best way to go about this.
> Come to think of it, we would also get rid of some seriously
> out-of-date properties we can do without, like pixel-wise collision
> detection (which clearly violates the principle of separating game
> logic from screen graphics).
I like the pixel-wise collision detection - it means you can pull off
really great stunts if you're good! There is, however, a problem with
recording a game and playing it back with different shaped planes. So
(given that I don't want to give up pixel-wise collision detection) do
you think the collision detection should use the original planes or
whichever ones happen to be in use?
> BTW, I've read you're working on an automatized reverse-engineering
> system. I'm very interested to know more about it. Can you supply
> some details about it?
I intend to write a decompiler based on some of the ideas presented at
http://www.svrc.uq.edu.au/groups/csm/dcc.html and some ideas of my
own, which have come to me through doing this sort of thing by hand.
Unfortunately, automatic decompilation is impossible, so my decompiler
will have to be interactive - when the computer finds something it
doesn't know what to do with, it asks for help. So far I have written
(in C++) most of an instruction decoder for a disassembler. The whole
thing is not entirely baked at the moment, though.
Andrew