BielBdeLuna
commented
7 years ago [OTE 2017 vision]
Open Tech Engine is creative cooperation applied to game development. Open Tech Engine Achieves cooperation through creative means. Open Tech Engine strive for meaningful functionality as the basis for different applications.
A stepped process:
1 - building a meaningful community. The best way to hold a community together is trough having a modifiable platform, and having a genuine interaction with the community
1.1 - build a modifiable platform to have a modifiable platform means to have a set of assets that people can use as basis for their mods/games/applications the best way to have a first modifiable platform is to create those assets in an organized way
1.1.1 - building the first assets in an organized way the easiest way to create those assets would be to create meaningful assets, and identify what assets to build would be far easier as a part of a coherent game, since the engine is the byproduct of an existing game, the easier game to create would be something similar to that existing game
1.1.1.1 - building a first game since we don’t have a big team, the best bet would be to create a “vertical slash” a couple of levels, or a single level, two to three weapons, and two to three enemies, with that “vertical slash” in place levels could already be created and mods could already be done
1.1.1.1.1 - building a vertical slash we could copy existing mods or games, beside the game the engine is a byproduct of, as our “vertical slash” here is a list of proposals of single or couple of levels long mods that could be interesting as basis for our initial “vertical slash”:
doom - The City of The Damned : Apocalypse - video - link quake - Plumbers Don't Wear Ties (But They Do Carry Shotguns) - link quake - The Altar of Storms - video - link quake 3 - The edge of forever - video - link quake - The Marcher fortress - video - link quake - Firetop Mountain - video quake - The Horde of Zendar - video quake - Forgotten Sepulchre - video - all last three within this mod
we could have something build like one of them updated with the current improvements the engine has, that would serve to gather the limits of the engine we have on our hands, and a trial to resolve bugs from the new improvements, it could be something meaningful enough to stand on it’s ground but not overly complex to build.
1.1.2 - building the community pro-actively since now we have a small asset pool, we could try to build a community out of mapping, that would serve in more than one way, it would build community out of the creations of the community. And would serve to create new assets and empower tool creation. Sort of: http://www.thedarkmod.com/missions/
1.1.2.1 - manage the community with creativity we could have a lively community with mapjams, or even with yearly competitions, sort of: https://www.quaddicted.com/
1.1.2.2 – guest-mapping proposals for known mappers to guest as mappers for our engine as propaganda of the community, let those that inspired us also inspire others on our behalf.
1.1.2.3 – perpetual campaign for the engine and it’s possibilities every time we get a new feature create screen shots and didactic videos that attract new talent to the community and pro-actively distribute the videos on the appropriate social networks, sort of: http://www.celephais.net/board/news.php
1.1.3 - enhancing the community possibilities we could also build community from a asset point of view, with a repository of assets so everyone can supply their created assets so all in the community benefit from the community efforts, like this: http://www.realm667.com/index.php/en/
1.1.4 - enhancing the reach of the engine building other «vertical slashes» for games that differ from the original game, the engine is byproduct of, would be wiser at this stage so the possible applications of the engine are enhanced
2 - enhancing the technology of the engine building better technology should be an end goal that would be beneficial to all anytime
2.1 – recognizing the outsider work works outside the community are also valuable, let’s people into the community but doesn’t require it, so a proactive attitude towards outsider work should be the normal attitude
In order to further enrich the stepped process with technical ideas to make the engine a more stable base for development, easier to maintain and extend and more accesible to content creators.
The codebase is quiet big with alot of moving parts, but some of these parts are outdated or legacy stuff which makes it unnecessarily hard for our small team to maintain it, examples for this are cg shaders and their translation into glsl/hlsl, flashbased gui system, 3rd party libs source code which is just "drop in" in the codebase, complex handling of these 3rd party libs but also git submodules.
My idea would it be to firstly make the engine more "equal"on multiple platforms, one step in that direction would be to finally deprecate cg shaders in our engine and replace them with a platform-independent alternative, imho the only option we have here is glsl as shader language, this means the logic to parse and handle cg shaders should be removed by a proper glsl shader parser.
Similair the flashbased menu should be removed by an alternative, we have already cegui integration but i propose that we instead try to reenable the old doom 3 gui system as it is a battleproven and has atleast some consumers within the doom3 community like for example the darkmod aka the is knowledge available how to create guis using it.
3rd party libs is a more difficult topic, we have code just dropped in as it and we also have a certain amount of git submodules. Both have certain problems, 3rd party libraries that are just dropped in like that dont receive any updates from upstream, this includes security related fixes but also potentially useful new features which we might want to integrate. Our git submodules that we have are already a bit better in that we have a copy of the upstream source which we can update easily at any time, but they also have the problem that the library in question already needs to be available via git or that we maintain the source code ourselves in git which adds alot of maintainance burden for our small team. Because of that i suggest that we remove the dropped in versions of 3rd party libraries and git sub modules and instead refactor our cmake build configuration to be smarter and find these required libraries itself. Potential devs and packagers are then free to provide the required libraries in any suitable way.
Reducing the codebase like that while make it easier to maintain it but we also what to make our engine more attractive for content creators, one way to do that is to add more modern content formats, in terms of 3d models have have for example "only" stuff like md3, md5, lwo and probably something else and it looks similar on the audio side. We should aim to add newer formats to the engine like OpenGex, glTF 2.0 but also older but widely used formats like ogg to give content creators more ways to use their work with our engine.
But content creators don't only need more available formats but also tools to work with, this means we also need to bring back the old engine tools the original version of doom3 had. These tools are sadly not platform independent and need to be reworked. We already have a simple light editor as proof of concept thanks to Daniel's work.
Damiel and Me have been speaking lately about the nature of the project, we feel the project lacks planning and a common vision, at the moment it’s just a couple of individuals working here and there without a clear direction, we propose a way to define a clearer direction with a defined set of steps, we propose that during the next week we have free proposals posted on the ‘forum’, each on on it’s own 'issue' thread so it can have it’s own discussion separated, and the following week we vote on it, and the most voted it’s the one we could follow.
On the proposals, we consider it should have a clear vision stated in a few lines and a proposal for a stepped process to reach it, in order to differentiate the proposals from other stuff in the ‘forum’ we could have their individual 'issue' thread named starting with:
The discussion on the proposals should be useful for revising the presented proposal in order to gain more votes, hence the week of time for the proposals. Then in the beginning of the following week we freeze the proposals and vote on them.
This doesn’t mean we won’t accept things outside the voted proposal, or outsider work, ( There is always the outside loner that will call us deformed soviet bon-vivants :) , his work apportions will always be welcomed ) it just should concretize our common efforts.
So next week ( sept 18 – sept 24 ) is proposal week for the vision for OTE in 2017
list of proposals:
[OTE 2017 Vision] – Technical ideas and clean up of the engine [OTE 2017 Vision] – a communal and open approach ---> merged into the other one <---
Proposals are merged as they are now
next Week ( Sept 25 - Oct 1 ) is vote week! in order to vote let's leave a message in the proposal thread stating that we vote
vote passed