Jump to content
 Share

_Rocket_

Game Development Tips From a Game Developer

Recommended Posts

Posted  Edited by _Rocket_

So you wanna make a video game? Leave your sanity by the door and we'll get you started on your way.

 

Fail Faster

Step 1: Mess up and break shit.

 

No seriously. The process of making a game is boring when everything goes according to plan. Making huge plans and blueprints is a sure-fire way to result in a huge waste of time. You are going to make many mistakes during the development process of your game. This is especially true when you are a first time developer. You will make mistakes, errors, lapses in judgement (yes, your brain can shut down that bad sometimes it's great). It's inevitable. So? Fail Faster.

 

Purposely make mistakes. Don't avoid errors, try everything you can think of. If an idea you have isn't successful, then think up a new idea. If a solution fails, great! Just back track a little and come up with a new solution. Don't try to plan out every little detail. In fact, planning out details in general isn't smart. You want to have a rough idea going into your development project, and build on that idea as you progress.

 

Fixing Bugs is a Huge Part of the Fun

Programming is a very repetitive thing. I mean hell, if I'm not listening to music as I work I sometimes feel like my mind is going numb.

 

I am going to tell you right now. If you are new to game development, there is one rule you must know: When everything is going right, you are going to be bored out of your mind. Problem solving is what makes programming fun. It's what keeps it from becoming a tedious mind-numbing experience. So when you know EXACTLY what you are doing, you're going to lose motivation.

 

If you are ever at a point where you know exactly how to write every single line of code, try to expand on your game in a creative way. Try to improve a mechanic, or expand on an idea, or add a new twist. Give your problem solving mind something to work towards. There is always a way to improve your game. Don't lose motivation because writing the code is too boring and tedious. Try to find a way to make it challenging for you. You'll not only maintain your own motivation, but you'll be improving your game in the process.

 

Yes I know. Fixing problems in code can be frustrating sometimes. But believe it or not, it is apart of the fun. Remember, you are a problem solver. When you aren't problem solving, all you are doing is writing the same words in a document over and over again. It hurts.

 

Take Things Step-By-Step

This is the most important piece of advice I can possibly provide.

 

Every single new mechanic you add is a problem you need to solve. This remains true throughout your entire development process. And it's good to recognize this. It is also good to recognize the fact that you should only be solving 1 problem at a time. Not 3, not 2. Just a single problem. To give you an example, let's go through the steps of making a simple racing game.

 

Our first problem is making a car. How do we make a car? Well hold on! That's gonna involve a lot of different details. We should only be solving a single problem here.

 

Our first problem is how to draw a sprite on the screen. So, we make a sloppy car sprite and draw it. Yay we did it.

 

Our next problem is how to make the car move. Let's add some basic controls and bam we did it. The sprite moves when we press specific keys.

 

Now we need a wall that can stop the car in its tracks. Our problem? We need to make an object that stops the car from moving. So, we make a black block. However, we need hitboxes. So we are now being introduced to a new problem: We need hitboxes.

 

But remember! Making hitboxes has details. So making hitboxes isn't our current problem. Our current problem is actually figuring out how to add hitboxes into the map. My solution to this problem? Have car hitboxes and wall hitboxes be a rectangle in 2D space. Have a set position for them. Make the player control the hitbox instead of the car sprite, make the hitbox move. Great! Now the hitboxes are on the map.

 

Now how do we make the sprite move? The hitbox is completely invisible to the player. We need the sprite to follow the hitbox. The solution should be simple. Just set the sprites position to the hitbox's position. Do this for cars and walls.

 

Okay, how does the hitbox detect if it hit a wall? Once you finish that, how do you detect if you ran into another car? Etc.

 

The point here is: I am always focused on solving a single problem. I don't try to plan ahead while I'm busy already solving a problem. I always solve a problem, then think about what the next addition is gonna be.

 

You MUST maintain this step-by-step mindset as you develop your game. Even slightly deviating from it can result in you overwhelming yourself. Which often results in time wasted trying to fix a lot more bugs than you really need to. Focus on a single problem. Think about solutions, fix bugs and mistakes, etc. Avoid trying to think about a new problem when you haven't solved your current problem. This makes it so much easier to back track, manage your code, come up with good solutions, and maintain sanity.

 

No One Cares About Your Game Code

All anyone cares about is your game. Just make the game you want to make. Don't try to add weird mechanics because it uses "Kool code stuffz". Some programmers think they are gonna be praised for their code quality. When you're developing a game, no one cares about your code. So just write your code, fix your problems, and move on. This piece of advice may seem pointless, but it isn't for me at least. I would sometimes think about adding some weird addition to my games just because it would use some complicated programming thing. Don't. Just don't.

 

No Seriously, No One Cares

Open source code is apart of programming. Your goal as a programmer is to solve problems as efficiently as possible. If someone out there already has a solution to your problem, just use their damn code. No one cares if you wrote all your code or not. No one cares if you got stumped somewhere and decided to find some open source code that fixed your issue. Just use whatever you can if it helps. You don't have to restrict yourself to only write original code.

 

Open source using is a part of your programming practice. Using open source is as essential as finding solutions in stack overflow. Just because you used someone else's code in your game doesn't mean you're a fraud, or a bad game developer. ALL game developers have used code written by other people at some point. It is seriously a part of programming.

 

 

I might expand on this sometime in the future. I could've actually gotten into *actual* code. Maybe I'll make a video sometime idk. Hopefully this has opened your eyes to a few things. This is stuff that helped me out a ton, and I really wish I learned sooner when I first started making games. Cya bois

Edited by _Rocket_

I write programs and stuff.

 

If you need to contact me, here is my discord tag: Dustin#6688

 

I am a busy person. So responses may be delayed.

1840045955_Thicco(1).thumb.png.87c04f05633286f3b45b381b4acc4602.png

 

Share this post


Link to post
Share on other sites


I like that you have a wealth of guides, but I wish there were some examples or slices of code.  I think the way of thinking is sound and I know you're super capable; we also have a very strong and diverse audience that may interested in this topic, but I think it's a good idea to add those little snippets just in case someone is really putting their toe into the water for the first time.

 

When it's just wording it feels a little incomplete.  I feel like a little nudge further could really add a lot of value.  A first time user might not know what it means to break code and how to benefit from it as you describe.  I would showcase something where the code didn't work and what you learned from it, or maybe a case where broken code worked!  It has certainly happened to all of us (I definitely showed off instances in another thread where I did not put the correct type as exampled from my comment below)

 

 

Approaching problems step by step as you said is the perfect way to go; it's also the easy spot to suggest using functions to make slices easier to test, re-usable, and it even helps with the legibility.  For example Roy shared with me a type of checkAdmin(client) function that he was using, and it was real obvious every time it showed up in the code, or in your example above you can show where your checking if the car has ran into an object/wall.  You can also up the game and even suggest making a new class and how to call them in the object-oriented languages.

 

Since you have a lot of comments about debugging I would also add approaches to solving it.  Is it just fidgeting with code or is there some mathematics someone can use to solve these problems.  Maybe list a few very common ones you've seen like maybe people who put the ; after an if() or for() because the code can still run; same for when a number is data type is exceeding its boundaries.  How can people add sanity checks to their code (ie. a few print lines showing "Here" or an intermediate value within a loop).

 

One more thing you can do to improve this is start connecting your guides together.  How has everything you wrote about and taught others add up?

 

Just a suggestion...  I still think you're doing a great job and I just really want to amplify it.


PoorWDm.png?width=360&height=152

Share this post


Link to post
Share on other sites


3 hours ago, Joshy said:

One more thing you can do to improve this is start connecting your guides together.  How has everything you wrote about and taught others add up?

I was going to try and do this at first, but it kinda just... I guess it didn't work out that way? I have always wanted to make a tutorial series on Youtube covering these various topics. With a youtube series I would probably attempt to be a lot more organized. But in GFL I often post whatever I feel like in here. Pretty much anything that doesn't have "the basics" in the title is a random post I made. I make it and focus it more towards programmers who already have some experience, but may not know some important nuggets of information that can completely change their perspective on things. Everything I write here is stuff that amazed me the first time I learned about it. So I just share it here for the fun of it.

 

Maybe I'll try to make a more organized thing at some point. Maybe I'll make a youtube series and post it here lol. I love being a teacher after all. It depends on how things go.

 

3 hours ago, Joshy said:

I would showcase something where the code didn't work and what you learned from it, or maybe a case where broken code worked!

I might consider doing that as well. I mean, the exact moment I am able to start programming again my first project is gonna be a game. The game might just turn out to be the first game I add on steam, too. There is likely going to be new things I learn during that process. I have learned something new with every single game development project I have started. This one will be no different. I can probably keep track of my failures and successes, then share my experience with them and how I worked problems out.

 

Again, a lot of my thoughts are pretty unorganized with all this. Once I am FINALLY able to start developing again, I should have a much better plan with things. With that improved mindset and focus I should be able to make good tutorials that cover as much as it possibly can. This tutorial was something I kinda just threw together, admittingly haha.

3 hours ago, Joshy said:

Approaching problems step by step as you said is the perfect way to go; it's also the easy spot to suggest using functions to make slices easier to test, re-usable, and it even helps with the legibility.  For example Roy shared with me a type of checkAdmin(client) function that he was using, and it was real obvious every time it showed up in the code, or in your example above you can show where your checking if the car has ran into an object/wall.  You can also up the game and even suggest making a new class and how to call them in the object-oriented languages.

 

Since you have a lot of comments about debugging I would also add approaches to solving it.  Is it just fidgeting with code or is there some mathematics someone can use to solve these problems.  Maybe list a few very common ones you've seen like maybe people who put the ; after an if() or for() because the code can still run; same for when a number is data type is exceeding its boundaries.  How can people add sanity checks to their code (ie. a few print lines showing "Here" or an intermediate value within a loop).

This is most definitely something I would do in a tutorial series. Showing examples are key when you are teaching someone a new concept. And since I will be able to actually show myself coding things as I talk, it will make showing examples much easier.

 

Joshy, I know you develop with Java. If you have any experience with the JDA (Java Discord API), I made a tutorial series covering how to use that library I made for the JDA. The lobby system thing. That's an example of how I go about tutorials. Though I would have a better microphone now since I got a new one. And I might plan things out a little better for a tutorial series covering programming as a whole rather than a single library.


I write programs and stuff.

 

If you need to contact me, here is my discord tag: Dustin#6688

 

I am a busy person. So responses may be delayed.

1840045955_Thicco(1).thumb.png.87c04f05633286f3b45b381b4acc4602.png

 

Share this post


Link to post
Share on other sites


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

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...