OwlchemistVile Posted July 29, 2022 Share Posted July 29, 2022 There's been a few topics, one recent, that proposed this idea alongside many comments in the Discord. I want to address the Logistical nightmare, problems, and hurdles associated with this notion. First Off: Increased Licensing and Regulatory Issues. Not only would a stupid licensing a product from an IP holder need to gain additional licensing to publish new works [that would need to bear up to the scrutiny of the licenser], by endeavoring to make a new product; you would open yourself to the potential of needing to submit for increased business permits, operation permits, and regulatory inspections for things like ESRB and the like. Apart from governmental regulation and oversight, you'd have the IP Holders scrutiny that your new product doesn't violate the their requirements [typically that you're not besmirching the image of their product or name, damaging it in any way they deem] to contend with and adhere to. Ground Work: Before you can even start doing what most people might conclude, that being making the new game engine; you actually have to start even more conceptually. You need to understand just about everything that you want that engine to do for your game. What type of physics will it have. What level of detail. How do you want to handle loading of data. Where is data stored and loaded from. Encoding. What scripting languages do you want to use. and many, many more factors. Once you've nailed down the mechanical bases you move onto- The Foundation: So you know all the functions and features handled by or through the engine. Pre-built, or Custom. I'm going to leave this section SIGNIFICANTLY stripped down, because there's a lot of debate between which is better and why, for who and so on. But know, an entire thesis could be writ on this one section alone. Narrative: Key to designing any immersive world, key to the suspension of disbelief and feeling connected to the game, is the Narrative. What does this world look like. Who lives here. How do people travel. How do they engage with each other. What type of technology to they have access to. What are their societies like. What's the ecology of the biomes. What types of flora and fauna exist. What types of trouble or conflict do the peoples face. All of these things and many more are deeply important to giving legitimacy and guidance to how game mechanics and interactions get chosen and designed. You need, an absolute must, to have a suitably strong understanding of the world you're attempting to build. There is NO exception for an RPG genre to not do this step. After months, potentially year or years+ you're ready to start actually creating product. Engine: Based off your chosen designs and choices, you now labor away at creation thousands, or tens of thousands of lines of code to build the engine. The engine being the brains of the entire operations and calculations. It's the foreman of the entire site. Network and Database: Now that you have an engine, you need something to store your data in. Local storage for some things, network storage for others. Authentication via a network authorized machine/server. Verification of computations or lost data. Settings saved on the network incase of hardware failure and more. Render Pipeline: This is required to render your graphics. If you have any images on the screen and your game isn't running in a command prompt, you'll need a renderer. You have many many considerations. Legacy materials, PBR? Ambient Occlusion? Depth of Field. Raytracing? Emissive lights. Refraction? Subsurface scattering! The list is exhaustive to consider it's breadth and scope. But you can't skip this. Style, Assets, World: You need to establish a style, concepts for the assets, and draft your world. NOW, we're getting into where ROSE Next-gen starts to take shape. ROSE has a style you can already pull from. Concepts exist for designs, and how the worlds scale and look are established in a rudimentary way. The issue is you need to redo it all from scratch. Higher resolution models, higher resolution and fidelity textures. More dense foliage and ground clutter. More populated areas with bustling cities and streets. Redesigned UI [User Interface] All requiring new assets. This, is probably the most expensive and time consuming part. Getting ALL the art you need. Story & Narrative: How this handled is unique to each game. But a prime narrative that propels players through the world with purpose is key. Even if some players elect to not partake, it is vital for those who expressly play games for the immersive experience and story. Systems: You have your world, your engine, your assets and your renderer. Now you need to code and implement your mechanics, physics, and UX [User Experience]. These go all the way down to how it feels to get a piece of gear, up to how a character behaves when force physics are applied. Additionally, how does gearing work. Upgrades. Do you have a currency and if so how does it work/what role does it play/ what can you get with it. Are there other systems that need to be implemented like durability, repairs, socketing, enchanting, honing, refining, mastering, crafting, so on. Those all need to be designed and implemented. Inspection: Product will have had oversight at every step of the project: however is product is a licensed product the licenser any any investors will want projections, demonstrations, and significant amounts of confirming data to continue the project. [IF approved] Closed Alpha Test[s]: Internal testing of every major function, aspect, and interaction. Typically carried out by the development team themselves. Can take many passes / phases. The goal is to assess that the intended playstyles, features and general intended design are intact and present. Bug Fixing: Required intermittently between internal alpha test sessions. Alpha[s]: Selected play testers from outside the Development team scrutinize the initial product. Bug Fixing: Return to bug fixing steps to address issues and problems found by the player testers and their reports. Multiple passes may be required for this step and the step before. Beta: Refining and more generalized open engagement to produce a greater sample size and more eyes to reduce escape rate of issues and defects. Continued Bug Fixing: Self explanatory at this point, but the step itself exists and therefore isn't omitted. Open Beta: Typically the last step of the testing cycle before launch. Typically concludes of testing sessions such as Stability test, integrity tests, stress testing servers and so forth. Also good time to collect engagement data and satisfaction reports. Release: The product releases. Post Release: Having been started back in the Story and Narrative section of this, continued development must continue to adhere to the steps of Story and Narrative through to internal testing and bug fixing for future content releases, patches and expansions. And there you have it. This was not an exhaustive or nuanced take on every single aspect, but it does paint a clear enough picture that "Just make ROSE 2 obviously" isn't in anyway as easy and speaking it into existence. It is a truly massive undertaking, even with a previous IP and product to pull from, the sheer volume of work itself is truly extraordinary, particularly for a smaller or independent design firm to take on. Hopefully this sheds some light on why it just aint so simple. Cheers. [I am not proof reading this] 5 1 Link to comment Share on other sites More sharing options...
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now