Probably one of the most guarded and heralded aspects of the game, this has always been sensitive to changes. More modifiers will probably be added as the situation evolves and we find more ways to give deeper mechanics to each weapon, after which we will have to take a look at the balance again before releasing. In v2.0 this has been extended further to actually give your choices more depth, these include things like changing weight, speed, and health. Rather than creating rigid classes, we wanted to offer everything so you could make as many different combinations as you want.
In choosing your load-out, this was basically among the first of the ways we gave players to customise their character and combat styles. The philosophy of how weapons were viewed shifted at this point from that of skewed weapon balancing to what we currently have in v1.6 with fairly even pros and cons. This was generally so popular for it’s “get-in-and-play” style that it eventually became the default play style for Red Eclipse, with the original gameplay replacing the mutator slot with what we now call “Classic” (yep, it really resembles the classic gameplay). “In the beginning” what we now consider “load-outs” used to be just a game mutator called “Arena”.
#Cube 2 sauerbraten commands series#
Many of these are highly experimental or extensions of previous ideas, and others are attempts to fix flaws we’d become reliant on, but the main idea of the new series will be that it is more considered a “reboot” or “sequel” of the game rather than a direct continuation of what we’re currently used to. Since starting the v2.0 project, there have been some deviations from the standard design present in the v1.x series, some minor and some major. Tesseract instead chooses to use a fully dynamic lighting engine to resolve the mismatch between lighting of dynamic and static entities while making better trade-offs between appearance and storage requirements. Finally, storage of these lightmaps became a concern, so low-precision lightmaps were usually chosen, at the cost of appearance to reduce storage requirements. Lightmap generation took significant amounts of time, making light placement a painful guess-and-check process for mappers, creating a mismatch between the ease of instantly creating the level geometry and the not-so-instant-process of lighting it. Dynamic entities in the world could not fully participate in lighting and so never looked quite “right” due to mismatches between dynamic and static lighting techniques.
Sauerbraten was reliant on precomputed lightmapping techniques to handle lighting of the world. You can read more about the renderer here, but this outlines the differences in design choice: We are sorry to leave behind our root vegetable loving friends, but we are trying to make real progress by turning Red Eclipse into a beautiful looking game that people want to play.
We know we’ve prided ourselves for a long time concerning the fact Red Eclipse can “run on a potato(tm)”, but we’re going to have to say goodbye to the potatoes in order to make progress. This is great news for us, as we can take more advantage of newer hardware and do things we simply couldn’t before, due to the limitations of the old renderer. The new rendering features include fully dynamic omnidirectional shadows, global illumination, HDR lighting, deferred shading, morphological/temporal/multisample anti-aliasing, and much more. Tesseract provides a unique open-source engine derived from Cube 2: Sauerbraten technology but with upgraded modern rendering techniques. So, what does this mean? A New Rendering Engine
#Cube 2 sauerbraten commands full#
The time since the release of v1.6 has seen some major developments within the project, starting at the New UI and culminating in a full port of the Tesseract engine to Red Eclipse that is now being dubbed “version 2.0”, which we will hopefully be releasing in the near future.
0 kommentar(er)
