I’m currently working on a game document with a small group of friends (there are 3 of us) and have some questions which are listed below.
What are some best practices when working with a team when it comes to developing a game?
How do you come up technical content budgets for things such as polycount, draw calls, materials / textures, lighting, etc?
Are there any tips or best practices I should be aware of before getting to far into the beginning stages of development?
Are there any resources available that shows market share for PC Gamer hardware (cpu / gpu / operating systems / etc), this way we have an idea of what the minimum requirements would be to run the game?
Well you don’t state if your team is local to one another or is Internet based each having their own unique requirements to keep every one happy and contributing when the shinny starts to wear thin or what the objective of the project is once you remove the more idealistic of the warm and fuzzy that is called the fun part of making a video game.
If you and your friends are working on making a game because your friends then best practices of team management are different than practices, best or other wise, that are necessary to produce a product with the intention of selling your efforts as a consumer product which your customers are willing to pay you for your efforts in the form of hard earned cash
Personal opinion wise though based on the questions you ask and as part of a rather large Internet based development team, for the love of the game project, here is what I think is of use.
Be flexible with your game design decisions and avoided saying no when ever possible. Everyone has what they think is a good idea but don’t have the skills to put their ideas into a properly formatted pitch in to words that even comes close to conveying the full scope of the idea that as an individual you might have had weeks or months to mull over. Idea in words generally don’t have the same impact until implemented in a way that it can be examine under practical game real time game conditions and if said person has the ability and skill to implement the idea say “Yes” to that so all can disuse with assets in hand and not say no because of an opinion that someone does not like the idea.
Rule of thumb is if it’s not in the engine then it’s just talk.
Experience has taught me that if you give someone a specification, aka work order, they will only produce content art that meets the requirements and never exceed expectations as to individual talent and abilities to to produce more than what is needed.
In large part UE4 does present the ability to do “better” because as an engine limits and limitations are not placed as to requirements as to best practice as to what the engine is hard coded to accept as to artificial limits like polycount and texture resolutions. 15 years ago limits were placed not because of performance issues but rather limited to how much content could fit on a single CD where spanning across a second would be a cost that comes out of the profit margin.
As the content and asset manager on our team when asked this question my response is to use what they need to make their efforts look as best as it can be as it’s an easier task to take to much and make it less than it is to try and take not enough and make it do more. Best practice in this case is always be working with the highest possible fidelity of working assets and solve what is needed as to fit to finish requirements with in the editing, Unreal 4, environment.
Best practice is a myth that can only be applied within context of the issue in hand. As to the context as to beginning just start by starting and make up what you need to do based on fact and not on assumptions of problems that you may hear stories about that may or may not even happen.
Steam tracks and updates a on going hardware and software survey
Internet based projects are a pain and contrary to belief is a lousy way to develop anything as far as communication goes so above all else be patient and keep a sense of humor as it usually takes ten times longer to resolve a simple problem that could be solved with a single look.
