Why should the government subsidize the games industry in the UK? As a UK tax payer I would be quite upset to hear of such an arrangement when the NHS and transportation systems are in such a poor state.
In Canada (where I have also worked in the games industry) the government actively promotes the games industry (and a number of other high-tech industries) with such incentives because it's a good way to increase Canada's skilled worker population, which is one of the governments' on-going goals. Additionally, I think that you'll find that a large portion of such breaks are actually offered by the Provincial Governments, rather than Federal. These breaks are not designed to attract such companies to Canada (the nationwide reduced operating costs relative to other western nations are enough to do that) they're simply an extra incentive to attract such companies to one province over another. In a sense, the provinces compete for the tickle down economic benefits of having high-tech companies around.
An incentive system like this would make no sense for the UK government. Here in the UK we already have a large financial sector which employs a lot of the best programming talent and pays them very well. Giving money to the games industry (or taking less money away from it in tax breaks) would be money well wasted from the point of view of UK economic policy, because it wouldn't create as much trickle down benefits as the finance sector (not even close!) and it might take talent away. Additionally, unless the breaks were *HUGE* Canada would still be cheaper.
The fact of the matter is that tax breaks or not doing anything in the UK is more expensive than doing it most other places in the world. If you're in an industry where the local economic environment influences your income as well as your operating costs, then this isn't a big problem. Although it costs more to staff a restaurant in London than in Vancouver, people pay more to eat at a restaurant in London.
This is not the case for games, no-one is ready to pay more for a game because it was developed in the UK rather than Canada.
What a load of Rubbish. In my current place of work we pay reasonable wages and we have filled all of our programming positions.
In some places I have worked in the past, we paid less reasonable wages and didn't fill all our positions. The complaint here seems to amount to "there's a labour market and the prices are more than I want to pay".
Of course, then there's the other side of the problem which is that the relatively high cost of labour means that it's cheaper to run a studio in the Far East, Eastern Europe or Canada. So a lot of studios and individuals move there. I don't think that anyone can seriously blame universities or consoles for that!
The fact that these 'special articles' are able to appear in the preprint archive after they have been published (essentially traveling backwards in time) means that I no longer need to read the article.
I find that customers like this are far better at telling you want they don't want, rather than what they do want. This can be very unhelpful as it can lead to your not knowing that what you're making is incorrect until it's actually finished.
The best approach is for you to spec out the system as best you can yourself, using what little input you do have (perhaps including some glaring errors on purpose;) This spec will almost certainly be totally unacceptable, but you should then ask the customer to approve it.
Generally you'll get a whole lot of input about what's wrong with this system that you 'almost' built. Hopefully you can then work from that.
Of course, depending on just how unreasonable they really are they might get rid of you just because your spec was so wrong;)
I conduct regular technical interviews for a large game company, so I can't comment on the value of such a degree outside of the industry. However, I can tell you that whether you take a standard CS course or a games oriented one, it really won't make very much difference to whether you get a job inside the industry.
If the course you are looking at is affiliated with an actual games company (one that's actually put products on shelves before) then perhaps the situation is slightly different, but I doubt it.
The reason for this is that a degree, no matter how relevant or prestigious can only help you to get into a technical interview. Once you're in the interview it really won't matter at all, what will matter is whether you can demonstrate sufficient technical ability to do the job and in my experience this is not something that people get directly from their degrees.
The strongest candidates are the ones that have degrees (mainly to get past the recruitment teams' basic filtering, and to learn some 'soft skills') and have learned to program by themselves outside of that context. I do not believe that any degree will teach you how to program to the level required of a professional game developer by itself. Remember, if you get the job you'll be programming for upwards of 60 hours a week at times, if you don't love programming enough to have become very good (which can only be done with at least some contribution of free time) then your career will be short lived.
Well over half the candidates that I reject get turned down simply because despite their degrees they simply aren't good enough at programming to be employed in the industry.
So, whether you have a degree or not and whether you intend to get one or not, if you want to get into the games industry as a programmer, then you need to get very good at programming (because the other candidates are).
In case no one else has mentioned it in this thread (which I doubt), almost all games' programming is done in C/C++ or something lower level (i.e. assembler), so make sure that's what you teach yourself.
Personally, unless the course has some kind of real industry link (which is very, very rare) then I would go for the standard course, because it won't limit your options in fields outside of games, but the 'games' course isn't really going to give you any advantage in the games field itself.
Several years ago, just before I left my 'proper job' to work in the games industry I was involved in a pretty disastrous software project. The project and companies involved shall remain nameless, but basics of the story will be familiar to alot of people.
We had a small in-house team (9-10 coders) and the business decided to embark on a project which was way outside of the teams' capacity. After several weeks of protesting that the project was too big for us to deliver in anywhere near the drop dead dates we were given management finally relented and brought in a development consultancy to supplement our small internal team. This consultancy (who will also remain nameless) brought with them a small army of mostly incompetent coders and a giant army of business analysts, architects, project managers and other varieties of monkey trained in various levels of sales and management speak. Needless to say the consultancy left the internal team todo most of the coding work and spent alot of time making presentations, sending long e-mails, creating complex charts of various kinds and then left the delayed, feature barren, burning carcass of of the project behind and pocketed alot of cash.
The one thing that the consultancy brought with them that actually helped was a team of sub-contracted QA staff who were located off-site at the consultancy's office, some miles away. I was even younger and stupider then than I am now and at first I complained bitterly about the 2 page bug reports that I began to receive from them on a regular basis. These reports would contain a massive amount of detail for even the most trivial bug, complete (often 100%) repro cases for bugs which were incredibly complex and (IMO at the time) were never going to be found by normal users. The reports often also contained references to specific areas of the functional specs that we had written at the start of each project which our implementation was not entirely adhering to.
Now that I am less young, less stupid and work in the game industry I pine regularly (as my colleagues will no doubt confirm) for those QA people whose bug reports were so clear, complete, accurate and detailed. The bug reports I receive now from game team testers are like drawings on the wall of a cave when compared to the reports described above. They are short, unclear, often completely inaccurate and sometimes the text is not even recognizable as English.
The reason for this massive discrepancy in report quality is glaringly obvious. When I worked at the consultants office for a little while (just prior to leaving that job) I actually sat next to the QA team. The difference between that QA team and all the QA teams I've worked with in games was like night and day. In a word, they were professionals. Most of them were graduates with 5-10 years of work experience, they were obviously well paid (some of them better paid than me I think) and their personal appearance and hygiene put most of the coders to shame. They had analyzed our entire functional spec, without any interaction with the development team and created a complete test plan which they synced up to our development schedule. They had identified a number of complex testing tools which were appropriate for our product, acquired them and were actively using them to find bugs the we could hardly even imagine. They were often able to isolate the causes of problem, when the cause and effect were in totally unrelated parts of the product (functionally speaking).
That's not to say that the game QA teams I've worked with have been all bad, but they're a totally different class of tester than the guys at the consultancy. I suppose that the title of this post is alittle misleading, as I have also worked with the class of tester found in the games industry in other industries, but they are less common and generally in smaller numbers.
Anyway, before I get modded off topic the real point of this post is that I would like to see the kind of testing described above happen more in the industry
Regardless of the negligible performance hit compared to native code
There's a whole number of reasons why native languages are still in very heavy use in a number of environments and industries. The original post plays down the performance concerns but they are a real consideration for many products. Compare the user experience of a Java GUI application to a native C++ one of comparable functionality. Even if the C++ product uses MFC or somesuch it will still be faster, more responsive and leave more CPU and RAM around for the other apps. Embedded systems often don't have enough system resources to make an interpreter or vm workable at all. Some applications (i.e. games) are engineered specifically to use as much system resources as possible, in order to provide the best possible user experience. A vm might take 2ms per frame and 4MB of RAM (or quite a bit more in some cases) that's a pretty serious thing for a game, you might have to remove something (or several things) to free up enough resources for that, and it would add nothing to the user experience at all.
even though interpreted languages are easier to port cross-platform
In my experience this is not really the case at all. Decent C compilers are available for almost every single platform in existence, most interpreters and vm's are compiled on C compilers. In contrast many vm's are confined to specific platforms, or have only patchy support for platforms other than PC.
Platform support aside I would also assert (without any actual proof) that the consistency between platform implementations for a given C++ complier is far in excess of the consistency between platform implementations for most vm's.
Also, vm languages often need extra (native) runtime modules to access specific API's which are not available through the language itself. This means that if a required runtime module is unavailable for a given target platform, the application developer is basically barred from it until it becomes available (or they write their own native module to access the API).
Finally, vm and interpreted languages almost always require more setup of their target environment(s) than native languages. Most of these kinds of languages have no concept of a linker, so all module binding is done dynamically (i.e. at runtime). Obviously some OS's (i.e. windows) lean towards dynamic bindings for native code as well, but native languages are equally capable of both. When you're writing any kind of consumer targeted software, telling people that they need to download the latest jvm (or whatever) and wait another 20 minutes (if you're lucky) for that to download and install just so that they can start to install your software is a sure way to send them to your competitors... If it doesn't then get them started on setting their CLASSPATH.
often have a shorter development time
This is an arguable point at best. While such languages are often easier to both learn and to start new projects for (i.e. no build scripts etc.) I wouldn't say that there's a clear winner for overall development time. It often depends on what you're trying to write. Generally lots of string manipulation and calls to standard system modules (i.e. file system etc.) are simpler in interpreted languages (provided that you're not trying to keep your memory footprint down) but some other things are easier in native languages (i.e. encryption or math which requires specific and consistent accuracy).
Garbage collection is often cited as a feature of interpreted languages which decreases development time (because developers don't need to worry about memory allocations and deallocations) but garbage collection is also available in native languages, it's just not popular. Also, doing 'advanced' things in interpreted languages is often quite a bit more tricky than their native counterparts (i.e. function pointers - the C# equivalent is far more complex).
In reality it's not a 'lack of games' for the mac, but a lack of timely release, advertising and retail support for the mac. There are studios out there that actually do very little except port PC games to the Mac...
The original Half-Life port for PlayStation 2 had an excellent co-op mode which my wife and I played through until the end (I don't think that she's ever finished another game - except maybe Quake 1). AFAIK that's the only format that the co-op levels appeared in. It's really cool, both players have to work 2gether, but a good player can help out a less skilled one without detracting from the fun at all.
One thing to note about this is that if either player dies the mission is failed and you have to go back to the start of the level, so co-operation is far more critical than in something like Halo.
I don't doubt that it's a problem. But that doesn't mean that it's not true. Whenever something like this happens and an entertainment product ends up in court for "causing" death/injury by "forcing" someone to injure/kill someone else/themselves the sales of the product in question go up (or continue to be good long after it's usual shelf-life).
And that is good for business. If it wasn't publishers wouldn't make games like that.
The main effect of all this 'bad press' is to sell more games. Kids think that they're "bad"/"cool" or whatever if they play games like that so they buy them (with or without their parents' consent).
Unless someone actually looses one of these lawsuits and has to pay up a significant chunk of cash, then there's no reason (from a units sold perspective) for the industry to even see this as a problem.
You know, this is why video game developers have work to do on the image of video games.
This kind of media coverage - while stupid and inaccurate - is also great for sales and costs the industry almost nothing. You can't buy advertising this good. The industry does not have to work on this at all, just keep making more money from it.
The simpsons are not their cup of tea or should i say glass of camel milk.
Having lived in many parts of the Gulf I'd like to point out that camel milk is rarely drunk neat (it's really gross) and that 'cup of tea' is really the correct phrase to use in this instance as tea was drunk in arabia long before it was exported to the west (it is possible that the Arabs that first introduced it to Europe as an export).
I see. Well my advice from the previous post still stands. Don't try to address the codebase as a whole, but confine yourselves to the functional (rather than architectural) areas that you're interested in.
Presumably you have some specific types of modification in mind so start by creating a list of each functional area that you think each modification will impact. You probably don't even need to look at the code for this part. For example, if you want to add a 'boost' feature to a racing game, then you'll probably have to change the following areas:
+ physics/simulation - to actually do the boosting
+ control - to allow the player to trigger the boost
+ ai - to decide when to boost
There may well be other areas (i.e. ui to indicate boost is available, fx to indicate to the player that a car is boosting, but let's ignore that for now).
Once you have done this, then you'll have a list of modifications and corresponding functional areas:
+ boost - simulation, control, ai
+ position indicator - ui, simulation
+ car damage - simulation, (rendering?)
+ manual transmission - simulation, control, ai
As you can see from my (rather contrived) example the areas you really need to look at are simulation, control and ai. You do not need to even look at the asset management system, memory manager (which is probably not a garbage collector;), front end, sound system, networking, user settings, ui or rendering until you actually start coding.
That's not to say that you won't need to touch on these systems and understand them in some way (can't do much without allocating *some* memory) but you won't be *changing* them, and you don't need to understand how they work, just how to use them. In fact, the calls that you need to make can probably be figured out by looking at the code that you've already examined. For example, if you want to add a position indicator to the ui which is driven by the simulation, you'll probably be able to find another indicator (i.e. race progress) which is already driven by the simulation. You can just mimic it without ever looking at the ui code. Likewise, once you understand how the simulation uses the asset manager, memory manager, sound system and networking you can modify the simulation using those systems in the same manner without ever examining them in great detail.
After a while you may find that you want to change the way that some of these other systems work. Although that may be necessary (depending on how good/bad the code is and how far your final requirements differ from the original functioning of that system) don't worry about this until it actually stops you from making a modification that you want to. There's probably alot of bad code in the engine, but just focus on what you need to in order to make your changes.
IMHO there is no place for pointer arithmetic in modern software. If someone working for me wrote something like the second option, I would ask them to rewrite it.
Obviously you have never worked with low-power architectures or non-mainstream compilers. While this particular example may well be too simple to justify using pointer arithmetic in any environment, in a more complex example that type of thing may well be justified (espically on more exotic architectures).
Just expecting compilers to do a good job is no substitute for being able to ensure that they do and being able to do a good job for them if they don't.
This is an interesting post. Much better than all the politics etc. that we've seen recently on./
I can't think of any modern architectures that don't support register indexing. Can anyone else?
On another note, although at first glance it may appear that the poster is correct I think that a good compiler written for an architecture that didn't support register indexing (M68000 does, so it's going to have to be something very old) would probably be able to figure out what's going on in this code sample. i.e. in the array version within the for loop head and tail are only used as indexes into the array, so converting them into straight pointers would be trivial. Of course in a more complex example YMMV.
So what are you trying to do? Do you want to modify this source todo something new? Do you want to document it, or represent it in some other way? You're still not telling us what you mean by 'reverse engineer'. What is your goal here?
First of all this is not a massive code base for a commercial computer game, it's about average. Many games get into the 1-2 million lines of code. Having said that most games also have teams that are probably much larger than your group of students.
I'm not exactly sure what you're trying to do here. As many ppl have said reverse engineering something that you already have the source for is not really reverse engineering at all. However if I make the (somewhat suspect) assumption that your objective is to examine the code and extract some kind of high-level understanding of the entire engine which you can then demonstrate in some way, I would advise you to think again. Most games (again, I am assuming that you have a commercially developed code base of some kind) are a giant mess with no overall design or direction in the code.
Generally you'll find that a few sub-systems have been implemented with some kind of clean design (although not necessarily in a coordinated manner) and then the rest of the game is just a mass of glue code that holds these pieces together. During the original implementation no-one will have had the kind of general overview that you're looking for, each member of the team will know their specific area or areas, and how that part interfaces to the next, but no-one will know how all of them work together. Trying to summarize how all the systems work together will either give you something very high-level (and essentially meaningless) or something so complex that it's almost as hard to understand as the source (and not suitable to give to your professor as 'proof of understanding').
My advice would be to choose one or more parts of the game and try to gain an understanding (in whatever manner you choose) of those areas. One of the best ways to choose these areas is to look at the USP (unique selling points) of the game itself. Some areas of the game will have been very important to the final product, while others will have been done just because they had to. For example, if the game is an RTS with a focus on the tactical aspect of the single player experience, then the scripting and ai systems will have been very important (and made as good as possible) while the sound engine will not have been very important (and made just good enough). The parts of code which are important to the actual gameplay will have had much more time and attention spent on them and will probably be far more interesting. Having said that the most important parts of the game will also have had more ppl working on them and they may well contain much less readable code.
Perhaps you should give us some more info on what exactly you want to do, so that we can give you more relevant advice?
Slashdot Mirror
This is the last Easter Egg I "worked" on (as a manager):
http://nfs.wikia.com/wiki/Fair...
This was not very much work, but generated a lot of positive reactions and everyone on the team liked it, so I think the ROI was there.
It's like any software feature, if it justifies the work (and you have the resource) then go for it :)
Nah... she just had a bad teacher.
Why should the government subsidize the games industry in the UK? As a UK tax payer I would be quite upset to hear of such an arrangement when the NHS and transportation systems are in such a poor state.
In Canada (where I have also worked in the games industry) the government actively promotes the games industry (and a number of other high-tech industries) with such incentives because it's a good way to increase Canada's skilled worker population, which is one of the governments' on-going goals. Additionally, I think that you'll find that a large portion of such breaks are actually offered by the Provincial Governments, rather than Federal. These breaks are not designed to attract such companies to Canada (the nationwide reduced operating costs relative to other western nations are enough to do that) they're simply an extra incentive to attract such companies to one province over another. In a sense, the provinces compete for the tickle down economic benefits of having high-tech companies around.
An incentive system like this would make no sense for the UK government. Here in the UK we already have a large financial sector which employs a lot of the best programming talent and pays them very well. Giving money to the games industry (or taking less money away from it in tax breaks) would be money well wasted from the point of view of UK economic policy, because it wouldn't create as much trickle down benefits as the finance sector (not even close!) and it might take talent away. Additionally, unless the breaks were *HUGE* Canada would still be cheaper.
The fact of the matter is that tax breaks or not doing anything in the UK is more expensive than doing it most other places in the world. If you're in an industry where the local economic environment influences your income as well as your operating costs, then this isn't a big problem. Although it costs more to staff a restaurant in London than in Vancouver, people pay more to eat at a restaurant in London.
This is not the case for games, no-one is ready to pay more for a game because it was developed in the UK rather than Canada.
What a load of Rubbish. In my current place of work we pay reasonable wages and we have filled all of our programming positions.
In some places I have worked in the past, we paid less reasonable wages and didn't fill all our positions. The complaint here seems to amount to "there's a labour market and the prices are more than I want to pay".
Of course, then there's the other side of the problem which is that the relatively high cost of labour means that it's cheaper to run a studio in the Far East, Eastern Europe or Canada. So a lot of studios and individuals move there. I don't think that anyone can seriously blame universities or consoles for that!
Surely the whole point would be to port it to Ruby?
... and now Video Killed the Internet too??
i o_Star
http://en.wikipedia.org/wiki/Video_Killed_The_Rad
The fact that these 'special articles' are able to appear in the preprint archive after they have been published (essentially traveling backwards in time) means that I no longer need to read the article.
Many sucessful products are made up of around 500K lines of C++.
Most console computer games for example start at around 500K lines...
I find that customers like this are far better at telling you want they don't want, rather than what they do want. This can be very unhelpful as it can lead to your not knowing that what you're making is incorrect until it's actually finished.
;) This spec will almost certainly be totally unacceptable, but you should then ask the customer to approve it.
;)
The best approach is for you to spec out the system as best you can yourself, using what little input you do have (perhaps including some glaring errors on purpose
Generally you'll get a whole lot of input about what's wrong with this system that you 'almost' built. Hopefully you can then work from that.
Of course, depending on just how unreasonable they really are they might get rid of you just because your spec was so wrong
I conduct regular technical interviews for a large game company, so I can't comment on the value of such a degree outside of the industry. However, I can tell you that whether you take a standard CS course or a games oriented one, it really won't make very much difference to whether you get a job inside the industry.
If the course you are looking at is affiliated with an actual games company (one that's actually put products on shelves before) then perhaps the situation is slightly different, but I doubt it.
The reason for this is that a degree, no matter how relevant or prestigious can only help you to get into a technical interview. Once you're in the interview it really won't matter at all, what will matter is whether you can demonstrate sufficient technical ability to do the job and in my experience this is not something that people get directly from their degrees.
The strongest candidates are the ones that have degrees (mainly to get past the recruitment teams' basic filtering, and to learn some 'soft skills') and have learned to program by themselves outside of that context. I do not believe that any degree will teach you how to program to the level required of a professional game developer by itself. Remember, if you get the job you'll be programming for upwards of 60 hours a week at times, if you don't love programming enough to have become very good (which can only be done with at least some contribution of free time) then your career will be short lived.
Well over half the candidates that I reject get turned down simply because despite their degrees they simply aren't good enough at programming to be employed in the industry.
So, whether you have a degree or not and whether you intend to get one or not, if you want to get into the games industry as a programmer, then you need to get very good at programming (because the other candidates are).
In case no one else has mentioned it in this thread (which I doubt), almost all games' programming is done in C/C++ or something lower level (i.e. assembler), so make sure that's what you teach yourself.
Personally, unless the course has some kind of real industry link (which is very, very rare) then I would go for the standard course, because it won't limit your options in fields outside of games, but the 'games' course isn't really going to give you any advantage in the games field itself.
Maybe the real story is that the PS/3 is made of cylon parts? Why else would Starbuck have spent all this time posing as a foreign student in Japan???
Don't buy it!!!
Several years ago, just before I left my 'proper job' to work in the games industry I was involved in a pretty disastrous software project. The project and companies involved shall remain nameless, but basics of the story will be familiar to alot of people.
We had a small in-house team (9-10 coders) and the business decided to embark on a project which was way outside of the teams' capacity. After several weeks of protesting that the project was too big for us to deliver in anywhere near the drop dead dates we were given management finally relented and brought in a development consultancy to supplement our small internal team. This consultancy (who will also remain nameless) brought with them a small army of mostly incompetent coders and a giant army of business analysts, architects, project managers and other varieties of monkey trained in various levels of sales and management speak. Needless to say the consultancy left the internal team todo most of the coding work and spent alot of time making presentations, sending long e-mails, creating complex charts of various kinds and then left the delayed, feature barren, burning carcass of of the project behind and pocketed alot of cash.
The one thing that the consultancy brought with them that actually helped was a team of sub-contracted QA staff who were located off-site at the consultancy's office, some miles away. I was even younger and stupider then than I am now and at first I complained bitterly about the 2 page bug reports that I began to receive from them on a regular basis. These reports would contain a massive amount of detail for even the most trivial bug, complete (often 100%) repro cases for bugs which were incredibly complex and (IMO at the time) were never going to be found by normal users. The reports often also contained references to specific areas of the functional specs that we had written at the start of each project which our implementation was not entirely adhering to.
Now that I am less young, less stupid and work in the game industry I pine regularly (as my colleagues will no doubt confirm) for those QA people whose bug reports were so clear, complete, accurate and detailed. The bug reports I receive now from game team testers are like drawings on the wall of a cave when compared to the reports described above. They are short, unclear, often completely inaccurate and sometimes the text is not even recognizable as English.
The reason for this massive discrepancy in report quality is glaringly obvious. When I worked at the consultants office for a little while (just prior to leaving that job) I actually sat next to the QA team. The difference between that QA team and all the QA teams I've worked with in games was like night and day. In a word, they were professionals. Most of them were graduates with 5-10 years of work experience, they were obviously well paid (some of them better paid than me I think) and their personal appearance and hygiene put most of the coders to shame. They had analyzed our entire functional spec, without any interaction with the development team and created a complete test plan which they synced up to our development schedule. They had identified a number of complex testing tools which were appropriate for our product, acquired them and were actively using them to find bugs the we could hardly even imagine. They were often able to isolate the causes of problem, when the cause and effect were in totally unrelated parts of the product (functionally speaking).
That's not to say that the game QA teams I've worked with have been all bad, but they're a totally different class of tester than the guys at the consultancy. I suppose that the title of this post is alittle misleading, as I have also worked with the class of tester found in the games industry in other industries, but they are less common and generally in smaller numbers.
Anyway, before I get modded off topic the real point of this post is that I would like to see the kind of testing described above happen more in the industry
There's a whole number of reasons why native languages are still in very heavy use in a number of environments and industries. The original post plays down the performance concerns but they are a real consideration for many products. Compare the user experience of a Java GUI application to a native C++ one of comparable functionality. Even if the C++ product uses MFC or somesuch it will still be faster, more responsive and leave more CPU and RAM around for the other apps. Embedded systems often don't have enough system resources to make an interpreter or vm workable at all. Some applications (i.e. games) are engineered specifically to use as much system resources as possible, in order to provide the best possible user experience. A vm might take 2ms per frame and 4MB of RAM (or quite a bit more in some cases) that's a pretty serious thing for a game, you might have to remove something (or several things) to free up enough resources for that, and it would add nothing to the user experience at all.
In my experience this is not really the case at all. Decent C compilers are available for almost every single platform in existence, most interpreters and vm's are compiled on C compilers. In contrast many vm's are confined to specific platforms, or have only patchy support for platforms other than PC.
Platform support aside I would also assert (without any actual proof) that the consistency between platform implementations for a given C++ complier is far in excess of the consistency between platform implementations for most vm's.
Also, vm languages often need extra (native) runtime modules to access specific API's which are not available through the language itself. This means that if a required runtime module is unavailable for a given target platform, the application developer is basically barred from it until it becomes available (or they write their own native module to access the API).
Finally, vm and interpreted languages almost always require more setup of their target environment(s) than native languages. Most of these kinds of languages have no concept of a linker, so all module binding is done dynamically (i.e. at runtime). Obviously some OS's (i.e. windows) lean towards dynamic bindings for native code as well, but native languages are equally capable of both. When you're writing any kind of consumer targeted software, telling people that they need to download the latest jvm (or whatever) and wait another 20 minutes (if you're lucky) for that to download and install just so that they can start to install your software is a sure way to send them to your competitors... If it doesn't then get them started on setting their CLASSPATH.
This is an arguable point at best. While such languages are often easier to both learn and to start new projects for (i.e. no build scripts etc.) I wouldn't say that there's a clear winner for overall development time. It often depends on what you're trying to write. Generally lots of string manipulation and calls to standard system modules (i.e. file system etc.) are simpler in interpreted languages (provided that you're not trying to keep your memory footprint down) but some other things are easier in native languages (i.e. encryption or math which requires specific and consistent accuracy).
Garbage collection is often cited as a feature of interpreted languages which decreases development time (because developers don't need to worry about memory allocations and deallocations) but garbage collection is also available in native languages, it's just not popular. Also, doing 'advanced' things in interpreted languages is often quite a bit more tricky than their native counterparts (i.e. function pointers - the C# equivalent is far more complex).
In general (l
Quite alot of popular PC games actually get ported to the Mac, they just get released several months (years?) after the PC versions:
http://www.apple.com/games/
In reality it's not a 'lack of games' for the mac, but a lack of timely release, advertising and retail support for the mac. There are studios out there that actually do very little except port PC games to the Mac...
The original Half-Life port for PlayStation 2 had an excellent co-op mode which my wife and I played through until the end (I don't think that she's ever finished another game - except maybe Quake 1). AFAIK that's the only format that the co-op levels appeared in. It's really cool, both players have to work 2gether, but a good player can help out a less skilled one without detracting from the fun at all.
One thing to note about this is that if either player dies the mission is failed and you have to go back to the start of the level, so co-operation is far more critical than in something like Halo.
I don't doubt that it's a problem. But that doesn't mean that it's not true. Whenever something like this happens and an entertainment product ends up in court for "causing" death/injury by "forcing" someone to injure/kill someone else/themselves the sales of the product in question go up (or continue to be good long after it's usual shelf-life).
And that is good for business. If it wasn't publishers wouldn't make games like that.
It's still good for business.
The main effect of all this 'bad press' is to sell more games. Kids think that they're "bad"/"cool" or whatever if they play games like that so they buy them (with or without their parents' consent).
Unless someone actually looses one of these lawsuits and has to pay up a significant chunk of cash, then there's no reason (from a units sold perspective) for the industry to even see this as a problem.
You know, this is why video game developers have work to do on the image of video games.
This kind of media coverage - while stupid and inaccurate - is also great for sales and costs the industry almost nothing. You can't buy advertising this good. The industry does not have to work on this at all, just keep making more money from it.
The simpsons are not their cup of tea or should i say glass of camel milk.
Having lived in many parts of the Gulf I'd like to point out that camel milk is rarely drunk neat (it's really gross) and that 'cup of tea' is really the correct phrase to use in this instance as tea was drunk in arabia long before it was exported to the west (it is possible that the Arabs that first introduced it to Europe as an export).
I see. Well my advice from the previous post still stands. Don't try to address the codebase as a whole, but confine yourselves to the functional (rather than architectural) areas that you're interested in.
Presumably you have some specific types of modification in mind so start by creating a list of each functional area that you think each modification will impact. You probably don't even need to look at the code for this part. For example, if you want to add a 'boost' feature to a racing game, then you'll probably have to change the following areas:
+ physics/simulation - to actually do the boosting
+ control - to allow the player to trigger the boost
+ ai - to decide when to boost
There may well be other areas (i.e. ui to indicate boost is available, fx to indicate to the player that a car is boosting, but let's ignore that for now).
Once you have done this, then you'll have a list of modifications and corresponding functional areas:
+ boost - simulation, control, ai
+ position indicator - ui, simulation
+ car damage - simulation, (rendering?)
+ manual transmission - simulation, control, ai
As you can see from my (rather contrived) example the areas you really need to look at are simulation, control and ai. You do not need to even look at the asset management system, memory manager (which is probably not a garbage collector;), front end, sound system, networking, user settings, ui or rendering until you actually start coding.
That's not to say that you won't need to touch on these systems and understand them in some way (can't do much without allocating *some* memory) but you won't be *changing* them, and you don't need to understand how they work, just how to use them. In fact, the calls that you need to make can probably be figured out by looking at the code that you've already examined. For example, if you want to add a position indicator to the ui which is driven by the simulation, you'll probably be able to find another indicator (i.e. race progress) which is already driven by the simulation. You can just mimic it without ever looking at the ui code. Likewise, once you understand how the simulation uses the asset manager, memory manager, sound system and networking you can modify the simulation using those systems in the same manner without ever examining them in great detail.
After a while you may find that you want to change the way that some of these other systems work. Although that may be necessary (depending on how good/bad the code is and how far your final requirements differ from the original functioning of that system) don't worry about this until it actually stops you from making a modification that you want to. There's probably alot of bad code in the engine, but just focus on what you need to in order to make your changes.
Hope that helps.
IMHO there is no place for pointer arithmetic in modern software. If someone working for me wrote something like the second option, I would ask them to rewrite it.
Obviously you have never worked with low-power architectures or non-mainstream compilers. While this particular example may well be too simple to justify using pointer arithmetic in any environment, in a more complex example that type of thing may well be justified (espically on more exotic architectures).
Just expecting compilers to do a good job is no substitute for being able to ensure that they do and being able to do a good job for them if they don't.
This is an interesting post. Much better than all the politics etc. that we've seen recently on ./
I can't think of any modern architectures that don't support register indexing. Can anyone else?
On another note, although at first glance it may appear that the poster is correct I think that a good compiler written for an architecture that didn't support register indexing (M68000 does, so it's going to have to be something very old) would probably be able to figure out what's going on in this code sample. i.e. in the array version within the for loop head and tail are only used as indexes into the array, so converting them into straight pointers would be trivial. Of course in a more complex example YMMV.
Then you can go freelance, get paid more and work *less* hours :)
So what are you trying to do? Do you want to modify this source todo something new? Do you want to document it, or represent it in some other way? You're still not telling us what you mean by 'reverse engineer'. What is your goal here?
First of all this is not a massive code base for a commercial computer game, it's about average. Many games get into the 1-2 million lines of code. Having said that most games also have teams that are probably much larger than your group of students.
I'm not exactly sure what you're trying to do here. As many ppl have said reverse engineering something that you already have the source for is not really reverse engineering at all. However if I make the (somewhat suspect) assumption that your objective is to examine the code and extract some kind of high-level understanding of the entire engine which you can then demonstrate in some way, I would advise you to think again. Most games (again, I am assuming that you have a commercially developed code base of some kind) are a giant mess with no overall design or direction in the code.
Generally you'll find that a few sub-systems have been implemented with some kind of clean design (although not necessarily in a coordinated manner) and then the rest of the game is just a mass of glue code that holds these pieces together. During the original implementation no-one will have had the kind of general overview that you're looking for, each member of the team will know their specific area or areas, and how that part interfaces to the next, but no-one will know how all of them work together. Trying to summarize how all the systems work together will either give you something very high-level (and essentially meaningless) or something so complex that it's almost as hard to understand as the source (and not suitable to give to your professor as 'proof of understanding').
My advice would be to choose one or more parts of the game and try to gain an understanding (in whatever manner you choose) of those areas. One of the best ways to choose these areas is to look at the USP (unique selling points) of the game itself. Some areas of the game will have been very important to the final product, while others will have been done just because they had to. For example, if the game is an RTS with a focus on the tactical aspect of the single player experience, then the scripting and ai systems will have been very important (and made as good as possible) while the sound engine will not have been very important (and made just good enough). The parts of code which are important to the actual gameplay will have had much more time and attention spent on them and will probably be far more interesting. Having said that the most important parts of the game will also have had more ppl working on them and they may well contain much less readable code.
Perhaps you should give us some more info on what exactly you want to do, so that we can give you more relevant advice?