The map images within the project are ugly as it stands right now, these maps deserves better.

Remove all assets that is not being used within the project; this will downsize the project exponentially - theoretically.

Since TGRDM3 might have its own Help graphic, it might be useful to encourage easy access to the help section. This might also require updating the credits, however.

Using Perkristian's smooth animations, change the chaingun to use smooth animations.

Source link

This was previously in the project a few years ago, but I don't remember why it was removed.

Since TGRDM3 uses its own set of weapons and number assignments, we might have to update the Help graphics to fit with this project.

Check and find a balance of the ammunition provided when picking up a weapon and ammo.

I have not done much research on this specific lump yet, but I presume this will allow the possibility to have a small - lightweight music jukebox that rotates the music on each cycle.

MUSINFO Script Lump

If possible, include eight sided sprites for ammo and health. Some PWAD's have something adjacent to this already, like KDiZD.

When the player uses a Jumping Pad, the jumping pad should give out a sound indicating that the player just used the pad.

Include ambience that fits with the levels

Self-Note: OGG or DMX, Opus isn't supported in ZDoom yet....

Apply optimizations to point lights and visuals to all maps.

Some of the reports provided by Kappes Buur relates to THING's being stuck and height variation issues. As VOXELs have a much different behavior than the ordinary SPRITEs, they must be checked thoroughly.

The SkullTag special lump script file 'Campaign' needs to be updated to append the latest changes with ammo and weapon spawning.

References:

• Wiki Documentation
• Ammo Issue

This should be looked at - as this carries the OOBE philosophy.

Recalling from the previous ideas back in the year 2007, I really wanted TGRDM3 to branch off to other game modes, and one of them was Perfect Dark's King of the Hill. One of the best ways to get King of the Hill supported in TGRDM3, is to look at the well known game mode, Domination which was featured in the SkullTag Domination project back in 2006 (It was fun back then too!)

Here is some useful links for when TGRDM3 is ready to implement this feature:

• ZDoom's GameType()
• Zandronum's GameType()
• Zandronum's Game Modes
• Zandronum's ZMAPINFO GameMode
• Zandronum's Sector Info
• ZDoom's CVarINFO
• ZDoom's SetCVar
• Making Domination Maps
• SkullTag Domination Project
• ZDaemon's King of the Hill

Just a reminder to myself if I forget.
Add clause that states that the maps and resources are free for use and modify for other projects IIF: Free, project is completely Open Source, no financial gain from project, and proper credits to respected authors of the resources and maps.

In all the maps that use jump pads that rely on thrusting the player to a specific spot, the pads must have 'Thing_Stop' action in-order to stop the player's current momentum. With this, all the pad's ThrustThing action must be re-examined in all of the stock maps.

Include Perkristian's high quality sounds. This will be very useful for the weapons used in the project and a few other sounds.

Source Link

Most of the maps within the project contains an overly abundance of dynamic lighting, but for users that have the actors disabled - the maps will be left darker than originally intended.

Proposed idea of resolving this is to increase the lighting to a level of '192' or whatever feels 'bright' enough for the map as the base lighting. For example, Abandoned Misery uses a base light of 168, when Dynamic Lights are disabled set the value to 192 or brighter if necessary.

Using the current scheme of [Killed] -->> [Weapon] -->> [Killed by], some weapons do not follow this scheme such as the Super Shotgun, Railgun, and Grenade Launcher. In addition, this should probably follow with the standards from Duel32 - to stay compatible with regex\streamline search applications.

With supporting the Campaign functionality, this will help give a 'Out of the Box Experience' to offline users using the Zandronum engine.

Possibly, lets try to shift over to Voxels instead of SPRITES. With using Voxels, this will give items depth and a 'feel' to it on all sides. Additionally, this will provide support for both OpenGL (GZDoom) and the Software renderer (ZDoom). Even though, right now, ZDoom does not support some of the OpenGL features, I still would like to leave a door open for the possibilities in the far future.

Not all of the THINGS should be converted to Voxels, as there's still some nicer effects with the fire sticks, for example.

Topic to watch: http://forum.zdoom.org/viewtopic.php?p=900673#p900673

The 3D acting teleporter doesn't exactly like a teleporter; it activates when the player 'lands' on the sector but never when the player is above the trigger.

The Grenade Launcher's grenades does not play the bounce sound at all.

The compiler presently used, is merely just held together with duct-tape -- it has been around since the Subversion days of 2013. In order to expand further with newer customizations that ZDoom offers, we're going to need a better compiler that offers a cleaner solution and handling operations.

Seems there exists a texture alignment issue with the teleporter in MAP01. This happens with GZDoom version 3.5.1, I have yet to test other builds.

Screenshot of the issue and where it is located:

Besides on using the older scheme of the maps running sequentially, why not instead focus on the maps being centered to a Hub base map? Doing this will allow the end-users to select what maps they want to play and not be forced to use a sequential order.

Marginal cost is severally minimal and will allow the project to see a release at a expeditious rate; removes the additional requirements of filling in the gabs with more maps.

Possibly create smaller maps that are specifically for four or eight players, clustered.

As of GZDoom 2.1 version, all of Texture Cameras used in the map will not work - generally. However, they worked perfectly fine in GZDoom 2.0.5. Engine bug or WAD bug?

Allow support for libraries via Compiler_Map or any other revisions of a better project compiler.

• ZDoom Libraries
• ZDoom Directives

Warn the user if they're using the software renderer. This will alert the user that they must have OpenGL enabled or better.

Really now; this project deserves a wiki! 😃

I am not exactly sure how to tackle this, but this video seems to highlight some remarks.

If incase the player is new or forgot to adjust the game mode, display a small message that they are not in the correct game mode. The message shouldn't really be 'In Your Face', but on the side as a kind-warning.

Despite that this is an issue with GZDoom not defining them, it would be nice if the missing items (such as Megasphere) had GL lighting. Such items that lack the lighting feels - empty and unsettling...

Do note that some maps, like AMisery, adds Point Lights to the Evil Eye. Some maps (if not all) will need to be altered to remove the point light THING.

Weapons that are not set with the DMFlag 'Always Stay after Pickup' but the DMFlag 'Item Respawn' is true, the weapons might need to have half of the time needed to respawn.

Using DECORATE property: Inventory.RespawnTics

Add support of proximity door triggers in maps that utilizes doors as part of main gameplay.
Adding a simple linedef trigger to execute script that assigns to open the door (despite that it could already be opened), could potentially break the door mechanism completely.

If and only If ammunition adjusts automatically purely by skill level, this should change to normalize all of the skill levels to one setting. Deathmatch with a skill level is simply not needed and there shouldn't be any differences amongst skill levels.