Gravity Ace

Optimizing code and learning pixel art


Hey everybody and welcome back to another Gravity Ace Devlog!

Before we get into it I want to thank everyone who’s been watching this video series. It started out as an experiment just to see if anyone was even interested in a boring old devlog from yet another indie game developer. Well, to my surprise and delight, you exist! Not only that, the comments you folks have been leaving are lovely and I really do appreciate every single one of you. I started these in December. As I write this it is January 24th 2020 and I have 333 YouTube subscribers and growing FAST! It’s been a huge success and I intend to keep going as long as I can.

You may have noticed the new background music. It’s a new track I wrote for GRAVITY ACE. Let me know what you think.

I’ve been getting some interesting questions so I thought I’d use this devlog to answer a few of them here. Digital Ki asks if using _integrate_forces() had a high performance cost. You can substitute anything you like for that… maybe you’re wondering about _process() or _physics_process() or some other code in your game or maybe you have doubts about GDScript. The short answer is NO. GDScript is fantastic and the engine does most of the work anyway and it’s written in highly optimized C++ already.

If you’re concerned about performance or you notice that you have an actual performance issue, take a look at Godot’s built-in profiler. It’ll show you if you have a problem. So, let’s look at the game running for a bit. First look at the Monitors tab. We’ll turn on a few monitors and start the game. And as you can see the frames per second is very high. Process is taking almost zero time. Physics process is taking even less. It’s virtually nothing. Almost nothing is happening here. The game performance is fine. This is on a 2011 Intel i5-2500k and a GTX 1060 – that’s OLD and MIDRANGE AT BEST hardware.

So now let’s look at the profile tab. I’ll switch over to the profile tab. Start the profiler. We’ll let the game run for a little bit. The red line here is our baseline. That’s the physics frame time which is locked at 60 FPS. That’s the slowest interval in the game. You can see the real frame time is ridiculously small. So you can see that I’m using a tiny amount of my 60 FPS budget. All of the physics 2D is using a tiny percentage. All of the callbacks are tiny. All of my own script functions are tiny.

When you have this much headroom there’s basically no need to waste time optimizing. What would be the point? So here’s my process for writing code: make it work, make it right, make it fast. In that order. Make it work means just get it working. Be sloppy. Be wild. Copy and paste. It doesn’t matter. Just get it working. Then, once it’s working, make it right: clean it up, organize the code, restructure it so it’s easy to understand and easy to maintain. Finally, and only if you need to, optimize it. And I often just skip that step because I don’t need to. Now, your game is not my game. It could be that your game requires highly optimized algorithms. If that’s the case, the profiler is your best friend.

Martin asked how I learned to create such good pixel art? Thanks for the compliment Martin! This just comes down to hard work and practice. I’m sorry for the bad news! I picked up drawing as a hobby in 2010 and I’ve been teaching myself since then. I’m not very rigorous about it. I don’t spend a huge amount of time on it. But over ten years I guess it adds up and I can draw OK now. How quickly you improve will depend on how well you practice and how often you practice. I’ve been doing pixel art for 2 years almost daily as I’ve been developing this game. I don’t have any magic advice about how to get better. It’s just… you’ve got to practice.

You also have to sort of let go of the idea that you can draw something nice on the first try. This took me a LONG time to understand. Drawing, for me, Is always a struggle. My first drawing is going to be garbage. And I don’t mean just that one drawing… I mean every first drawing I do forever is gonna be garbage. My first sketch always sucks. Just like my first draft when I’m writing something. But I keep working on it. I keep refining it. I erase it and draw it again and again. And maybe by the fifth time I find something that I like. It’s just pixels. So you can’t be afraid to erase it and start over. I promise you it’ll be better the next time you draw it. I can’t tell you how many times I’ve redrawn EVERYTHING in this game. And I KNOW that if I just picked something at random and redrew it I’d like that next version better.

That’s all I have time for today. But PLEASE ASK if you have any questions or you want me to explain how I do something! I’m HAPPY to answer and help you out. Plus it helps me create content for new videos… so it’s a win-win.

Please like and subscribe if you enjoyed this or one of my other videos. Also, please help spread the word, tell a friend, post a link on your Twitter or Facebook about GRAVITY ACE. Every little bit helps and I truly and sincerely appreciate it.

Thanks for watching and see you next time!

Published January 26, 2020

More devlogs...

Game jams for beginners

3 methods for screen shake in Godot Engine

Creating a custom Fixed Joint in Godot Engine