Castlevania Dungeon Forums
The Castlevania Dungeon Forums => Fan Stuff => Topic started by: Corpsecrank on February 18, 2012, 01:18:16 AM
-
Basically what this thread is about is discussing different aspects of game making. More specifically technical aspects that cause snags or headaches and different methods for dealing with that.
We have a lot of people working on fan games here. More than I have seen anywhere else actually. Because of that I thought discussing different methods we use for dealing with certain things might be beneficial. For those that are new to game making it can help give you a better understanding of what goes on "behind the scenes" in a game.
If you are going to discuss anything be sure to note the application or method you are using to make games. If you are using game maker, flash/actionscript, code from scratch etc.
I guess to start this off I would like to ask a question. Tiling in a game necessary or not? What would stop you from using solid layers for the background and then setting up an invisible area for a character to collide with and walk on? What are the advantages/disadvantages to tiling or not tiling? Specifically for platforming games I suppose just to keep things clear. I never gave any real thought to breaking everything into tiles vs just tossing in a background and designating a solid area of collision for the character to move along. This is why I want to ask if there is any good reason to use a tiling setup instead.
-
Beyond a shadow of a doubt, the most important technique in game creation is backups. Always keep multiple back ups in multiple places. And at least one of those should be kept in an online archive such as mediafire. Far too often have I seen great projects that show promise be taken down by the loss of the work due to a crash or what not.
-
Beyond a shadow of a doubt, the most important technique in game creation is backups. Always keep multiple back ups in multiple places. And at least one of those should be kept in an online archive such as mediafire. Far too often have I seen great projects that show promise be taken down by the loss of the work due to a crash or what not.
Agreed, I have a dropbox sorely for this. It would also be wise to give fans a beta version of your game so you can always have something to fall back on...
-
Yeah backups are important beyond just making games. Any project should be thoroughly backed up to prevent loss. I once lost an entire month of work on a game server because my backup failed and I only had one on disc. The disc didn't burn properly and it contained everything I had done since the previous backup. This was back in the end of the win98 days though. Back then if you did the kind of work on your pc we do today by the end of the month it completely wrecked the system and you would need to restore it to clear up all the crashing and glitching the system would have going on. I am so glad they finally got a stable OS out these days.
-
Basically what this thread is about is discussing different aspects of game making. More specifically technical aspects that cause snags or headaches and different methods for dealing with that.
We have a lot of people working on fan games here. More than I have seen anywhere else actually. Because of that I thought discussing different methods we use for dealing with certain things might be beneficial. For those that are new to game making it can help give you a better understanding of what goes on "behind the scenes" in a game.
If you are going to discuss anything be sure to note the application or method you are using to make games. If you are using game maker, flash/actionscript, code from scratch etc.
I guess to start this off I would like to ask a question. Tiling in a game necessary or not? What would stop you from using solid layers for the background and then setting up an invisible area for a character to collide with and walk on? What are the advantages/disadvantages to tiling or not tiling? Specifically for platforming games I suppose just to keep things clear. I never gave any real thought to breaking everything into tiles vs just tossing in a background and designating a solid area of collision for the character to move along. This is why I want to ask if there is any good reason to use a tiling setup instead.
Because it is not as easy to edit then for one thing. Since it is a whole background instead of separate tiles. Also, in games that use solid/unsolid tiles, no collision checking is done on non-solid tiles. Which means less resources are used, since collision with EVERY tile is not checked.
-
Using Game Maker, I've already shown how to reduce memory usage by scaling the invisible solid objects. But as Esco said and as I have argued for months now on GMC (to deaf eyes, since they're all more stubborn than range horses), any object that has no real use is wasted space. Sure, it makes things easier to work with many times, but it's still a waste. In my Castlevania engine, splash effects and rubble from broken walls are objects, but that's horrible planning on my part; they should be sprites drawn via timeline accessed via the broken wall or the player.
Anyway, I've also already shown that in Game Maker you can easily (... the term is used loosely) program an entire game with no collision objects, just tiles. I've even argued that in theory you could program an entire game with just a handful of invisible controller objects that just draw sprites to the screen (although that would be nuts).
The only argument that I've made on GMC that has been validated by anyone of note on that forum is that a game constructed around tiles rather than invisible solid collision objects will run many times faster and be less of a memory hog.
-
a game constructed around tiles rather than invisible solid collision objects will run many times faster and be less of a memory hog.
See I actually would have guessed the opposite to be true since individual tiles would need to be loaded to memory. A couple of large layers vs the same number of layers with tons of smaller items seems like the number of items would slow things down more.
Considering that what is the best method for breaking up graphics into tiles? Is there really any specific way to break things up or can you slice the graphics up any way you see fit? I know some tiles would be things that would repeat like the blocks in classic castlevania games but what about more complex things like the ds games and sotn? It doesn't seem like those would be as easy to break apart. I guess I will have to go play with some roms and see how they were busted up in the original games.
Interesting stuff. I would like to try both methods with benchmarking and post the results when I get some time. Been moving all month so I only have a couple hours a day at the moment. I think it would be great to keep updating this with examples of good ways for handling things. It could prove really useful for people who plan on making a game anyhow.
-
it all depends on the program used. GameMaker you almost HAVE to be tile based with objects cause of performance. It was designed that way. Somethin like html 5 it wouldnt matter cause its just graphics like anything else. It might actually be better to use full backgrounds instead of tiles with it.
traditionally 2d games are done with tiles cause of useability small size and memory restrictions. Theres no reason that has to be true now... UNLESS your program was designed that way
-
Well fo rmy game I am using MMF2 so I am guessing I should use a tile set instead of a full background but I could be wrong too. I am still new to this myself. Maybe I should ask around over on the MMF2 forum which is best since that is what I use.
The html5 thing makes sense but I know nothing about html5. I keep hearing it is so amazing and will eventually replace flash etc. Is it really that great though? Also with html5 wouldn't you be restricted to a browser or is it able to be used without a browser? Not real familiar with html outside of web page stuff and even then I have limited knowledge.
Back to tiles vs full backgrounds. Lets expand on this some and look at games other than platformers. I know an rpg can benefit more from tiles especially when talking classic style final fantasy games. What are the differences and pros cons?
-
pros of tiles would be more variety in locations for typical 2d rpgs. 1 tileset can make dozens of different buildings that all look similar but not the same. Each building would have to be a individual img without a tileset. Thatd mean if you wanted a layout you didnt already have youd either have to do without or make it. But with tiles you could just arrange em as close to what you envisioned for the layout (and depending on how well the tileset was made) you wouldnt have to make any changes to the graphics you already had
You can also add a new tile to an existing tileset with as little effect as adding a whole new img. The difference is that new tile can be added into any existing maps AND new ones
The main thing would be how your game needed to be made from the beginning. If you wanted big graphics similar to Odin Sphere then itd make more sense to have big backgrounds cause tiles arent really ideal. But if you want to make somethin like a oldschool 2d rpg or a platform game then tiles would be a smarter idea
-
Yeah that makes sense. I remember how odd it was when they started using the "pre-rendered" backgrounds in rpgs around the ff7 years on psx. ff7 and saga frontier both used them and it was kind of a huge shift from the tile based era that came before. I remember having a difficult time finding exits on some maps and being able to determine what areas you could and could not walk on. With tiles you could almost always tell when an "edge" was.
Something I still wonder about though. Are we really that limited today? Look at the average pc and the amount of resources we have. Is memory and performance an issue for a game that is sprite based? There were obvious limitations on old consoles and even today a console vs a pc is like day and night. A cheap pc can easily out perform the best console on the market. You can spend 500 bucks and build a computer with superior graphics and resources because console hardware is like 10 years behind in a lot of areas especially graphics.
I guess that is why I have to wonder if we really need to be as concerned about resource usage. Other than efficiency I suppose. Because it is poor habit to just hog resources. I just wonder if you could even notice the difference without checking the resource usage.
I still need to dig around and find more info about tiling graphics in games. Specifically the best way to chop the graphics up. I will probably have to get my hands dirty with some roms though since I need to see specifically how certain graphics were broken up. Regardless of which uses less resources the question for me becomes which one is more flexible and I think tiling is obviously more flexible than solid backgrounds.
I have this weird way of thinking since I have spent more time creating and using graphics inside programs like flash. I feel like it is easy enough to make a single sheet of graphics as a psd or ai file and then change things there as needed. But with games it's not quite as easy. I can link and update my changes in a program like flash or illustrator lol. I guess that was why I had originally given tiles no real consideration over a solid background.
When I animate in flash if there is a change needed to a background I have used hundreds of times I can simple update my graphics in photoshop or illustrator and then update all instances of that background in flash in one shot. To bad MMF2 and other game making programs don't work that way eh.
-
Do you want your rooms of each stage to be 5MB to 25MB or just 500k? Do you want to spend a few days constitutions each room, or a few hours? Do you want your game to be unplayable on lower end computers? Do you want your game to have a terrible frame rate unless the PC is way over current standards?
Tiled graphics exist for a very good reason. Think about it for a moment, and you'll realize; 3D games also used 'tiled' graphics. It was never abandoned, or overcome, or outdated. It's very much in use today as it ever was.
-
yeah just look at BethSoft games from Morrowind to Skyrim they all use tiles lol. Besides terrain 3d tiles make their entire games indoors and out
But I think Uzo means the textures tile mainly. 1 2*x2* texture tiled across the surface
-
If you really want to be a smart ass, then realize each polygon is a 'tile'.
But of course, I mean textures. Even if not in exactly the same format, each texture has coordinates for the specific reusable portion of the image grouping. It's the same exact concept as traditional tiled 2d graphics, for the same exact reason. Reusability, centralization, and resource efficiency.
-
If you really want to be a smart ass, then realize each polygon is a 'tile'.
But of course, I mean textures. Even if not in exactly the same format, each texture has coordinates for the specific reusable portion of the image grouping. It's the same exact concept as traditional tiled 2d graphics, for the same exact reason. Reusability, centralization, and resource efficiency.
I don't agree though. Textures across a 3D model are not like tiles in a 2D game at all. I know because I have worked with 3D meshes and models and they are VERY different. The texture is applied to a surface not a tile and each surface must have a texture applied to it to cover all the bare spots on the model. That is completely different than a tile because the size of the surface to be covered can vary in size and while a texture may be scaled and/or repeated as needed it is a totally different subject than sprite tiles.
I don't understand the idea that breaking up the same amount of graphics over a screen could effect how much memory it takes to load those graphics. Bottom line you are drawing the same amount of graphics on screen no matter how those graphics are put together. I think the memory usage must come from how the engine handles those graphics vs how the graphics are pieced together either as a whole or as chunks. But if you understand why smaller pieces = less resource usage please explain it because that is the point to learn why these things matter and how they make a difference.
-
I don't understand the idea that breaking up the same amount of graphics over a screen could effect how much memory it takes to load those graphics.
Seriously? You can't understand a 256x256 texture takes less memory than a 2048x2048 texture?
I just- How could- Your post is just a giant wall of dribble. I've already explained exactly why the centralized 'tiled' graphic concept was created, and why it still remains a central part of game program design to this day even in 3D games. Apparently you didn't bother reading anything I already wrote. So, fuck it, I quit.
-
Seriously? You can't understand a 256x256 texture takes less memory than a 2048x2048 texture?
I just- How could- Your post is just a giant wall of dribble. I've already explained exactly why the centralized 'tiled' graphic concept was created, and why it still remains a central part of game program design to this day even in 3D games. Apparently you didn't bother reading anything I already wrote. So, fuck it, I quit.
No I can't understand that a texture takes more or less memory because I am not talking about textures I am talking about bitmap sprite graphics. But since a texture is never a different size because it gets stretched and tiles but the base texture is always static I guess it couldn't be any larger than it started out could it?
I don't know where you got on this texture thing at I was trying to discuss 2d tiles not 3d textures.
I don't understand how a 500x500 pixel image can take up more memory than 10 - 50x50 pixel images would. THAT is what I am talking about.
-
technically it cant. The difference would come from the object data in memory mainly. There shouldnt really be any more memory use either way. The problem comes when you need MORE than that 1 large image loaded. Say 20 things on screen all use the same texture (tile set) but 1 thing on screen uses another texture (different tile set) then both of those have to be loaded in memory completely even tho the 1 that uses the 2nd tile set is only usin 1 tiny part of it.
Another thing to think about. Say you have a huge background you wanna use for like a town. Now say the next map needs the edge of that town as the startin part. Do you put the entire town background in that map and just move it so only the part you need is shown? Or make a new graphic with just the part you need? If it was just a tile set it wouldnt matter.
Like I said before. It all comes down to how the game was designed from the very beginning for what kinda graphics it needs. Hell you could even make a game like Odin Sphere with tiles if ya wanted... Just very big tiles in sets for very specific parts. Which is prolly how it was made anyway
-
even character model sheets for games like say, Megaman legends or probably even Lament, are tile sheets. Ever look at texture rips?
(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fwww.sprites-inc.co.uk%2Ffiles%2FLegend%2FLegends%2Ftextures%2FCharacters%2Fmml1juno1.png&hash=522f4989a9e0ab43310a87fe7cb5b5551344bbc7)
-
Why the F would you make ten 50x50px tiles for a 500x500 background? A tile should never be more than 8x16, 16x16, 8x32, or 32x32 in size.
You are completely missing the points of all this.
1) Tiles can be repeated. It's called tiling. Either that's why they're called tiles or that's why it's called tiling. Either way, tiles and textures are the exact same. Yes, you can even stretch tiles.
2) A tile is placed on a 2D surface in a 2D plane. A texture is placed on a 2D surface in a 3D space. That's the only difference between a tile and a texture.
3) A tile is not the same as a map (the term used in Gameboy Advance and DS emulators). Let's look at Dragon Force on the Sega Saturn, as it's a prime example of the difference between tiles and maps.
This is a map (http://i23.photobucket.com/albums/b377/Draymius/00000124.jpg).
As is this. (http://hardcoregaming101.net/segaages/dragonforce-saturn1.jpg)
But this is made from tiles. (http://www.rpgamer.com/games/other/sega/dforce/screens/0975.jpg)
This is made of tiles placed over a map. (http://citronfraise.files.wordpress.com/2010/12/dragon-force-saturn-5.jpg)
Full-screen portraits aren't tiles; they don't need to be in most cases. There are exceptions to the case, though. Take Kirby for example. This would be done with tiles (http://www.spriters-resource.com/nes/kirbyadv/pausescreen.png) because there's so much wasted memory otherwise due to the repetition of 8x8 color blocks. Break it down to 8x8px cells and count all the monotone pink or monotone white cells in the pause screen. Take them all out except for one each and compress them all together and see how much memory you save.
-
thats not a tile sheet Flame thats a skin. It looks like it could be but thats just how the modeller laid out the UV of the model so the texture could be made. Pretty much EVERY 3d game uses skins for things similar to that for the models. Theres some exceptions and things that can be done without that kind of skinning but its kinda rare especially in characters
And Theou tiles can be any size generally as long as its a power of 2. Its just typical that theyre 32x32 or smaller for 2d games. They can easily be 128x128 and still be used just fine
-
Well yeah, but you don't make 128x128 tiles typically unless you have a high resolution room. A 500x500 room is a far cry from a resolution that would make 128x128 or even 50x50 tiles logical. A 500x500 room should be a map if you have no way of reducing its presence in the ROM by at least 25%. A 128x128 tile of a foreground tree is much different in use than a 128x128 grass tile.
-
Why the F would you make ten 50x50px tiles for a 500x500 background? A tile should never be more than 8x16, 16x16, 8x32, or 32x32 in size.
You are completely missing the points of all this.
1) Tiles can be repeated. It's called tiling. Either that's why they're called tiles or that's why it's called tiling. Either way, tiles and textures are the exact same. Yes, you can even stretch tiles.
2) A tile is placed on a 2D surface in a 2D plane. A texture is placed on a 2D surface in a 3D space. That's the only difference between a tile and a texture.
3) A tile is not the same as a map (the term used in Gameboy Advance and DS emulators). Let's look at Dragon Force on the Sega Saturn, as it's a prime example of the difference between tiles and maps.
This is a map (http://i23.photobucket.com/albums/b377/Draymius/00000124.jpg).
As is this. (http://hardcoregaming101.net/segaages/dragonforce-saturn1.jpg)
But this is made from tiles. (http://www.rpgamer.com/games/other/sega/dforce/screens/0975.jpg)
This is made of tiles placed over a map. (http://citronfraise.files.wordpress.com/2010/12/dragon-force-saturn-5.jpg)
Full-screen portraits aren't tiles; they don't need to be in most cases. There are exceptions to the case, though. Take Kirby for example. This would be done with tiles (http://www.spriters-resource.com/nes/kirbyadv/pausescreen.png) because there's so much wasted memory otherwise due to the repetition of 8x8 color blocks. Break it down to 8x8px cells and count all the monotone pink or monotone white cells in the pause screen. Take them all out except for one each and compress them all together and see how much memory you save.
I wouldn't do that and I didn't miss the point those numbers were purely for example sake and nothing more. You kind of took that a bit literally.
What I mean is that something is X number of pixels wide and tall and you are filling a screen with an image. No matter how you display what is on the screen you must be filling it with something. So a screen size of say 600x800 is always going to have 600x800 pixels on it. I wanted to know why filling it with smaller images is different than filling it with a full 600x800 image. Does that make sense?
I know that tiles can repeat but does that actually lower the memory use? If it did I would understand how it could be better. But there are still other advantages yet like the ability to edit easier or simply reuse the same tiles in other parts of the game without creating a new image.
Come to think of it you could lower the size of the game as a whole by using the same tiles in different areas as the game would contain less artwork total. Maybe that is actually the point of tiles in older games which had limited cartridge space. Even discs are limited to 700mb a piece. That would be a great reason alone to use tiles over full size images.
But I think this is getting kind of out of hand anyways. This has gone from learning to arguments and I for one have no more time for that. It has become counter productive so I am going to go back to work where my time is better spent.
-
Even regardless of the ROM size, you're still having to load those images into the computer's memory. Tiles allow you to free up more memory on the player's computer for other functions instead of the graphics. If I load up your game and my page file fills up with 2 gigs of 800x600 portraits, I'd be pissed.
-
even character model sheets for games like say, Megaman legends or probably even Lament, are tile sheets. Ever look at texture rips?
(https://castlevaniadungeon.net/forums/proxy.php?request=http%3A%2F%2Fwww.sprites-inc.co.uk%2Ffiles%2FLegend%2FLegends%2Ftextures%2FCharacters%2Fmml1juno1.png&hash=522f4989a9e0ab43310a87fe7cb5b5551344bbc7)
You misunderstand what those really are and how they are applied to the game. When you look at the rip you are seeing an image of the textures applied across a surface of a 3D model. Those aren't "tiles" each one of those get mapped to a surface which is quite a bit different than a flat bitmap object on the screen. Those may not even be 100% accurate because of how they get ripped. It greatly depends on how good the ripper is and how well they understand the tools and what to rip and how well the tool can do the job. That is why I keep trying to keep 3D and textures out of the conversation it doesn't apply to bitmap tiling in a 2D game.
It doesn't matter either way I did more research on the subject on my own and found out everything I need to know.
-
It doesn't matter either way I did more research on the subject on my own and found out everything I need to know.
So then does that mean you understand why using tiles uses less memory?
-
So then does that mean you understand why using tiles uses less memory?
Kind of. I understand how using tiles can give advantages anyhow. Even if it were not saving memory there are other reasons to use it that make sense. I do understand how you can save on memory by using tiles but not in a sense that objects on the screen must still be drawn and that there is memory usage there as well. The idea that instances of a single piece of art take less memory to cover a screen does make sense though. Similar to instancing objects in flash animations. A single image can have lots of instances and your file will be small and handle well while lots of physical copies to make up the same thing would lead to a large file and poor handling.
The thing is if your tiles were all different for a screen and you couldn't take advantage of using instances of a tile would you still be saving any memory? That is really the issue for me. I still want to know if you have to fill a screen and you can't use duplicate tiles to do so is there a reason to chop those particular graphics up into tiles? Unless of course you wanted to use parts of those graphics in other areas of the game. But for a single screen where nothing would be reused are you better off using a solid image vs tiles or is it still better to break it all apart into smaller tiles anyways.
-
That's the thing right there. The actual graphics that appear on the screen take up memory besides the graphics themselves. Roughly, this is the way it works: the pixels that appear in a 640x480 space need to have memory for that 640x480 pixel space all the time no matter what. If the background you're using is a big background that, say, is 5 screens long then you also need to use 640x480x5 pixels worth of memory to have them available to display. Making the total memory usage 640x480x6. 1 for what is currently visible and 5 for the full background. However, if you condense the whole background into a 640x480 tileset that does the same job. But you're now only using a total of 640x480x2 pixels worth of memory. So with a large single image background that's 640x480x6 = 1,843,200 pixels in memory. While condensed in a single tileset it's 640*480*2 = 614,400 pixels in memory. That's a huge difference.
-
That's the thing right there. The actual graphics that appear on the screen take up memory besides the graphics themselves. Roughly, this is the way it works: the pixels that appear in a 640x480 space need to have memory for that 640x480 pixel space all the time no matter what. If the background you're using is a big background that, say, is 5 screens long then you also need to use 640x480x5 pixels worth of memory to have them available to display. Making the total memory usage 640x480x6. 1 for what is currently visible and 5 for the full background. However, if you condense the whole background into a 640x480 tileset that does the same job. But you're now only using a total of 640x480x2 pixels worth of memory. So with a large single image background that's 640x480x6 = 1,843,200 pixels in memory. While condensed in a single tileset it's 640*480*2 = 614,400 pixels in memory. That's a huge difference.
That makes sense to. But what if say I only needed to fill a single 640x480 would single images be any different than tiles in that case? You only have to fill 1 640x480 screen and the background wouldn't scroll so I wouldn't think there would be any reason to tile. Not unless you were able to take advantage of tile instances to save on usage.
-
That makes sense to. But what if say I only needed to fill a single 640x480 would single images be any different than tiles in that case? You only have to fill 1 640x480 screen and the background wouldn't scroll so I wouldn't think there would be any reason to tile. Not unless you were able to take advantage of tile instances to save on usage.
Yes, it would still make a difference because the memory space for the graphics are always separate from the actual image being displayed. Even if it's a single screen and you can condense the bg into a smaller set of tiles you'll be saving on memory usage.
-
It's been said you shouldn't try to simplify things before you actually make anything because in the end you'll make things worse, but that's also probably why so many games these days waste resources. In many cases you can tile something that normally wouldn't be thought of as tiled. Take the image in question and apply an 8x8 grid over it. Look for ANY tiles that are duplicated. Don't see any? Consider reducing the color count or changing some tiles so they're duplicated. If that's not an option and you can't break it down, then go ahead and use the full image.
And games these days ARE wasteful. Programmers don't take the time they need to to optimize their space and coding. Everyone nowadays has the destructive mentality that since the media can hold larger ROMs, there's no need to optimize the ROMs. For sprite rippers, it's nice because it's easier to align sprites, but moving from ripping NES and SNES sprites to ripping GBA and DS sprites, it's become apparent how wasteful designers have gotten. In GeGeGe Kitarou on the GBA, if the programmers optimized their sprites, they could have freed up possibly 32kb or more. That might not sound like much, but in terms of graphics memory that is a lot.
-
I been pretty much picking out patterns found in full background and selecting that area and popping it out into a separate sheet. Anything that doesn't follow the standard patters I see gets pulled as is and tossed onto the sheet. That does mean floors walls stairs and more are all repeated tiles while odd objects found here and there are a lot larger. Should make a large difference but it is extremely tedious. I had to much trouble with tile viewers etc and wasn't able to pull the tile sheets straight from the rom. So it's all photoshop and full backgrounds right now while I pull them apart. It's enough to make you cry doing this but the payoff in the end is probably worth it.