Discussion: Breaking GCS limitations

[Mystery]

(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

[Saturdaynight]

Great Post! Early in your post you asked about; "-I'm not sure if all game logic is kept intact when switching levels. Some scripts/events/triggers might not work anymore"

Say you're in one room, i.e. level 1, and you kill all the guards, then you move to the next room, i.e., level 2. When you return to level 1, the game engine remembers that the guards were all killed. I'm fairly certain that the engine remembers this fact and the guards are still destroyed when you return to level 1. It would only make sens that the scripts and event triggers would still hold true in the same manner. I think all of that is held in the universal register for the game. Someone correct me if I'm wrong but I think the engine works that way.

The part about level switching is a great idea and I kind of did that with MOD-G to a point. It just sucks that you have the stop watch with the black screen between levels.

The Windows engine did away with this and if you've ever played House of Catholon, the developer did just that with Level switching. It felt only like a pause in the game when you switch levels. It was a brilliantly devised level switch. if only we could do that in the DOS GCS.

[Mystery]

Yes, the level switching itself is a little bit awkward, but I think the potential advantages outweigh the loading screen annoyance by far. In House of Cathalon the loading is much better, but I'm afraid there's no way to speed up the loading in the DOS engine.

If the universe registers (as the name subtly suggests) have indeed global functionality and if the game remembers the states of objects, enemies and registers when going back and forth in between "levels", this would work.

With this method it should be possible to create GCS DOS games at a visual level that nobody would ever expect from that engine. It's not quite Doom, but with proper artwork we should be able to surpass Wolf3D even further and get a lot closer to Doom.

[lgb3d]

Mar 25, 2014 2:42:37 GMT -5 Mystery said:

Yes, the level switching itself is a little bit awkward, but I think the potential advantages outweigh the loading screen annoyance by far. In House of Cathalon the loading is much better, but I'm afraid there's no way to speed up the loading in the DOS engine.

If the universe registers (as the name subtly suggests) have indeed global functionality and if the game remembers the states of objects, enemies and registers when going back and forth in between "levels", this would work.

With this method it should be possible to create GCS DOS games at a visual level that nobody would ever expect from that engine. It's not quite Doom, but with proper artwork we should be able to surpass Wolf3D even further and get a lot closer to Doom.

You're right about many things here, there are defined limitations , but yes if we had the source code we could tweak the engine out .. in that case the sky's the limit, a motivated programmer could create his own GCS, I've watched enough YouTube videos where people create their own first person game engines with very realistic effects, but then again there using equipment that could handle the modern load, and when the dark GCS was released the hardware was carrying a much different load and it's time GCS was a complete stellar tool. One thing you are a little off on, we could make something similar to Wolf 3D, Doss GCS is far more capable than wolf 3D, the only compromises that number of unique enemy per level. But then when we come to comparing it to Doom yes it has a unique engine oh, I really like the way that they can do textured platforms of all sorts of shapes, but on the other hand tell me when you can walk Under and Over a bridge in doom. The Doss GCS has many capabilities that's a d**n engine is lacking just as the Doom engine has many things Doss GCS is lacking.

One more solid point, to my witness from one level to the next any interaction you have with a Doss GCS game is stored in the game memory, I think Universal register is the correct term. Weatherby ammunition you picked up on the ground or an item that you set down somewhere an enemy that was killed or one that was left alive, and animation that begun but did not end it sequence Etc. There are a few tests we could do on this and I swear there has been one instance that wigged me out like something disappeared... but I have found by using the universal registers to trigger events in the game, if I'm on level one and I trigger a universal register that interacts with an animation on level 2 the message AK register hits the target. The same if I Cosmic event on level one with a universal register and I played the entire game go through each level few times back and forth and sideways when I come back to level 1 that event occurred.

For example I make a pit with hot lava if the player steps on it he dies, but using an animation or another platform I trigger Universal register that voids a section of that hot lava then the player can walk across it without dying, I can go throughout the game triggering all sorts of other registers as long as none of them reset that lava to its original value I will always have a bridge across it.

For this reason in certain applications if I trigger a register I make sure before the player leaves that area or the level , that I reset the value to the initial status quo. It's a very easy trick this is how we make bridges that we pass under and walk over, and if you're motivated and have enough free time because it takes time you can make spiral staircases using the same technique, the important thing is keeping track of the numbers write them down make note of them , because you will want to be on top of that once it's built its a little bit of a mess to untangle if something goes wrong. For example you can build a room on top of a room but if something goes wrong you only have two floors to separate by selecting and moving things apart to find what platform or object was in conflict, but if you do 3 4 5 floors... Dot your I's and cross your t's, and make notes of what you did so that you remember, as well know what year zero number is. This can protect you from triggering it at a different point in the game because you forgot what set of numbers you're using, and when you return to your four story house you fall through three stories...

Things that I really want to understand the source code, when the windows version came out enemies could not shoot projectiles, but in one of the update packages the ability was included, I don't want to be running version 3.8 to have projectile firing enemies I wish I could figure out how to make it work because the engine is clearly capable of it has the player shoots Rockets, hopefully that makes sense. Another thing about later development that should be capable in DOS GCS with a little tweak pstr text user input, if you responded with keystroke to a message it could trigger animations to do different things as well as set Universal registers, pstr did not change by much as well the engine always received Universal registers from a variety of variables. So these two things wood be very easy small tweaks to the Doss engine. On the other hand light and shadows that's some serious math bro, even with the source code we could steal somebody else's math quicker than I could count on my fingers

[Saturdaynight]

Great info on the universal registers!