Post by Mystery on Mar 16, 2014 10:56:40 GMT -5
(warning: this is a very long posting with no pictures)
Hey everyone,
for quite a while now I've been thinking about the numerous and obvious limitations of GCS and how to work around them, using different methods or tricks.
I've tried looking at the different shortcomings of the engine and the reason behind this. I found out that most issues were part of one single problem and that there might be a single solution to a lot of the problems GCS developers face.
Note: It's been quite a while since I've worked with the GCS so there might be some inaccuracies and/or questions from my side. This whole thread is more of a brainstorming idea with the goal to create future guides/tutorials, get more people interested in the engine and grow the community and number of quality titles using GCS. Okay, that might be a little bit far fetched, but who knows
Alright, let's get started. Here are the most annoying issues/limitations people will be facing when coding with the GCS:
1) only one enemy type per level
2) no real lighting/shadows
3) severe memory issues, limiting the number and size of textures
4) hard coded limit of 768 objects per level
5) Lack of interactive objects (due to both memory and object limits)
6) Lack of visual fidelity because of the palette system
Some problems would have a pretty simple solution if we had access to the engine's source code, but since all attempts to obtain it from Pie in the Sky software have failed, there's not much we can do about those. These issues include but are not limited to:
-no real skybox effect
-no variable hud/interface layout/size
There are probably a lot more things that can be listed here and I'd like to extend both lists and try to find solutions for each problem.
The problems listed above cause the levels to feel empty and repetitive. You have to use the same textures over and over, you can't put too much stuff into one level or it won't work or require too much memory, textures are usually low res, to save memory, resulting in low detail etc.
The solution I propose for pretty much all of these is splitting up the levels into smaller chunks. The smaller, the better. Of course this will work better with indoor scenarios, but you might be able to make use of this outdoors as well.
Before I go into detail, I'll talk about some of the drawbacks using this method:
-more loading times are unavoidable
-I'm not sure if all game logic is kept intact when switching levels. Some scripts/events/triggers might not work anymore
-levels might feel smaller
-the whole game will be shorter as the number of levels is limited and you're using several of these to create just one level
-it'll only work if I'm right about every level starting with empty memory that gets filled by the individual textures/sprites used there
But on the other hand, it should allow for much more detailed and varied levels. This is how we do it:
1) Sure we still can have one enemy type per level, but there already are workarounds for that and some games even use that method: Stationary enemies. Use objects that can shoot at the player and look like an enemy, only it's not moving.
But if we split up one indoor level into different rooms/sections, we still can technically have just one enemy type, but it's limited to a smaller portion of the level.
Stand in a corridor: Guards before a door. Kill the guards, enter the room (load a new level), there's a crazy scientist inside. Enter the room next to it (different level): A robot is guarding the place.
Even though you still have one enemy type per level, it won't feel like it anymore. Combine that with stationary object-type enemies and you can put a lot more varied enemies in your game
2) There's a simple solution for that but it's a lot of work and won't function in larger levels. But fortunately we've trimmed down the level size significantly and have more memory available.
When designing a level we take note of the light sources, the objects in the level and the way the light would cast shadows. Then we create custom textures for every spot on the wall that would have a shadow cast upon it. Shadows are painted on the wall texture and then put into the game exactly where it's needed. That way the room will look like there's actual lighting going on. Well, not quite since we can't work with the floor or ceiling very well, but still.
I suggest using darker shadows since the palette is limited.
3) This is a variation of the second option. Because we've got more memory available we can use a LOT more textures in our single-room-levels. We don't have to worry about creating a one-use only texture eating up memory for the whole level anymore. Torn wallpaper, bulletholes, different posters and pictures, furniture, shelves with varying content...go nuts. We can also combine this with higher resolution textures. Sure they use up MUCH more memory, but we don't have to worry about that as much as before. Sure, if we use all 200x200 textures, we'll still be at the memory limit pretty quickly.
4) There's a fixed limit of 768 objects per level. This limits the amount of detail we can display significantly...IF we put the whole level into one file. When splitting the whole thing up, we suddenly get 768 objects per ROOM, which allows for a huge amount of additional detail. More small objects, sprites, detailed architecture, you name it.
5) More Interactivity:
In theory there's a lot we can do with the games register/trigger system, but its use is limited by memory restrains, again. With more memory freed up, we can create things like:
-shooting and destroying almost every sprite/object in a room
-animated shattering glass windows
-probably even bullet holes in a wall (although the effect might look odd because we can't actually place a bullet hole where the player shot, just a texture with a bullet hole above the approximate area where the player shot at)
-several different looking (static) animated NPCs in a single room
-in general a lot more animations
-and much more...
Like I said, that's already possible, but probably not a good idea to use excessively. Having a bunch of graphics for destroyed objects and maybe even animations for them being in the process of breaking/shattering, will use up a lot of valuable mamory. But since we've now got more memory than we used to, we can put more visual effects in the levels/rooms.
6) More fideliy, optimizing the look of the game:
GCS uses a limited palette system for the whole game. You can only use 256 colors for -everything-. Other games use much more colors, but only display 256 of them at a time, but GCS is much more restrictive.
Unless we make different "games" for each level with their own executable and palette (or obtain the source code) we can't do anything about that. What we CAN do it optimize the palette to our needs. This will of course require excellent planning because all visual game assets need to be created beforehand. But once that's finished, we can make a custom palette for these assets, resulting in a better looking game. Another solution would be to build a prototype of the game first, and recreate the whole thing again with the new palette and assets. Like I said, it's a lot of work and I'm not even sure how good the results would be, given that you can already achieve pretty good looking visuals with the standard palette.
So, what do you think? Is it feasible? I imagine, if there's not a catch to the whole thing, that this might be a way to create much better levels, at least visually. Good level design isn't replacable by better graphics
Hey everyone,
for quite a while now I've been thinking about the numerous and obvious limitations of GCS and how to work around them, using different methods or tricks.
I've tried looking at the different shortcomings of the engine and the reason behind this. I found out that most issues were part of one single problem and that there might be a single solution to a lot of the problems GCS developers face.
Note: It's been quite a while since I've worked with the GCS so there might be some inaccuracies and/or questions from my side. This whole thread is more of a brainstorming idea with the goal to create future guides/tutorials, get more people interested in the engine and grow the community and number of quality titles using GCS. Okay, that might be a little bit far fetched, but who knows
Alright, let's get started. Here are the most annoying issues/limitations people will be facing when coding with the GCS:
1) only one enemy type per level
2) no real lighting/shadows
3) severe memory issues, limiting the number and size of textures
4) hard coded limit of 768 objects per level
5) Lack of interactive objects (due to both memory and object limits)
6) Lack of visual fidelity because of the palette system
Some problems would have a pretty simple solution if we had access to the engine's source code, but since all attempts to obtain it from Pie in the Sky software have failed, there's not much we can do about those. These issues include but are not limited to:
-no real skybox effect
-no variable hud/interface layout/size
There are probably a lot more things that can be listed here and I'd like to extend both lists and try to find solutions for each problem.
The problems listed above cause the levels to feel empty and repetitive. You have to use the same textures over and over, you can't put too much stuff into one level or it won't work or require too much memory, textures are usually low res, to save memory, resulting in low detail etc.
The solution I propose for pretty much all of these is splitting up the levels into smaller chunks. The smaller, the better. Of course this will work better with indoor scenarios, but you might be able to make use of this outdoors as well.
Before I go into detail, I'll talk about some of the drawbacks using this method:
-more loading times are unavoidable
-I'm not sure if all game logic is kept intact when switching levels. Some scripts/events/triggers might not work anymore
-levels might feel smaller
-the whole game will be shorter as the number of levels is limited and you're using several of these to create just one level
-it'll only work if I'm right about every level starting with empty memory that gets filled by the individual textures/sprites used there
But on the other hand, it should allow for much more detailed and varied levels. This is how we do it:
1) Sure we still can have one enemy type per level, but there already are workarounds for that and some games even use that method: Stationary enemies. Use objects that can shoot at the player and look like an enemy, only it's not moving.
But if we split up one indoor level into different rooms/sections, we still can technically have just one enemy type, but it's limited to a smaller portion of the level.
Stand in a corridor: Guards before a door. Kill the guards, enter the room (load a new level), there's a crazy scientist inside. Enter the room next to it (different level): A robot is guarding the place.
Even though you still have one enemy type per level, it won't feel like it anymore. Combine that with stationary object-type enemies and you can put a lot more varied enemies in your game
2) There's a simple solution for that but it's a lot of work and won't function in larger levels. But fortunately we've trimmed down the level size significantly and have more memory available.
When designing a level we take note of the light sources, the objects in the level and the way the light would cast shadows. Then we create custom textures for every spot on the wall that would have a shadow cast upon it. Shadows are painted on the wall texture and then put into the game exactly where it's needed. That way the room will look like there's actual lighting going on. Well, not quite since we can't work with the floor or ceiling very well, but still.
I suggest using darker shadows since the palette is limited.
3) This is a variation of the second option. Because we've got more memory available we can use a LOT more textures in our single-room-levels. We don't have to worry about creating a one-use only texture eating up memory for the whole level anymore. Torn wallpaper, bulletholes, different posters and pictures, furniture, shelves with varying content...go nuts. We can also combine this with higher resolution textures. Sure they use up MUCH more memory, but we don't have to worry about that as much as before. Sure, if we use all 200x200 textures, we'll still be at the memory limit pretty quickly.
4) There's a fixed limit of 768 objects per level. This limits the amount of detail we can display significantly...IF we put the whole level into one file. When splitting the whole thing up, we suddenly get 768 objects per ROOM, which allows for a huge amount of additional detail. More small objects, sprites, detailed architecture, you name it.
5) More Interactivity:
In theory there's a lot we can do with the games register/trigger system, but its use is limited by memory restrains, again. With more memory freed up, we can create things like:
-shooting and destroying almost every sprite/object in a room
-animated shattering glass windows
-probably even bullet holes in a wall (although the effect might look odd because we can't actually place a bullet hole where the player shot, just a texture with a bullet hole above the approximate area where the player shot at)
-several different looking (static) animated NPCs in a single room
-in general a lot more animations
-and much more...
Like I said, that's already possible, but probably not a good idea to use excessively. Having a bunch of graphics for destroyed objects and maybe even animations for them being in the process of breaking/shattering, will use up a lot of valuable mamory. But since we've now got more memory than we used to, we can put more visual effects in the levels/rooms.
6) More fideliy, optimizing the look of the game:
GCS uses a limited palette system for the whole game. You can only use 256 colors for -everything-. Other games use much more colors, but only display 256 of them at a time, but GCS is much more restrictive.
Unless we make different "games" for each level with their own executable and palette (or obtain the source code) we can't do anything about that. What we CAN do it optimize the palette to our needs. This will of course require excellent planning because all visual game assets need to be created beforehand. But once that's finished, we can make a custom palette for these assets, resulting in a better looking game. Another solution would be to build a prototype of the game first, and recreate the whole thing again with the new palette and assets. Like I said, it's a lot of work and I'm not even sure how good the results would be, given that you can already achieve pretty good looking visuals with the standard palette.
So, what do you think? Is it feasible? I imagine, if there's not a catch to the whole thing, that this might be a way to create much better levels, at least visually. Good level design isn't replacable by better graphics
