"Teachers teach how, while learners learn why."

​

Hello again, adventurers! In this devlog, I'm going to share the first steps in my self-learning game project, "Pixel Tennex," where I'll dive into why I chose a certain game engine, how I set up the project, and the little coding puzzle I had to solve to create the game area's background and dashed line. Without further ado, Let's jump into it!

Start your engines!

In my previous devlog, I would discuss on which engine I would use later on. After much deliberation of looking on various engines features and limitations, I'm confidently going with Godot Engine.

​

Source: GodotEngine.org

​

Why Godot?

​

Since I was a little, I always have a knack to try something never done and experiment on things to waste time. At the same time however, I also tend to put things in practice quickly since I have quite lots of ideas I want to test it out. And hey, there are no rules where you can't develop small ideas and later turn them into something big, right?

​

Game frameworks like LÖVE, OGRE, MonoGame, XNA/FNA, SDL, and many others allow me to keep experimenting stuff and build the game system as needed. However, I fear that building stuff with one of them can take more time than it should. Aside of having a little time to spend daily due to work related reasons, getting comfortable with RPGMaker back then got me used with GUI rather than text-oriented DE. (Also I'm suck at typing)

​

Game engines however, like Unity or Unreal allows me to prototype quickly and with ease. Yet, game engines nowadays are bloated with a bunch of stuff that I will likely not use. Can't say I blame them. Most of game engines are company owned, and they have to suit the market needs. Whether towards hobbyists, indie devs, AAA corporations, investors... you get the idea.

​

While the other game engines are lightweight, they have their own limitations. Take GameMaker for example, where 3D is possible but may get very tricky.

​

That's where Godot comes in. It provides the sweet spot between game engine and game framework, allowing me to keep flexible during development session. I start with nothing as a solodev, and working solo requires to distribute my attention towards many things than just game development. For that, it helps me to safely take away my focus on programming towards other elements, like game design, art, sound, writing, and more.

​

Godot however doesn't have cutting edge features like in other game engine, and is not entirely flexible like other game framework. But considering the case I'm in, it's a perfect choice.

​

"But... no big game studios are using Godot. They're using--"

​

Much matured game engines, right? That's right. Just in case you're wondering, I have little interest to land a job in any game studio. I'm not even a "office job" kind of guy. I like to set my own schedule. Not because I want to work less, but to sort priorities with daily stuff, like exercising or reading. I'm in a situation where I either be the busiest person on earth or have nothing better to do.

​

If there's something that I think Godot can't provide, I'll take time to consider whether it's wise to migrate or not.

​

Anyway, that's a fraction of my reasons why I chose Godot. Most of them are just preferences. Anyone can make a game with any engine or framework, or with in-community editors like Roblox or UEFN. I even want to try S&box in a meantime.

More importantly, if you want to choose which engine or framework, just start with the one you're comfortable first and try build one! Although I can't be sure if you can make a pong clone in RPGMaker, but feel free to change my mind!

​

With the philosophy settled, it was time to put the engine to the test. Let's see what a fresh Godot project looks like when the goal is a basic pong clone game.

Now Starting: Pixel Tennex Project

I created a new project in Godot. There are two things I need to configure before proceeding: Renderer, and version control as you can see in the image below. Just like my days on getting used with Godot, I skipped the initial Renderer and Version Control configurations (mental note to learn Git basics later!)

​

Home sweet home!

​

​

After creating a new project and preparing it with adjusting viewport settings and adding folders to ease file management, I started to open my notebook and follow through what I've written from watching tutorials. What could be possibly go wrong?

"It really went wrong... but it gets better!"

After I made the game scene, I add some solid color background to it. I followed the instructions where I should set the color and the anchor preset to full to fill the viewport. I did as it writes, and... it just shrink into nothing, like 0 x 0 size. Whatever, I just manually set the transform of it.

​

Where banana background?

​

While writing this devlog, I took a look at the image I included here, and suddenly realized something. The child and parent nodes had different class inheritance. I had used a Control-based node for the background where a Node2D as a parent node. So, I did some tweaking (No, not that kind of tweaking) by adding a parent node for the current parent (scene), and... the anchor worked perfectly!

​

Now, I added the middle line as the reference suggested by adding the line2D node.

​

Why did I forget about the Godot's inheritance-based structure...?

Looks good, but I couldn't find a property to turn the solid line into a dashed line. After some digging, I realized the only way was to write a code, using Godot's built-in draw function.

If it doesn't exist, just code it

Instead of Line2D, I scripted a draw dashed line function on the parent node, and it worked exactly as I wanted.

​

Then I wondered about something. Why don't change the background node with the draw rect function? I did it, and unsurprisingly it worked as expected too.

​

The only downside? Since the background is now drawn via code, it won't appear in the editor unless I start the game. That's the price for a clean script, I guess! It's a nice little reminder of when to use a simple node versus writing a few lines of code.

Now I have the game area!

​

We now have a functional, if empty, game area! I also added placeholders like paddles, ball, and score just to spruce things up for a while.

​

Next time, the real fun begins: making the paddles controllable and maybe even getting that little ball to move! Thanks for reading along on this journey. It's about to get interesting!

​

If you have any questions, let me know in the comments below!