FiniteStateGit
commented
2 years ago I agree, this would make a great addition to the documentation. I wanted to add a few things that might fall under the scope of a FPS template.
- Multiple game modes that can be played on a selection of maps.
- Settings for input sensitivity.
- Remappable keybinds.
- A throwable weapon (UI helpers, decals).
- A non-trivial damage system (aoe damage falls off from source, limb hits do reduced damage).
- Basic AI tactics (unit-based search-and-destroy, seek item pickup).
- Weapon system features ballistics, recoil, inaccuracy.
@decryptedchaos and I have a conversation thread going on in the #games channel. Among the takeaways from the conversation so far: this project should address the deeper design considerations of implementing a familiar problem space (an FPS game) in a new solution (O3DE). The project should detail how interoperability between systems is best achieved. This would be in contrast to documentation that only details the functions of a single system. Beyond the educational benefits of a detailed FPS Template, users would benefit from an accelerated starting point for developing the most popular genre of game.
lmbr-pip
decryptedchaos
sptramer
FPS Boilerplate Template
We need to develop and maintain a FPS template and corresponding documentation on how it works as well as ways it can be extended. Having a detailed sensible boilerplate template is important, the core concept of FPS should be demonstrated.
So many times have I tried to learn how an engine does something, the sample/template provided gives you a FP Controller and a weapon but if you change the weapon or add another weapon, suddenly aiming no longer works properly. and on and on.
While it may be some initial work to get this going, over time having something that is very well thought out, maintained and presented will go a long way into helping new devs get to a point where they understand how the engine works.
I should add, this needs to be a community effort, the more people that participate in this part of the development the better more fine tuned this process can be, with the idea of new user engagement.
I think those of us interested in working on this, need to work very closely on how this is designed, even if one person specializes in one part, we should at the very least inter-communicate on how all parts work, that way we are both familiar with the standards but are also in-line with our work respectively.
Furthermore, as I keep thinking about this idea, I believe this needs to be handled under one team/project. Here is why:
For this reason I think this should be dealt with like a common project/template, the difference being the docs should follow the template 1:1. In this way they both serve as training resources.
In one hand the practical example, in the other the technical instructions, striving for the tightest integration between the two is greatly important. "How, Why and Where" all covered by one or the other.
It has been suggested and briefly discussed that we could make this modular with Gem's / Sub-Gem's that way you could pick and choose which parts you needed.
In Conclusion, i would state that, this is just as much about developing internal standards, and best practices as it is about teaching, from a training perspective, we should internally develop the best case scenario for doing common tasks, and present them as best practices, with detailed examples and instructions on how to use and extend them.
For example:
This type of thinking and up-front leg work will go a long way to enabling and inspiring, new developers and by extension adoption of the O3DE project. If we take this, as an internal project, we build the template as a community we can solve both problems at once, setting the standard, and training the community.
I know the amount of work proposed is extensive, but it's very important, this is the single most preventive point of entry, if the training, examples and documentation are fragmented, effectively its just going to frustrate new users. Even myself having at least toyed with nearly every major engine available to the public over the last five years, The way O3DE works is a bit different. Which is to be expected from a nearly ground-up rewrite.
The vision I have is, building those standards and front and center presenting them to the users in the best most detailed, useful way, The proposed Template, should be constructed meticulously, with ample code comments, perhaps even declaring blank functions with the idea that they could be useful point to add functionality.
The documentation should pickup here, and explain, this is defined here, and it can be extended here,
here's how and so on..I do realize the scope of this proposal, however this project does have a significant backing, and as a community project, we should be able to come together to pull this off. Most engines in this area typically fracture this type of training, into documentation and practice, while one individual or set of individuals will create code examples and templates, another separate group of individuals will create documentation that tries to follow it. This is leading to a fractured ecosystem in my view, if we can combine the two into one team, we will achieve much more cohesion between the two.
I would love to spearhead/coordinate this effort, however myself alone, i do not have all of the required expertise to accomplish the vision, even two people probably don't, this has to be a defined general direction the community lays out as a whole, i believe it will take several individuals at minimum to do this properly.
UPDATE: I've forked the multiplayersample, as a possible basis for this template, to begin working on the issue, we need contributors though. otherwise, it will stall, as its more than one person can typically handle.