*clears his throat and begins to speak in an elderly ..scratchy voice* ..why.. In my time each year a new ground breaking game came out we would have to upgrade our hardware. soon, games became bigger and hard drives came out. Yay for hard drives and no more swapping floppy drves! You needed to upgrade hard drives what seemed at the release of every major game. When that wasnt enough, games started coming out on CD and most games where larger than the actual hard drive itself. I remember how pissed my mom would get every time I would buy a new game and it wouldnt load on to the hard drive. so be glad you dont live back when the Home PC was being pioneered and upgrading hardware was very common. It wasnt too long ago when upgrading video boards alone was standard practice just to be able to play or load the game. Now we just do it for the most part, for better FPS this cost $2500 bux when I was 16 8MHz proc
256 KB RAM
one 5 1/4" floppy drives
NO hard drive
4 color CGA graphics
so hey..screw you and you 23 gig beta :P
Amen to that. I started out on a C64 that my grandparents bought for my brother and me. I couldn't even play any games that my friends had, because they all had IBM compatibles. Of course, our school had Apples. Ah, the memories.
Insert floppy to boot.
Insert floppy to start a game.
Insert another floppy to continue loading.
Ooops, error! Reboot, insert floppy!
Oh yeah, I remember now why we loved our Atari 2600 and later the Nintendo. NO FLOPPIES TO INSERT!
Now I don't even have a floppy drive, and I've got a USB data key that's 20X bigger than my first HDD was.
Just think, in 2010 we'll all be laughing at CD-ROMs and HDDs with moving parts, and a 23GB beta test will be for a 2D MMORPG that plays in IE.
Agent_X7 AKA J Star [/URL] Notice: The views expressed in this post are solely those of the author and do not necessarily reflect the views of MMORPG.com or its management.
Originally posted by goater i cant believe people are pissing and moaning about the hard drive space a game is taking up... i mean i just cant follow that train of thought. this is 2007, games are HUGE... textures, etc etc...
and a happy new year (2008) to you too.
You will need as minimum 2GB RAM, graphics card with min 256 RAM (preferably ATI).
Originally posted by Agent_X7 Originally posted by Rayx0r *clears his throat and begins to speak in an elderly ..scratchy voice* ..why.. In my time each year a new ground breaking game came out we would have to upgrade our hardware. soon, games became bigger and hard drives came out. Yay for hard drives and no more swapping floppy drves! You needed to upgrade hard drives what seemed at the release of every major game. When that wasnt enough, games started coming out on CD and most games where larger than the actual hard drive itself. I remember how pissed my mom would get every time I would buy a new game and it wouldnt load on to the hard drive. so be glad you dont live back when the Home PC was being pioneered and upgrading hardware was very common. It wasnt too long ago when upgrading video boards alone was standard practice just to be able to play or load the game. Now we just do it for the most part, for better FPS this cost $2500 bux when I was 16 8MHz proc 256 KB RAM one 5 1/4" floppy drives NO hard drive 4 color CGA graphics
so hey..screw you and you 23 gig beta :P
Amen to that. I started out on a C64 that my grandparents bought for my brother and me. I couldn't even play any games that my friends had, because they all had IBM compatibles. Of course, our school had Apples. Ah, the memories. Insert floppy to boot. Insert floppy to start a game. Insert another floppy to continue loading. Ooops, error! Reboot, insert floppy! Oh yeah, I remember now why we loved our Atari 2600 and later the Nintendo. NO FLOPPIES TO INSERT!
Now I don't even have a floppy drive, and I've got a USB data key that's 20X bigger than my first HDD was. Just think, in 2010 we'll all be laughing at CD-ROMs and HDDs with moving parts, and a 23GB beta test will be for a 2D MMORPG that plays in IE.
got my atari 2600 when i was 12.
got an Epson Equity 1+ when i was 15 (20mb hard drive) I remember Bard's tale was the big game back then. I wrote a 26,000 page basic program called Image Master lol i never did anything with it but it did get me through a programming class or 2.
I also had a commodore 64 when they came out.. gunship ROCKED! oh and Caveman Ughlympics
Stuck with the epson and c64 until Intel came out with the pentiums.
There are lots of graphics and sound files in the Vanguard client.
PS: You're not supposed to talk too much about what's in the client... read that NDA before posting about it.
there is no NDA. they dont make you sign/read anything with an NDA in it. (i know, i have been in the beta for a while.) Actually everytime you login you agree to the NDA.
Originally posted by Xpheyel I'd be more worried about your hard drive than your graphics card... As in, moving those 18 gigabytes to and from memory and virtual memory. But whatever. That does seem pretty big.
Bingo. Someone who actually knows what will happen.
I hope you guys have RAM out the ass to load half of that shit, otherwise sit back and watch you HDD churn like a butter maker.
Well it is 16.6 gigs, but thats because they havent done any compression yet they will be doing that soon, also the game will be running 2-3 times better very soon once they compress and optimise the code.
Originally posted by Aethios Code IS compressed when you download the installation files. The install process is the process of decompressing those files. You can't use a compressed file in a game without decompressing it first.
Since we're discussing the amount of disk space being taken up AFTER install, it's pretty silly to argue that the installation package BEFORE install is huge due to it being non-compressed. It's even sillier to argue that the game takes up a lot of space AFTER install due to non-compression, since that's the whole point on installation.
So yes, the game is non-compressed. That's the way games are played. What's your point?
I'm not talking about the installer package. I'm talking about content packages. The installer package is something that compresses all of the content packages into a smaller foot print, to fit on the chosen delivery media.
When a game is in development, it's not unusual to find all of the game's assets like - audio in full *.WAV file, models in full *.3DS, textures to be in full *.BMP - full size files because it's easier to work with, without the Asset Manager having to create more steps to getting the updated content to CVS. Normally the Asset Manager reserves the conversion of files to smaller *.MP3 or *.OGG, *.DXT or *.PNG or what have you, and compression of all these configuration files, game scripts, textures, audio, models, into game readable "content packages" (for example Quake's *.PAK files, Unreal *.U, *.UKX, *.UTX and so on).
As for game code (the binary stuff that acutaly runs the game), once most of the debug code has been removed from the client and server executables, they start optimizing for final release. Unless there are big issues like unexplained network traffic on the client side caused by too many server requests inducing server lag, they will leave specific debug code in to continue troubleshooting the game client until they have a resolution. That usualy means that an "in development" executable that maybe 10MBs, could be reduced to 3MBs after being fully optimized and all debug code removed. Even a further point, it's common practise to put all your debug symbols into an external package and make that package switchable from the *.EXE (for example iexplore.exe /debug).
Do you feel that I need to expound further by listing Package Type differences, Aethios? If I need to make the distinction, I gladly will. I don't want anyone to be confused about what I'm saying. It should be quite clear.
...from my experience an oversized game often means a badly coded game...
lets hope vanguard is not the case..
OMG, you have got to be kidding right? Code has nothing to do with the size of the game install. The install size has EVERYTHING to do with the content packages not being compressed yet because it's still in development. It's easier to work with your assets when they're not compressed; so in its non-compressed format a file that would normaly be 3 to 4 MBs like a high resolution model/high polygon count static mesh would be half of that once compressed into the package.
So I don't know what to conclude from "your" experience, as code has nothing to do with it! C++ code once compiled into 001110100110000110111111111000110001000 can't get much smaller after it's optimized.
But there is a correlation between coding and the game size. Primarily with optimization. If the game is so huge with a near-release version, how sloppy was thier coding? Sure quite a bit needs to be optimized down, but with it this far in development atleast half the assets should be optimized. Infact with the Open Beta in early January, I would expect 90% of all the assets to be complete and already optimized within thier respective packets.
Originally posted by CleffyII But there is a correlation between coding and the game size.
No. There is NO correlation between coding and the game size. Where I went to school, that's not what they're teaching in C++ 101 1st year university course. You don't learn it in 2nd year either; nor any year after that.
If the game has a large install foot print, it's because there are many assets usualy, or that the assets are not compressed into game readable compressed packages.
If the game executable is large and runs like a bloated pig, then you're right, the coding is crappy or the they didn't leverage the programming language very well.
With Vanguard's current state, unfortunatly, the games isn't in a final state until it's ready to goto Glass Master stage. Until the final build is approved, they will not proceed to Glass Master. I've seen this take upto a month.
You can expect that when they are in the final stretch coming upto the Open Beta, the Asset Manager will start compacting the game files. Until then, there is NO reason to expect it to have a small foot print.
But there is a correlation between coding and the game size.
No. There is NO correlation between coding and the game size. Where I went to school, that's not what they're teaching in C++ 101 1st year university course. You don't learn it in 2nd year either; nor any year after that.
If the game has a large install foot print, it's because there are many assets usualy, or that the assets are not compressed into game readable compressed packages.
If the game executable is large and runs like a bloated pig, then you're right, the coding is crappy or the they didn't leverage the programming language very well.
With Vanguard's current state, unfortunatly, the games isn't in a final state until it's ready to goto Glass Master stage. Until the final build is approved, they will not proceed to Glass Master. I've seen this take upto a month.
You can expect that when they are in the final stretch coming upto the Open Beta, the Asset Manager will start compacting the game files. Until then, there is NO reason to expect it to have a small foot print.
first, let me apologize for my poor wording of what I was trying to say.
basically, you are saying the large size of the game is because the files are uncompressed, because the game is in closed beta.
granted that I don't have a experienced computer programing background like you, but I always believed the compression part of the game development was usually done before beta release. Beta is meant for tweaking the game in the aspect of gameplay balances, hardware optimization, network issues, etc. It seemed illogical to me that the developers would want to leave the compression to after beta release, since they will have to waste a lot of bandwidth distributing a lot of data through the internet.
Remember Auto Assault. In beta, if I remember correctly the game was a 7 gig download (not just the original installation, but including updates as well). without hardware optimization the game ran slower than it should considering its graphics.
As the game moved from beta to gold, I got a little more framerates/sec, but the size of the game stayed the same. That's what made me assume the compression part of the game was done before beta.
But I never worked in the video game industry, so what I know are just basic experiences from beta testing past games. feel free to enlighten me
basically, you are saying the large size of the game is because the files are uncompressed, because the game is in closed beta.
Let me answer this question in couple of parts.
Compressing/Compacting:
There are different compression types, depending at which level you need to compress, that you will use when you start down the road of compacting and finalizing the game into a retail deliverable.
Format compression: This is where you will use a compressed file format like jpg instead of bmp, or mp3/ogg instead of wav. So this is the first level at which you begin to make the game's foot print smaller. [ie - 100 bitmaps @ 3MBs each = 300MBs converted to jpeg @ 300KBs each = 30MBs + 100 text files @ average 45KBs each = 4.5MBs = 34.5MBs worth of content to be put into 1 package]
Package compression: This is when you take a large portion of similar files and create a compressed package, that the game.exe file will read and decompress the file inside the engine. Some packages are simply a renamed zip file extension like Quake 3's *.pk3 is easily renamed *.zip and you can open it to view the contents. Some other games really go through alot of trouble to make their packages proprietary, increasing the difficulty of accessing the content files inside. [ie - 34.5MBs worth of content to be put into 1 package will not compress the jpegs anymore than they are, but the text files will compress maybe 8:1 ratio]
Installer compression: This is where you prepare and plan your game installer for delivery via CD/DVD/Download media. Each variant of medium will have specific size targets. You need to plan for this, because CD contains 700MBs and if your game is 2GBs, how many CDs will you need? 2000MBs divided by 700MBs equals 2.86 CDs. Round that up to 3CDs and you know how large each segment of your installer's *.cab, *.package, or whatever file extension you choose for your installer. Most installer maker programs don't care what you use as an extension. [ie - at this point your creating a volume spanable file, much like the older programs that would split large files into segments that would span accross multiple diskettes. There is also a file "location to copy this file" database that is usualy associated with this process. It can be in one of many types of File Location Databases (FLDBs). Common FLDBs are Orca as *.MSI, simpler scripts like *.INI or *.CFG]
Anyhow, this is a HUGE topic for such a forum, but there are many places to find good information, as well as a few very good books over the last few years. Again, too many to list here.
Package compression: This is when you take a large portion of similar files and create a compressed package, that the game.exe file will read and decompress the file inside the engine. Some packages are simply a renamed zip file extension like Quake 3's *.pk3 is easily renamed *.zip and you can open it to view the contents. Some other games really go through alot of trouble to make their packages proprietary, increasing the difficulty of accessing the content files inside. [ie - 34.5MBs worth of content to be put into 1 package will not compress the jpegs anymore than they are, but the text files will compress maybe 8:1 ratio]
thanks for that informative post. Just a few more questions to satisfy my curiosity.
if the game engine reads and decompresses the package, wouldn't that mean if the game engine is completed, the package compression would also be done? so in other words, would the size of this game change drastically from now to release, now that most of the compression is already finished?
also, with games like Spore, where its developers are focused on algorithmically compressing each file to allow the game have more content while taking up less space, which stage of compression are they improving? Package of File compression? and at the same time does this more effective compression method help with game performance? since the game now has to deal with less data? (although I can see why it could NOT since now the game engine has to decompress with a more complicated method).
Well, to better understand some of what this is, I recommend you visit http://en.wikipedia.org/wiki/.kkrieger site for more information, and a link to the official website that leads to a download link. Please head the warnings from the site as per the file does cause a Anti-Virus alert to popup and may even delete the downloaded file because of this.
This demo is a perfect example of using an engine to compress/decompress files, use very tight algorythms to create amazing texture effects, and contain a few really interesting maps. The file is 96KBs. That's it. Take a look at that before I answer more of this. You'll understand once you see it to believe it.
Now that you've gone to the site and probably have tested .Krieger, I can maybe shed some light.
Even if the game engine is complete, there are still lots of bugs with some of the sub features of the engine that need a great deal of time to debug. Especialy considering how long some games go without having Gold Duping exploit bugs patched up. Now you can probably imagine how much testing they have to go through internaly to replicate the gold duping exploit. Until they figure it out, their maybe no way for them to discover the bug. Not all bugs are detected when compiling. You may think you have something fixed just because no compiler warnings show up anymore; but in reality, it's possible that the bug is actualy worse now. There is no garanteed way of discovering it. You have to rely on the honesty of your testing gamers.
Now, let's consider what compression really is to better understand what the engine is doing when it's compressing or decompressing files. "algorithm AL-guh-RITH-uhm, noun: A step-by-step procedure for solving a problem in a finite number of steps that often involves repetition of an operation." Meaning that it's just a math problem with certain steps that you need to complete before you get to the answer. Here is an explanation, that is much better than anything I can cover in a few paragraphs in this forum. http://www.prepressure.com/techno/compression1.htm andhttp://en.wikipedia.org/wiki/Data_compression Besides, like most programmers, I hold the belief that there is no need to reinvent the wheel. The reason I prefer you read from the link, is because you will understand why certain file formats are prefered when creating textures for models and such. Hint - There maybe a limiting factor a certain file type that will not be good for textures. What if you need Alpha masking for your texture, because you need to have some aspect of your model look as though it's hollow for one of it's features? So yes, choosing certain file types will for their particular features, can and will affect the total size of the game's foot print.
Usualy the engine will compress files during a content packaging phase. The Unreal Engine does this with a utility called UCC.EXE. It compile content that you point to in certain folders, to create a single file that can be called inside the engine by a short configuration file that tells it what it will be calling and decompressing from the package. That's why most games need alot of memory. The engine needs a very fast place to store the files until it needs them. What better place than the 2nd fastest place in your computer? Memory works fast enough to store and call the decompress content files when needed. If the game no longer needs those files, or you have limited amounts of memory, then the engine will simply flush the memory or swap it temporarily to the Virtual Memory hard disk storage space, but that's a whole other story.
The engine does not need to re-compress any of the files that it decompressed while you were playing or loading the game. It just flushes it out when it needs to. Choosing very slow, FPU intensive compression algorithms can be such big hits to game performance, that sometimes the game developpers will create a patch with optimizations that do not necessarily degrade quality, but do improve performance. It could even be as simple as writing a better File I/O method that actualy solves the problem. That's why testing is so very important.
Dude, dude, seriously---all you had to do is file a complaint with the proper government agency, we've seen complaints about file size before, we know the deal.
Dude, dude, seriously---all you had to do is file a complaint with the proper government agency, we've seen complaints about file size before, we know the deal.
Dude, dude, seriously---all you had to do is file a complaint with the proper government agency, we've seen complaints about file size before, we know the deal.
I have to agree with the above post, this is stupid and generalistic, basically by this 'form' everyone whos had a problem with any game (for instance DnL atm) MUST be a WoW/EvE fan boy, or a compete twat, isn't there such thing as a logical 'comment'? and it's wrong anyway 'Nintendi'? shouldn't that be a 'o'? plus theres no such thing as a 'Nintendo Wii' anyway offically it's just called 'Wii', if your gonna troll at least do it correctly..
Anyway back on topic: compresson aside one post was right 17gb is either one hell of a big game, or rushed coding to get a 'beta' out considering the lack of consisty between the 'pre order' and the 'open beta' versons or theres a whole load of data waiting for the poor sods when it starts.. either way lets hope it does get compressed or hope to god that the game doesn't require a complete overhall at some point cuz I recon that a 17gb 'patch' won't be well recived.. but lets wait on till it actally opens it's doors.
Vanguard is going to be mediocre. It really doesn't bring anything to the table except its' newness, really. Its mundane linear game-play, hack story-line, forced mass grouping to combat computer controlled mobs, excessive grind crafting and its harsh grind-like skill leveling consists of everything that I've perceived that mmorpg players want less of. There aren't any really new features that even remotely advance the enjoyment of mmorpg game-play.
Originally posted by Kremlik Originally posted by KaptainZerg Dude, dude, seriously---all you had to do is file a complaint with the proper government agency, we've seen complaints about file size before, we know the deal.
I have to agree with the above post, this is stupid and generalistic, basically by this 'form' everyone whos had a problem with any game (for instance DnL atm) MUST be a WoW/EvE fan boy, or a compete twat, isn't there such thing as a logical 'comment'? and it's wrong anyway 'Nintendi'? shouldn't that be a 'o'? plus theres no such thing as a 'Nintendo Wii' anyway offically it's just called 'Wii', if your gonna troll at least do it correctly.. Anyway back on topic: compresson aside one post was right 17gb is either one hell of a big game, or rushed coding to get a 'beta' out considering the lack of consisty between the 'pre order' and the 'open beta' versons or theres a whole load of data waiting for the poor sods when it starts.. either way lets hope it does get compressed or hope to god that the game doesn't require a complete overhall at some point cuz I recon that a 17gb 'patch' won't be well recived.. but lets wait on till it actally opens it's doors.
lol, you correcting my spelling and assorted other mistakes? Yeah, you got me, I messed up. Of course, mine is an attempt at humor, obviously not to be taken seriously. Your response is rubber room-quality psychobabble. So, settle down or the FGI will disappear you to a sense of humor reprogramming camp where you will only get Macintosh 2D games to play while being tortured. Rock on, dude.
And, btw, trolls don't usually post over two hundred messages and show up on the board almost every week for a year, like me. I did play a Troll in WoW, however.
if size were an indicator of quality this would be the best game ever made..however I would highly urge that anyone who is considering purchasing spend 5 bucks on a File Planet membership and try before ordering/preordering. From past experiances with betas pretty much what you see in a last month before release open beta is what will be on the shipped disks
Comments
----------
currentlyplaying:
age of conan
Amen to that. I started out on a C64 that my grandparents bought for my brother and me. I couldn't even play any games that my friends had, because they all had IBM compatibles. Of course, our school had Apples. Ah, the memories.
Insert floppy to boot.
Insert floppy to start a game.
Insert another floppy to continue loading.
Ooops, error! Reboot, insert floppy!
Oh yeah, I remember now why we loved our Atari 2600 and later the Nintendo. NO FLOPPIES TO INSERT!
Now I don't even have a floppy drive, and I've got a USB data key that's 20X bigger than my first HDD was.
Just think, in 2010 we'll all be laughing at CD-ROMs and HDDs with moving parts, and a 23GB beta test will be for a 2D MMORPG that plays in IE.
Agent_X7 AKA J Star
[/URL]
Notice: The views expressed in this post are solely those of the author and do not necessarily reflect the views of MMORPG.com or its management.
and a happy new year (2008) to you too.
You will need as minimum 2GB RAM, graphics card with min 256 RAM (preferably ATI).
Uninstall it, I have, you'll thank me in March.
No annoying animated GIF here!
downloading for 24 hours + now
searching for the next DAoC....
Kay-exile
LOL 24 hours... dude get a good isp.
Make a difference!
Amen to that. I started out on a C64 that my grandparents bought for my brother and me. I couldn't even play any games that my friends had, because they all had IBM compatibles. Of course, our school had Apples. Ah, the memories.
Insert floppy to boot.
Insert floppy to start a game.
Insert another floppy to continue loading.
Ooops, error! Reboot, insert floppy!
Oh yeah, I remember now why we loved our Atari 2600 and later the Nintendo. NO FLOPPIES TO INSERT!
Now I don't even have a floppy drive, and I've got a USB data key that's 20X bigger than my first HDD was.
Just think, in 2010 we'll all be laughing at CD-ROMs and HDDs with moving parts, and a 23GB beta test will be for a 2D MMORPG that plays in IE.
got my atari 2600 when i was 12.
got an Epson Equity 1+ when i was 15 (20mb hard drive) I remember Bard's tale was the big game back then. I wrote a 26,000 page basic program called Image Master lol i never did anything with it but it did get me through a programming class or 2.
I also had a commodore 64 when they came out.. gunship ROCKED! oh and Caveman Ughlympics
Stuck with the epson and c64 until Intel came out with the pentiums.
Make a difference!
http://www.speedtest.net/result/7300033012
LOL 24 hours... dude get a good isp.
searching for the next DAoC....
Kay-exile
Bingo. Someone who actually knows what will happen.
I hope you guys have RAM out the ass to load half of that shit, otherwise sit back and watch you HDD churn like a butter maker.
I'm not talking about the installer package. I'm talking about content packages. The installer package is something that compresses all of the content packages into a smaller foot print, to fit on the chosen delivery media.
When a game is in development, it's not unusual to find all of the game's assets like - audio in full *.WAV file, models in full *.3DS, textures to be in full *.BMP - full size files because it's easier to work with, without the Asset Manager having to create more steps to getting the updated content to CVS. Normally the Asset Manager reserves the conversion of files to smaller *.MP3 or *.OGG, *.DXT or *.PNG or what have you, and compression of all these configuration files, game scripts, textures, audio, models, into game readable "content packages" (for example Quake's *.PAK files, Unreal *.U, *.UKX, *.UTX and so on).
As for game code (the binary stuff that acutaly runs the game), once most of the debug code has been removed from the client and server executables, they start optimizing for final release. Unless there are big issues like unexplained network traffic on the client side caused by too many server requests inducing server lag, they will leave specific debug code in to continue troubleshooting the game client until they have a resolution. That usualy means that an "in development" executable that maybe 10MBs, could be reduced to 3MBs after being fully optimized and all debug code removed. Even a further point, it's common practise to put all your debug symbols into an external package and make that package switchable from the *.EXE (for example iexplore.exe /debug).
Do you feel that I need to expound further by listing Package Type differences, Aethios? If I need to make the distinction, I gladly will. I don't want anyone to be confused about what I'm saying. It should be quite clear.
OMG, you have got to be kidding right? Code has nothing to do with the size of the game install. The install size has EVERYTHING to do with the content packages not being compressed yet because it's still in development. It's easier to work with your assets when they're not compressed; so in its non-compressed format a file that would normaly be 3 to 4 MBs like a high resolution model/high polygon count static mesh would be half of that once compressed into the package.
So I don't know what to conclude from "your" experience, as code has nothing to do with it! C++ code once compiled into 001110100110000110111111111000110001000 can't get much smaller after it's optimized.
But there is a correlation between coding and the game size. Primarily with optimization. If the game is so huge with a near-release version, how sloppy was thier coding? Sure quite a bit needs to be optimized down, but with it this far in development atleast half the assets should be optimized. Infact with the Open Beta in early January, I would expect 90% of all the assets to be complete and already optimized within thier respective packets.
No. There is NO correlation between coding and the game size. Where I went to school, that's not what they're teaching in C++ 101 1st year university course. You don't learn it in 2nd year either; nor any year after that.
If the game has a large install foot print, it's because there are many assets usualy, or that the assets are not compressed into game readable compressed packages.
If the game executable is large and runs like a bloated pig, then you're right, the coding is crappy or the they didn't leverage the programming language very well.
With Vanguard's current state, unfortunatly, the games isn't in a final state until it's ready to goto Glass Master stage. Until the final build is approved, they will not proceed to Glass Master. I've seen this take upto a month.
You can expect that when they are in the final stretch coming upto the Open Beta, the Asset Manager will start compacting the game files. Until then, there is NO reason to expect it to have a small foot print.
No. There is NO correlation between coding and the game size. Where I went to school, that's not what they're teaching in C++ 101 1st year university course. You don't learn it in 2nd year either; nor any year after that.
If the game has a large install foot print, it's because there are many assets usualy, or that the assets are not compressed into game readable compressed packages.
If the game executable is large and runs like a bloated pig, then you're right, the coding is crappy or the they didn't leverage the programming language very well.
With Vanguard's current state, unfortunatly, the games isn't in a final state until it's ready to goto Glass Master stage. Until the final build is approved, they will not proceed to Glass Master. I've seen this take upto a month.
You can expect that when they are in the final stretch coming upto the Open Beta, the Asset Manager will start compacting the game files. Until then, there is NO reason to expect it to have a small foot print.
first, let me apologize for my poor wording of what I was trying to say.
basically, you are saying the large size of the game is because the files are uncompressed, because the game is in closed beta.
granted that I don't have a experienced computer programing background like you, but I always believed the compression part of the game development was usually done before beta release. Beta is meant for tweaking the game in the aspect of gameplay balances, hardware optimization, network issues, etc. It seemed illogical to me that the developers would want to leave the compression to after beta release, since they will have to waste a lot of bandwidth distributing a lot of data through the internet.
Remember Auto Assault. In beta, if I remember correctly the game was a 7 gig download (not just the original installation, but including updates as well). without hardware optimization the game ran slower than it should considering its graphics.
As the game moved from beta to gold, I got a little more framerates/sec, but the size of the game stayed the same. That's what made me assume the compression part of the game was done before beta.
But I never worked in the video game industry, so what I know are just basic experiences from beta testing past games. feel free to enlighten me
Let me answer this question in couple of parts.
Compressing/Compacting:
There are different compression types, depending at which level you need to compress, that you will use when you start down the road of compacting and finalizing the game into a retail deliverable.
Format compression: This is where you will use a compressed file format like jpg instead of bmp, or mp3/ogg instead of wav. So this is the first level at which you begin to make the game's foot print smaller. [ie - 100 bitmaps @ 3MBs each = 300MBs converted to jpeg @ 300KBs each = 30MBs + 100 text files @ average 45KBs each = 4.5MBs = 34.5MBs worth of content to be put into 1 package]
Package compression: This is when you take a large portion of similar files and create a compressed package, that the game.exe file will read and decompress the file inside the engine. Some packages are simply a renamed zip file extension like Quake 3's *.pk3 is easily renamed *.zip and you can open it to view the contents. Some other games really go through alot of trouble to make their packages proprietary, increasing the difficulty of accessing the content files inside. [ie - 34.5MBs worth of content to be put into 1 package will not compress the jpegs anymore than they are, but the text files will compress maybe 8:1 ratio]
Installer compression: This is where you prepare and plan your game installer for delivery via CD/DVD/Download media. Each variant of medium will have specific size targets. You need to plan for this, because CD contains 700MBs and if your game is 2GBs, how many CDs will you need? 2000MBs divided by 700MBs equals 2.86 CDs. Round that up to 3CDs and you know how large each segment of your installer's *.cab, *.package, or whatever file extension you choose for your installer. Most installer maker programs don't care what you use as an extension. [ie - at this point your creating a volume spanable file, much like the older programs that would split large files into segments that would span accross multiple diskettes. There is also a file "location to copy this file" database that is usualy associated with this process. It can be in one of many types of File Location Databases (FLDBs). Common FLDBs are Orca as *.MSI, simpler scripts like *.INI or *.CFG]
Anyhow, this is a HUGE topic for such a forum, but there are many places to find good information, as well as a few very good books over the last few years. Again, too many to list here.
if the game engine reads and decompresses the package, wouldn't that mean if the game engine is completed, the package compression would also be done? so in other words, would the size of this game change drastically from now to release, now that most of the compression is already finished?
also, with games like Spore, where its developers are focused on algorithmically compressing each file to allow the game have more content while taking up less space, which stage of compression are they improving? Package of File compression? and at the same time does this more effective compression method help with game performance? since the game now has to deal with less data? (although I can see why it could NOT since now the game engine has to decompress with a more complicated method).
Well, to better understand some of what this is, I recommend you visit http://en.wikipedia.org/wiki/.kkrieger site for more information, and a link to the official website that leads to a download link. Please head the warnings from the site as per the file does cause a Anti-Virus alert to popup and may even delete the downloaded file because of this.
This demo is a perfect example of using an engine to compress/decompress files, use very tight algorythms to create amazing texture effects, and contain a few really interesting maps. The file is 96KBs. That's it. Take a look at that before I answer more of this. You'll understand once you see it to believe it.
Now that you've gone to the site and probably have tested .Krieger, I can maybe shed some light.
Even if the game engine is complete, there are still lots of bugs with some of the sub features of the engine that need a great deal of time to debug. Especialy considering how long some games go without having Gold Duping exploit bugs patched up. Now you can probably imagine how much testing they have to go through internaly to replicate the gold duping exploit. Until they figure it out, their maybe no way for them to discover the bug. Not all bugs are detected when compiling. You may think you have something fixed just because no compiler warnings show up anymore; but in reality, it's possible that the bug is actualy worse now. There is no garanteed way of discovering it. You have to rely on the honesty of your testing gamers.
Now, let's consider what compression really is to better understand what the engine is doing when it's compressing or decompressing files. "algorithm AL-guh-RITH-uhm, noun:
A step-by-step procedure for solving a problem in a finite number of steps that often involves repetition of an operation." Meaning that it's just a math problem with certain steps that you need to complete before you get to the answer. Here is an explanation, that is much better than anything I can cover in a few paragraphs in this forum. http://www.prepressure.com/techno/compression1.htm andhttp://en.wikipedia.org/wiki/Data_compression Besides, like most programmers, I hold the belief that there is no need to reinvent the wheel. The reason I prefer you read from the link, is because you will understand why certain file formats are prefered when creating textures for models and such. Hint - There maybe a limiting factor a certain file type that will not be good for textures. What if you need Alpha masking for your texture, because you need to have some aspect of your model look as though it's hollow for one of it's features? So yes, choosing certain file types will for their particular features, can and will affect the total size of the game's foot print.
Usualy the engine will compress files during a content packaging phase. The Unreal Engine does this with a utility called UCC.EXE. It compile content that you point to in certain folders, to create a single file that can be called inside the engine by a short configuration file that tells it what it will be calling and decompressing from the package. That's why most games need alot of memory. The engine needs a very fast place to store the files until it needs them. What better place than the 2nd fastest place in your computer? Memory works fast enough to store and call the decompress content files when needed. If the game no longer needs those files, or you have limited amounts of memory, then the engine will simply flush the memory or swap it temporarily to the Virtual Memory hard disk storage space, but that's a whole other story.
The engine does not need to re-compress any of the files that it decompressed while you were playing or loading the game. It just flushes it out when it needs to. Choosing very slow, FPU intensive compression algorithms can be such big hits to game performance, that sometimes the game developpers will create a patch with optimizations that do not necessarily degrade quality, but do improve performance. It could even be as simple as writing a better File I/O method that actualy solves the problem. That's why testing is so very important.
Dude, dude, seriously---all you had to do is file a complaint with the proper government agency, we've seen complaints about file size before, we know the deal.
Thats the dumbest thing I've even seen.
I have to agree with the above post, this is stupid and generalistic, basically by this 'form' everyone whos had a problem with any game (for instance DnL atm) MUST be a WoW/EvE fan boy, or a compete twat, isn't there such thing as a logical 'comment'? and it's wrong anyway 'Nintendi'? shouldn't that be a 'o'? plus theres no such thing as a 'Nintendo Wii' anyway offically it's just called 'Wii', if your gonna troll at least do it correctly..
Anyway back on topic: compresson aside one post was right 17gb is either one hell of a big game, or rushed coding to get a 'beta' out considering the lack of consisty between the 'pre order' and the 'open beta' versons or theres a whole load of data waiting for the poor sods when it starts.. either way lets hope it does get compressed or hope to god that the game doesn't require a complete overhall at some point cuz I recon that a 17gb 'patch' won't be well recived.. but lets wait on till it actally opens it's doors.
Bring on the WARRRRGGHH!
Anyway back on topic: compresson aside one post was right 17gb is either one hell of a big game, or rushed coding to get a 'beta' out considering the lack of consisty between the 'pre order' and the 'open beta' versons or theres a whole load of data waiting for the poor sods when it starts.. either way lets hope it does get compressed or hope to god that the game doesn't require a complete overhall at some point cuz I recon that a 17gb 'patch' won't be well recived.. but lets wait on till it actally opens it's doors.
lol, you correcting my spelling and assorted other mistakes? Yeah, you got me, I messed up. Of course, mine is an attempt at humor, obviously not to be taken seriously. Your response is rubber room-quality psychobabble. So, settle down or the FGI will disappear you to a sense of humor reprogramming camp where you will only get Macintosh 2D games to play while being tortured. Rock on, dude.
And, btw, trolls don't usually post over two hundred messages and show up on the board almost every week for a year, like me. I did play a Troll in WoW, however.
I miss DAoC