Jump to content
XCOMUFO & Xenocide

X-com An Open Source?


uncy

Recommended Posts

Hi guys,

 

I would like to know if it is even possible to get the source code, I don't know, perhaps the utilities employed to program this legendary game.

 

I get very frustated when trying to Mod Xcom and then I can't really make heavy changes without crashing the game...

 

Thanks for your time ;)

 

Uncy

Link to comment
Share on other sites

I'm not sure how successful the guys at strategy core were. They would have to decompile the game or request the source from the owner. I doubt a company would just hand over an asset.

 

Optionally, you could turn to already developed open source games that pertain to X-com. There is UFO2000 for your 2D interest and 3D games such as UFO AI. If you know c++, you can help program either of the two mentioned.

Edited by Kratos
Link to comment
Share on other sites

I highly doubt they'll ever release the source code (bar a tiny snippet of C code that was left in one of the alien base map files in an earlier release of the game).

 

As for what they compiled it in: I seem to recall it was the Watcom C compiler. That link takes you to Open Watcom.

 

- NKF

Link to comment
Share on other sites

Guest Azrael Strife
Besides, now that Take Two owns the rights, and with all these rumours of a new X-Com game, there's even an even lower chance something like that would happen.
Link to comment
Share on other sites

aaaww, how sad... Just imagine the modding if they could only make it an open source... :innocent:

 

Anyway, i play UFO2000, but I can't really "feel" that I am playing Xcom, It does not have most of the original game's features I love the most...

 

All other Xcom sequels have fail to give me the excitement I still get from EU and TFTD, that simple...

Link to comment
Share on other sites

Forget about decompiling there are none that can handle that much code.

 

You want the code, learn asembler and disassemble it. THEN comes the hard part.

Link to comment
Share on other sites

Besides, now that Take Two owns the rights, and with all these rumours of a new X-Com game, there's even an even lower chance something like that would happen.

Add to that the fact that it's still being sold (on steam I believe) and I think it's even less likely.

Still anything's possible. If you're serious about it, try e-mailing Take Two, and see what you get. At worst, they'll just ignore you.

Link to comment
Share on other sites

If there is a chance to sell the game, Take Two will only sell the game to another company (does that means the source too??) that would be willing to "develop" a Xcom like Game. In my dreams this would be possible; but one never knows...
Link to comment
Share on other sites

  • 2 weeks later...
Forget about decompiling there are none that can handle that much code.

 

You want the code, learn asembler and disassemble it. THEN comes the hard part.

There is someone on the X-COM wiki (I'm not going to name names) who is using Microsoft Visual/Quick C/C++ to decompile certain parts of the game executable into understandable C code. For those with a C background, it shouldn't be too difficult to understand, but it's beyond my limited programming skills. Not sure how I feel about decompiling. On one hand, I'd love to understand the mechanics of the game, but on the other hand, it's basically cheating (and probably illegal from Take 2s standpoint). All the info I gather from the executable is by looking at the numbers and editing them to see what changes. ;)

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

I would not mind having to decompile the whole game! ;) But it's not a 1 person job, I believe the amount of work decompilying or deassembling the game is huge. I don't think it will be cheating, since, for example, Zombie knows almost everything one has to know in tactical missions!
Link to comment
Share on other sites

Hmmm, it seems not even the SC staff has been listening to me. :P

Here's what we know at this point... actually, before we begin, I'd like to point out I'm too lazy to give any links. If it's not absolutely necessary, I'd rather not waste time on searching for them (again). Anyway, back to the issue at hand:

1.) Take Two has no source code. In fact, they got nothing from Atari except the raw IP, i.e. the rights to the franchise. No source codes, no concept art, nothing. Like us, they too want the source code. We want it, not only because of modding, but also because it (CE version) is not working on Vista, and the further we get in time, the less likely it is to work.

2.) We know that Hasbro had it. How? They recompiled it for Windows, and in fact, I got confirmation from Dave Ellis that they had it.

3.) We don't know is whether or not Atari got it, and if they did, why didn't Take Two get it. Though I'm leaning more on Atari not getting it.

4.) So this is a pretty bad situation, because the source code is most likely lost. Most likely? Well, it's possible that one of the people who worked on the games still has it, but it's a very, very long shot. I suppose you could try e-mailing them, although I doubt they'd be able to release it, even if they had, due to legal reasons. They could give it to Take Two, though.

5.) The chances that you'd be able to reassemble the game are... slim. Obviously, if you have nothing to do and are a masochist, you could go and do it, but the assembler code is long, very long and making sense of it will likely prove to be difficult. Disassembling the game is no problem, it's literally a click of the button, but putting it back... oh boy.

6.) Let's assume that Take Two somehow got the source. What are the chances that we'd get our hands on it? Difficult to tell. They have been selling both TFTD and UFO recently. With those rumors going around, it could be a test balloon. In fact, Game Informer reported TFTD was selling very well, so if they are planning a new X-COM game, it will certainly encourage them. I'll take this opportunity to repeat that Take Two has stated that it's illegal to download any of the games in the series. Besides, if you do have the money, and they are planning a new game, it would be shooting ourselves in the feet since we'd be decreasing the number of games sold and they'd be less likely to make a new one.

Anyway, even if they did have the source, they would not be releasing it for the above mentioned reason, and if they are planning a new game, then a Collector's Edition would be possible as well, so again they wouldn't want to release the source. After that? Well it would be possible. It's quite old and it could certainly benefit both from modding and stomping out bugs.

7.) About Take Two selling the game to someone who would develop it. I'm pretty sure that's not how it works. There's two possibilities here. They would give it to one of their own studios to develop it, or license it to an external studio. In both cases, I'm pretty sure it would be for "free".

8.) Would decompiling it be illegal? Well, technically it's reverse engineering, which I think at least borders on illegal. You certainly couldn't release it to the public without Take Two's consent. In fact, I'm pretty sure that the only thing you could do is to give the code to them, but I think they'd be pretty suspicious if you tried e-mailing it to them (because of the possibility of it being a virus).

 

I have a few developer e-mails, and once I get some time, I'll try e-mailing them, I've been meaning to do some sort of interviews anyway, so it wouldn't hurt to ask.

Link to comment
Share on other sites

I barely even read the newspaper these days. :D Kind of had a feeling the source went missing somewhere along the line.

 

Back then (and I mean waaay back), I wonder why the owner-of-the-week didn't take a leaf from iD Software's book when they released the source for their DOOM series. Players still had to own the actual content, but the flurry of updated executables and fixes (not even counting the numerous existing mods)and extensions to it (like jumping!) that came out after that prolonged the life of the series a bit past its use-by-date and showed there was still a lot of interest amongst the fans.

 

But I guess since X-Com had a more niche following than a heavy hitter title like Doom, it probably wouldn't have fared as well in the same situation. That is, back then. Today? Who knows.

 

- NKF

Edited by NKF
Link to comment
Share on other sites

I swear I would buy X-Com 3 times if they make the source available ;) who is behind me?

 

Anyway I can dream, can't I?

 

About the newspaper, I stop reading it when I realized I could read less Biased info in wikipedia. :P

Link to comment
Share on other sites

8.) Would decompiling it be illegal? Well, technically it's reverse engineering, which I think at least borders on illegal. You certainly couldn't release it to the public without Take Two's consent. In fact, I'm pretty sure that the only thing you could do is to give the code to them, but I think they'd be pretty suspicious if you tried e-mailing it to them (because of the possibility of it being a virus).

Reverse engineering and thus decompiling and "recompiling" by one person is illegal. What is legal is to decompile the game, write a documentation on how the code works and then give this documentation to someone else who then would have to write his own code based on the documentation. Any contact between engineer 1 and engineer 2 is forbidden to ensure that no particle of the original code goes into the new code.

Edited by Mad
Link to comment
Share on other sites

Reverse engineering and thus decompiling and "recompiling" by one person is illegal.

In most cases, yes it is. It isn't illegal however, to decompile the game in order to fix compatibility problems (such as X-COMs CE vs. Vista). That is allowed under most statutes. :P

 

- Zombie

Link to comment
Share on other sites

Well, its a concession the game makers made to the consumer. See, most games makers usually refuse to do anything to the game once it is out. It's not that they don't want to fix the problems, it's because they can't as it would cost too much money to get some programmers back in to recode the areas which are causing the headaches. Imagine buying a game and after installing it you realize it is incompatible with your system. You could try contacting the original developer for support. but they probably will ignore you if the title is more than a year or two old. So what other recourse do you have? Could return it, but what if you really want to play the game? That leaves modding. =b

 

- Zombie

Link to comment
Share on other sites

What is legal is to decompile the game, write a documentation on how the code works and then give this documentation to someone else who then would have to write his own code based on the documentation. Any contact between engineer 1 and engineer 2 is forbidden to ensure that no particle of the original code goes into the new code.

 

Actually, that is good enough. With a thorough and accurate description, I could be engineer 2 all by myself. The monkey-wrench here is the decompiling; good luck. I'd love to have a decompiler that would give me, say c-code (even with variable/function names like function001, function002, etc.). But there is no such animal (well, one that could do the job with XCOM with a click of the button). So we're stuck with disassembling instead and Gimli said it best:

 

if you have nothing to do and are a masochist, you could go and do it, but the assembler code is long, very long and making sense of it will likely prove to be difficult. Disassembling the game is no problem, it's literally a click of the button, but putting it back... oh boy.

 

Question: Is disassembling the game, placing the result in, say, a word document, and posting it, illegal?

Link to comment
Share on other sites

Question: Is disassembling the game, placing the result in, say, a word document, and posting it, illegal?

I'm not sure, but I guess it alone would not be illegal. BUT Then how can the 2nd engineer claim he has never seen the source?

Link to comment
Share on other sites

In the US, we are all innocent until proven guilty. Posting the source to a game would certainly land engineer #1 in pot of very hot water (assuming the company who owns the rights to the game wants to take legal action). And the site where he posted it would probably be forced to remove or edit the post or face being shut down. That doesn't prevent engineer #1 from emailing his friend, engineer #2, with the disassembled code. Of course, emails can be traced and basically anything you do on your computer can be recovered if deleted... ^_^

 

- Zombie

Link to comment
Share on other sites

Well, as far as I'm aware it all depends on where you post it. by where I mean the location of the server. Now don't quote me on that, but as I recall a good deal of illegal content (warez) is on the internet, because it is hosted on a server in a country that doesn't have laws against it. So theoretically you could upload it to a server located in such a country and nobody would be able to do anything about it. but you'd have to know a country's law for that.

 

About the source: I'll repeat what I already said. Disassembling can be really easy. Microsoft's Visual Studio 2005 has the MSIL Disassembler which you could use to get CIL (common intermediate language == assembler level programs). However it doesn't work on everything, I assume it's for .NET programs, but I've never tested it. There are other programs out there that will get you assembler level code. Making sense of that and creating C code is a huge task. UFO Defense (CE) disassembly gives over 200 000 lines of code. In comparison, Doom 3 was mentioned to have 500 000 lines of code (not assembly level though). So I guess it would be a huge effort to put things back, and even then you wouldn't get a very nice version of it. I'll go out on a limb and say that I think it would be a lot easier to just start from scratch.

Edited by Gimli
Link to comment
Share on other sites

if this were legal. First, xcom1 and xcom2 are different but very similar. Gosh it'd be nice to have those disassembled and to start with the differences as keys to the rest. It would be a big job, if only we had a lot of people. But where on internet can we find a lot of people. where oh where hmmm?

 

 

wait!

 

anywhere! :)

 

 

To be sure its a MAMOTH job but maybe just maybe it can be split up to managable portions.

 

There is someone on the X-COM wiki (I'm not going to name names) who is using Microsoft Visual/Quick C/C++ to decompile certain parts of the game executable into understandable C code.

 

 

Microsoft's Visual Studio 2005 has the MSIL Disassembler which you could use to get CIL (common intermediate language == assembler level programs).

 

:doh:

Link to comment
Share on other sites

About the source: I'll repeat what I already said. Disassembling can be really easy. Microsoft's Visual Studio 2005 has the MSIL Disassembler which you could use to get CIL (common intermediate language == assembler level programs). However it doesn't work on everything, I assume it's for .NET programs, but I've never tested it. There are other programs out there that will get you assembler level code. Making sense of that and creating C code is a huge task. UFO Defense (CE) disassembly gives over 200 000 lines of code. In comparison, Doom 3 was mentioned to have 500 000 lines of code (not assembly level though). So I guess it would be a huge effort to put things back, and even then you wouldn't get a very nice version of it. I'll go out on a limb and say that I think it would be a lot easier to just start from scratch.

This is the casew only if the program comes with disassembling information. AFAIK this would be the case in a debug build, but I'm not sure. However, disassembling of a normal program into assembler code is always easy, but I do not know anybody who would be able to interpret x86 assembler code in such a quantity. Do not make the mistakes of drawing paralells between a x86 assembler code and that of a let's say 6502 microcontroller. x86 architekture is far more advanced and uses many many more registers, which makes reading assembler code quite difficult. The language itself is very easy, which makes it very hard to see complex relations in it. A single c code might result in a dozend assembler calls. Just look at this and tell me you know what's going on:

 

_sum:
pushl %ebp
movl %esp, %ebp
movl 12(%ebp), %eax
movl 8(%ebp), %edx
popl %ebp
addl %edx, %eax
addl %eax, _accum
ret

Plus, if the coding was bad, it is even more difficult to re-assemble a program...

I guess you would really have to be a masochist. A masochist with a lot of time on your hands... ;)

Link to comment
Share on other sites

Look, there are a whole lot of diassembling utilities. There are ones you can find if you work with warez/cracking stuff (one of them is SoftICE) or more formal tools like OllyDbg for windows. Linux distros also have such a utility, or you can download one yourself (like lida). You can also use symbolic disassemblers (like PEDasm.

 

Getting the assembly code is really easy. The difficult part is to understand it. Thinks can get more compicated if the developers choose to obsfucate it for security (there are good reasons NOT to, but it depends on a lot of factors, sometimes it's even beneficial). Understanding assembly code requires a good understanding of computer architecture, assembly "programming" by itself is not enough. You also have to be good at organizing information, so that you can sum up the different "subroutines" you've understood.

 

There are some tools that create C (or C-like) source from assembly code, but their abilities are minimal. You can have a look at:

 

http://boomerang.sourceforge.net/

http://www.backerstreet.com/rec/rec.htm

 

I'd say that your success on reverse engineering assembly code to C source is really a matter of patience and time (and of course experience, which implies time). People who have understood the different .dat files that the x-com games use have done a wonderful job already!

 

edit:

Actually Mad, the x86 architecture has a SMALL number of registers (16 IIRC), compared to MIPS for example (which uses 32).

The big difference is on the ISA (Instruction Set Architecture). At university you are usually taught the MIPS architecture because it uses the Reduced Instruction Set. You have a lot of registers, you load stuff on the registers, you execute a SIMPLE instruction, you store the info back to the memory.

 

On the contrary, x86 is CISC. A simple instruction will probably be translated to a lot of low-level functions. In addition, a lot of CISC instructions can possibly be translated to a single line of C source code.

 

Just write a simple sorting program in C and then try to write it on MIPS. It's a lot of work for me at least (now, I'm supposed to do it easily later). Now, move to a CISC ISA. Fuuuuuun :P

Edited by kafros
Link to comment
Share on other sites

Yep, as I said, too much work. I had worked with a bunch of assembler level programs in the university and it's a lot of work to do something more advanced with them. Not that it stopped Richard Garriot from making games in assembler... show off. :P

A lot of the instructions I've seen in the disassembled UFO at least look familiar, and compared to some other assembler languages I've used it looks a whole lot more understandable. It has strings people, strings! :D But as I said, you'll have a lot easier time just making the game from scratch in C. Or even better in C++. How difficult could it be? The Gollops made practically all the code and design on their own. Then again, depends on how much time and will you have.

Link to comment
Share on other sites

Actually Mad, the x86 architecture has a SMALL number of registers (16 IIRC), compared to MIPS for example (which uses 32).

I wasn't talking abaout MIPS, I was talking about microcontrollers like the 6502! (There the assembler code is understandable)

Link to comment
Share on other sites

Just look at this and tell me you know what's going on:

 

_sum:
pushl %ebp
movl %esp, %ebp
movl 12(%ebp), %eax
movl 8(%ebp), %edx
popl %ebp
addl %edx, %eax
addl %eax, _accum
ret

 

20?

 

Thinks can get more compicated if the developers choose to obsfucate it for security

 

I doubt they would have. Software companies do this because some of their compeditors are masochistic enough to wade through the assembly. One would assume that these companies consider the effort financially worth it with respect to the bottom line. Maybe the approach they use is to look for repeating lines of instructions, groups, patterns and so on, in order to parse the data into managable buckets and then go line-by-line? Would knowing which compiler they used help?

Link to comment
Share on other sites

Just look at this and tell me you know what's going on:

 

_sum:
pushl %ebp
movl %esp, %ebp
movl 12(%ebp), %eax
movl 8(%ebp), %edx
popl %ebp
addl %edx, %eax
addl %eax, _accum
ret

 

If I read it correctly, it's a function that takes two integers (I think longs), call them X and Y, and returns (X + Y + _accum), where _accum is another a static variable.

Sorry, all I know about x86 assembler is what I picked up reading some books some years ago.

 

FWIW, there are a couple of books out there which discuss how to decypher the assembly code produced by C/C++ compilers.

John Robbins' "Debugging Applications" has an excellent chapter on this.

Exploiting Online Games: Cheating Massively Distributed Systems (Addison-Wesley Software Security Series) also has a some chapters devoted to this.

 

Maybe the approach they use is to look for repeating lines of instructions, groups, patterns and so on, in order to parse the data into managable buckets and then go line-by-line?

Quite correct, the above books say that many C/C++ programming constructs result in the compiler emitting standard runs of assembly.

So in principal, it's not too hard to recognize function entry and exit points, and the number of parameters being passed. And the standard loops are also recognizable. That said, when the compilers start doing optimization tricks, moving code around, it becomes more difficult.

However, a compiler from 92/93 probably isn't going to be THAT sophisticated in it's optimizations.

 

Would knowing which compiler they used help?

Probably. Especially if the person doing the disassembly can get their hands on the compiler and the library.

Two reasons.

1. Given the compiler, the optimisation tricks and the standard patterns it uses should be known.

2. There will be a copy of the libraries it uses (comes with), so some tools can do a (partial) analysis of the code, and identify at least some of the library functions in the disassembly, which reduces the manual workload.

 

Look, there are a whole lot of diassembling utilities. There are ones you can find if you work with warez/cracking stuff (one of them is SoftICE) or more formal tools like OllyDbg for windows

Yes, OllyDbg is a fantastic tool.

Edited by dteviot
Link to comment
Share on other sites

Amazon must be monitoring my posts. I logged in a few minutes ago, and it immediately recommended a bunch of books on reverse engineering and disassembly. Spooky.

Wow, that is spooky! Do you use the same login name or something?

Link to comment
Share on other sites

However, a compiler from 92/93 probably isn't going to be THAT sophisticated in it's optimizations.

 

Back then the code was probably not object oriented but procedural; good ,bad, or it doesn't matter for reassembly?

Link to comment
Share on other sites

Amazon must be monitoring my posts. I logged in a few minutes ago, and it immediately recommended a bunch of books on reverse engineering and disassembly. Spooky.

Wow, that is spooky! Do you use the same login name or something?

I don't think so. IIRC, it uses my e-mail address as the ID.

However, a compiler from 92/93 probably isn't going to be THAT sophisticated in it's optimizations.

 

Back then the code was probably not object oriented but procedural; good ,bad, or it doesn't matter for reassembly?

Honestly, I don't recall. It's been a while since I read the texts. I think the second one did have some bits about C++ vs. C, and said that C++ is a bit harder, but not hugely so.

Link to comment
Share on other sites

Well, unless Watcom was a really bad compiler, I would assume that it would check the extension of the file. I just tried compiling a C file filled with some C++ code in DevC++ and it doesn't work. Since all the source files in UFO Defense had the .c extension, I think it's safe to say that they were purely C, and C is a procedural language so no OO design there.

As I recall, the first "version" of the ISO C++ was made in 1989, so it would have been quite unlikely for games to use it in 1992/1993. Must have cost a pretty dime, too. :/

Link to comment
Share on other sites

Well, unless Watcom was a really bad compiler, I would assume that it would check the extension of the file. I just tried compiling a C file filled with some C++ code in DevC++ and it doesn't work. Since all the source files in UFO Defense had the .c extension, I think it's safe to say that they were purely C, and C is a procedural language so no OO design there.

Interesting. How do you know the names of the source files? And that Watcom was the compiler used?

Although IIRC, around then Watcom was the compiler of choice.

Link to comment
Share on other sites

And that Watcom was the compiler used?

Although IIRC, around then Watcom was the compiler of choice.

Because the executable says Watcom was used as the compiler. NKF mentioned this a few posts above as well. ;)

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

The file names are actually written inside the disassembled code. :D I'm not sure why exactly, perhaps upon linking it checks that the files are there. Or perhaps it used for the execlp command or the like, couldn't really say. In case you have no idea what I'm talking about, linking is the part of the compile process which is important for programs separated into multiple files. You can use header files to sort of connect them. For example, let's say that you have two files: one.c and two.c. Now let's say that one.c contains your main() function. What you do is to make an include file called two.h and in it you place the function prototypes used in two.c. if you did everything right, all you need to do is to make an #include <two.h> preprocessor command in both one.c and two.c and you can now use functions from two.c in one.c. I started playing around with this sort of thing in C++, and boy is it awesome. Plus, it drastically reduces compile time, because changes inside the functions of one file will usually not matter to the other (unless you did something wrong). So only the file(s) you changed need to be recompiled.

Execlp is a command that sort of executes one file within the other. To tell you the truth I've only used it once, so I don't remember exactly how it works, but the UNIX-like platforms have it written in the man(ual).

 

Err... ramble over. ;)

Link to comment
Share on other sites

Splitting a large source into multiple files was the bees knees when I finally figured out how to do it. I guess it's probably the closest thing you got to object oriented programming during the good old procedural programming days, along with the humble Struct - at least before the concept of self contained data or data hiding emerged.

 

I think the source file names were kept behind for debugging purposes, although not sure if it's for the compiler or for when the game conks out and reports that something went wrong at the n-th line in whatever.c. As it is the game just dumps memory when it crashes.

 

- NKF

Edited by NKF
Link to comment
Share on other sites

@Gimli: And that's why people work with projects, it's easier to track changes and you only have to recompile the changed file. For command-prompt fans, Makefiles ftw! Although I prefer Dev-C++'s projects :P

 

@NKF: That's more like Data Structures theory (Encapsulation, Data hiding, code organization, etc etc etc). Of course when you get into things you notice that Object-Oriented programming and Data Structures are close... dangerously close :P. And the reason is simple :)

 

@Anyone: It seems that Borland had C/C++ IDEs around 1990, I wonder if they were used for game development. I didn't find any related articles with a quick internet search. :/ It would be educational to get some info on that matter :)

Edited by kafros
Link to comment
Share on other sites

Yep, I had some university lab work a week or so ago, that was sort of a continuation of the last lab assignment I did. I got some "criticism" for the first one, because I didn't split the exception handling class from my matrix class. So in the meantime, I got a bit more familiar with separating files, and the second lab has a whole lot better design. Not that it's some incredibly good piece of code, but hey, I'm a beginner when it comes to C++. ;)

And yes, I've used a project, didn't work otherwise. Can't say I really had much chance to practice OO design yet, but there will be time for that, too. :)

Link to comment
Share on other sites

It's really only in school where you see one-file source code.

 

My tiny little unfinished starting base editor (found elsewhere in these forums) for example has something like 60 files, I have a separate .c/.h for every major struct.

 

Gimli, if the executable mensions the source files in the disassembled dump, does it then give any clues as to where one file starts and ends. I'm thinking about it adding another layer to parsing the whole mess.

 

By the way if you have battlescape and geoscape disassembled can I (NOT) ;) have a copy?

 

Do you have them for both Xcom I and II?

Link to comment
Share on other sites

Unfortunately, it's the trial version which doesn't allow exporting. Still, they gave you all the links. I forgot something, though. This is the CE version, so it uses some Windows .dll's and uses DirectDraw. Or does it? I forget.

Also, there's something else that I forgot to mention. As you know, the include directive basically copies the included .h (and .cpp if there is one) into the file that included it. So... I'm pretty sure they included some standard headers. I'd say iostream, but unless I'm mistaken, it's for the console. Anyway, if you take a look at those headers... you won't have nice time reading them. Although... if you made a small program that uses the same header the game does, then the disassembled code of the header should be very similar, if not completely the same. That would quickly eliminate a lot of work. Of course, you'd have to know which headers they used (they being Dave Ellis and friends), but I leave that to you.

Also, I think the code for the first game is enough. You'd only need to create the graphics for the second and do "a bit" of extra coding.

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...