Development Cycle: BlauNacht

Forums for TGRDM3 [Home Not Yet Defined][/note]

Moderator: TGRDM3 Team

Locked
User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Development Cycle: BlauNacht

Post by Tiger » Mon Dec 05, 2011 5:26

The main focus for this project is to satisfy the general Doom Community while taking full advantage of the OpenGL features available for a modern look and feel. With utilizing the OpenGL renderer and features within the GZDoom engine, it is now possible to make a Deathmatch project that is like no other in the history of Doom. Understanding that Doom has been around for several gaming generations, the engine during 1994 was powerful in its time yet had its limitations. Today, the community has greatly taken this game engine - and made it into something vastly more powerful and modernized while keeping its unique atmosphere and environment. With this project, it should also follow with the modernization and take as much advantage of the newer features that are available today.

This development is focused on making this project unique by utilizing OpenGL features, but yet - upholding the Deathmatch Standards by Deathz0r (published on the SkullTag Forums, but it is now considered - lost). In order to stand-out from the rest of all of the other Deathmatch game projects, this project must stay focused on the two main points: Deathmatch Standards, and OpenGL modernization. The majority of projects released today for the Deathmatch genre, they still uphold to the 2.5 dimension and a vast majority are severely linear -- these projects can be easily found in /IDGames newstuff, but they are quickly forgotten and only hold value of database history. However, if the two main points - of modernization and Deathmatch Standards - are upheld, this project will stand out from the rest and may contain a little more in value than the vast majority.

However, while keeping up with modernization and focusing on the latest improvements from the targeted engine, GZDoom 2.0-era, there will be no backward-compatibility. With focusing primarily on the newer features and latest fixes, supporting - backward compatibility will simply downgrade the projects development time and will add-in more possibilities of bugs or confusing work-arounds that can potentially break or will restrict the use of newer features in favor of backwards compatibility. As a result, backward compatibility will not be considered and such engines that are based on the GZDoom engine will merely need to update to the latest versions.


With the project carrying these goals, there is a much greater chance of the project gaining more attention and getting recognized for gaming events.

Revision: 2
Last Updated: 20.Oct.2014
Last edited by Tiger on Tue Oct 21, 2014 2:23, edited 1 time in total.
Nicholas "Tiger" Gautier

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: Development Cycle: BlauNacht

Post by Tiger » Tue Oct 21, 2014 2:18

Updated Development Cycle (or Development Era) BlauNacht at revision 2; I want to keep BlauNacht as there has been huge progress ever since I switched gears and focuses.
Nicholas "Tiger" Gautier

User avatar
Tiger
Developer
Developer
Posts: 856
Joined: Thu Feb 25, 2010 3:44
Location: United States

Re: Development Cycle: BlauNacht

Post by Tiger » Thu Oct 30, 2014 16:56

Officially retired.
Nicholas "Tiger" Gautier

Locked

Return to “TGRDM3”