5 Common Developer Mistakes.
While being a developer seems like it’s as simple as ensuring you follow education options and practice, you can still often find some very common mistakes that happen early on in the game development world.
I sat down with Game Dev HQ’s very own Jonathan Weinberger and got his insight on some common mistakes he’s seen happen early on in career paths, so we could share them with you and try to help make your own journey into game development a little bit smoother. If you know any other mistakes you see happen all the time, shoot me a message at [email protected]. Hope you enjoy the read, and we look forward to your feedback
1. The Game Design Document.
This may be one of the first things you should ever do when deciding to pursue a project to completion. A Game Design Document, or GDD is crucial to organization of your project, time, and efforts.
Some of the most common structural components of a GDD according to wikipedia are:
- Level/environment design
- Sound and Music
- User Interface, Game Controls
While these are not the absolute musts, the core presentation of a GDD should supply you, your team, and often time the companies you are working with to look into your project. If there isnt a clear path laid out for you through this document, you’re already begging for a hard time and a whole lot of backpedaling to revise and change ideas that never should have made the cut!
Really take the time to think about your game from start to finish, and put it down on paper. This will help you really chew up what it is you’re trying to bite off which brings us directly to our next common complication.
2. Knowing the “Scope” of a project.
When starting out it’s really easy to get a head full of ideas and start branching yourself out as much as possible. We all end up like the tree of knowledge trying to absorb with our roots every possible piece of code we can to start making awesome projects. The problem this leads too however, is setting yourself up to make ambitious projects that may never see the light of day.
I know what you’re thinking. “Ryan, there are solo developers who make crazy ambitious stuff all the time. Why shouldn’t we?” Well, you SHOULD. If you are confident you have what it takes to solo an RPG then by all means go for it, but consider a few key factors before determining what it is you are going to build.
- Time. How much time do you actually have available to you? If you work full time, part time, or out of work, can be massive differences in determining what type of project you want to start. I wouldn't recommend starting an RPG when you have a full time job and family to maintain. If they support you however and you can find the time, then go for it!
- Practice, Practice, Practice. Before jumping into larger projects, how many smaller project shave you built in the past? If the portfolio is looking empty it may be considerate to yourself to make some less ambitious projects to get the feel for things first. Try taking the components you want in your big project, and breaking them down into multiple smaller projects. This way you’ve made five games that already provide the features you are trying to push into one larger game.
- What are your goals? If you plan to just take development to a hobbyist level and do it casually, there really isn't a reason to do anything other than what you’d like to try. If you’re trying to land a job however, it’s important to build up that portfolio. I would change your direction to smaller projects that demonstrate your skill, instead of large accumulative projects that take you years to make. This will build your portfolio faster, getting your foot in the door sooner - than later.
Of course, sometimes none of these things are really for sure. Everyone is different so take it with a grain of salt. If this speaks to you however, you may want to put that salt on your next project to preserve it longer while you figure things out, haha!
3. Making use of proper “ //comment /*etiquette.*/”
When I first started out I literally made comments to absolutely everything that I did. I was terrified I wouldn't absorb what I was learning. On the other hand there are some people who never even add a single comment outside of the default ones made by Unity that tell you what “void start” means. Both of those choices are pretty terrible, and now that I’ve had more experience under the belt I can assure you that skipping comments, or putting too many comments is foul play for your projects future.
When making comments in your projects starting out it's cool to go crazy until you get the point and absorb it all, but if you’re developing a project you plan to release its important to be comfortable enough that you don’t need so many comments.
When asking Jon about the right amount of comments, he said “When making comments to your projects, you should be able to read the comment and immediately understand what that section of code is for.” Additionally your code should also be readable in that fashion. If you cant understand what the code is for, it needs a comment.
In the example below, you can read through the code and figure it out or read the comment and know how the code is applied with a quick browse of the eyes. This is a good example of simple commenting.
The only confusion here, is “anything” refers to any new sources of weapons added in the future which may be confusing as there is only two options. It's clear though new weapons will be added that may hit the target in the future by stating this in advance. There are tons of ways to make use of commenting. Feel free to reach out to the community on our forums or discord and ask how you can alter your commenting to ensure you’re not making things harder on yourself and your team.
4. The Power of 2.
This is an interesting topic that goes pretty in depth so we’re going to only cover the discussion lightly. The power of 2 refers to developers in the art pipeline.
By ensuring texture dimensions are power of 2 the graphics cards of games can take advantage of the compression and optimize the game. Simply put, the math function of power of 2 allows easier processing.
Unity actually forces this to happen by default. A lot of that conversation on how Unity will create this for you by default can be found here: ( https://answers.unity.com/ques…ture-is-a-power-of-2.html ), however that doesn't mean rely on it.
It’s good to ensure your artists are aware of the differences in generating their textures to ensure there is no compression artifacts messing things up. As stated in the article listed above, you would only really use non-power of two textures in GUI fields. Everything else creates performance issues that can delay your project even further. Make sure your artists are communicating with you things like that to ensure completion goes as smooth as possible.
While it’s out of my field, I found this cool tutorial on ensuring the use of power of 2 textures that you can apply to your workflow or supply to your team ( https://www.katsbits.com/tutor…size-and-power-of-two.php ) and it states:
“The "Power of Two" rule is a fundamental necessity due to the way game engines work. There's actually a long history associated with game and content development that has to do with the way computers manage and process data in limited 'chunks', rather than all at once, for purposes of efficiency.
These chunks are important in regards to the "Power of Two" rule because they establish a set of hard coded, physical restrictions on media that must be conformed to, else a given games rendering engine will waste resources 'fixing' the assets so they do. In essence "Power of Two" is a form of data 'optimisation', a necessity so images are as efficient and 'lite' as possible, whilst simultaneously providing an appropriate visual experience.” - katsbits.com.
If you want to get hands on in this, you can find our course on CInema 4D to find the industry expectation on 3D asset production thanks to instructor Al Heck here: ( https://www.udemy.com/the-ulti…acter-art-using-unity-c4d ). Every project piece uses the power of 2 to ensure optimal settings for your games in this course. Be sure to pass this along to your 3D artists.
5. Communication is key.
As much fun as I enjoy talking through cans, it may not be the best method of communication in today's world. It’s extremely important to ensure a clear concise form of communication is available between you and your team, and that the path for the project is clearly laid out. The GDD really helps divide the tasks up, but additionally there are things out there such as Trello that you can use to create a proper “work board” to keep in the loop with your team on what’s going on.
You can also imagine being in a situation where you are a developer and just finished a part of your project, to find out that another developer picked up that task on the side of his current expectation. This can lead to wasted work and time, so be sure that your team fully understands what they should and should not be doing to prevent any kind of terrible overlap in tasks. Work smarter, not harder!
I would also recommend meeting once a week to ensure that motivation stays active .One thing that tends to happen to start up projects is communication fades out and morale drops slowly through the entire team. It is up to you as a team, and especially up to your project manager to keep everyone in the loop and continue communication where possible to prevent people from dropping off the face of the earth. Google hangouts is an awesome method, and so is even just facebook messenger to ping your team for a meeting.
Of course there are many other things to go into detail about, however this article has gone on long enough! We appreciate you taking the time to read, and we hope you found some of this information insightful. In the future we will go over things like the structure of coding, camel casing, and namespace mistakes that are very common.
Let us know in the comments, what issues you see are common when working with other developers. We’re happy to add them to the next list! Thanks again and we look forward to seeing what you create next.
The GameDevHQ Team.