A Little Background At age 8 I designed my first board game, at 10 I studied Q-Basic’s online help and started making video games, and at 13 I learned to develop 16-bit real mode DOS games in C with the help of Teach Yourself Game Programming in 21 Days, a great book that assumed an understanding of the language that I then lacked. Employment and responsibility soon stole most of my time, but over that past year I developed 7 Android games using only RFO-Basic and other Android apps, as well as a tutorial for the language. I would like to recreate some or all of them in Godot before starting a project that’s been in my mind for years.
Attracted by Godot The open source Unity killer has attracted me for some time. I considered Cocos because I like the API interface but I worry about its future. LibGDX seems like a solid framework with a solid future, but I dislike Java despite its good performance with in LibGDX. I appreciate using objects to represent objects, but I hate being forced to encapsulate my entire program in objects. In fact I’m quite used to writing software in a very linear fashion from the ground up, with complete control. It’s old fashioned, I’m sure, but I still use states instead of events, and a frame limiter instead of time deltas.
Obviously Godot is a big change for me. Despite my learning C from a single book back in ‘94 without internet or anyone to ask for help, I have ran into several roadblocks while navigating Godot. I love the concept, the editor, the open source nature (running in Linux Mint 18.3 Mate 64-bit), and the physics performance I’ve seen in various videos and game demos. But I’ve failed to complete even the simplest tasks.
During the hours I’ve spent stumbling around the Godot editor, I could have gotten my next project well off the ground using SDL with C or Pygame. But I lack the math skills to realize my vision without a proper physics engine. Yet while I accomplished it’s equivalent in a slow basic interpreter, using move_and_slide() to navigate my first sprite through a tileset results in slipping right between the walls!
Problem #1 – No Sprite Sheets in Animated Sprites This should be a no-brainer. I decided to use a kinematic body for the character from Cooties, the game tutorial I wrote for RFO Basic. I was shocked to discover that I cannot load frames into an AnimatedSprite from my existing sprite sheets. Yet I can use them in tilesets and in regular Sprite Nodes by appropriately setting hFrames and vFrames.
I explored the editor for some time but found no method to add frames to an AnimatedSprite from a spritesheet. That means I have two choices: either I break the spritesheets down into individual images or I can write my own animation player for the my sprite nodes.
Breaking down the sprite sheets seem contrary to everything I read about texture packing for better GPU performance, as well as my own preference to avoid too many small files. After setting a regular sprite node to vFrames=6 and hFrames=5, I can adjust the frame attribute manually in my script to animate the character. I’ve been animating my sprites through code for a long time, so it would be easy to do, but I feel that it’s a bad idea. If I start writing everything in script instead of letting the engine do the leg work then I may as well write the whole thing in PyGame and do like most programmers. Ignore efficiency and just use as many of those “unlimited’ of processor cycles that a modern processor offers.
Problem #2 – Slipping Between Walls I loaded a sprite sheet into a tileset and set up the collision objects. Then I wrote a simple script to move my unanimated character with move_and_slide(). For some reason the character was slipping between the wall cells, and on occasion, getting stuck between a wall and a pit(I haven’t coded the falling death or adjusted collision layers yet).
I experimented with many settings to fix the problem. I returned the tileset’s cell.size to its default setting, which made the tiles too big for the grid. Even with the tiles overlapping my character still slipped between them. I reduced collision.safemargin to its minimum of .001. Then I examined all the scales and found that the CollisionObjects for all the tiles were scaled at like 3.3.
Even after reading the warning about keeping the scale at 1, I inadvertently changed them when resizing the CollisionShape2Ds. I replaced the Shape2Ds with Poly2Ds and verified all scales are at 1 to one, but it made no difference. The amount of wiggle room between cells is enormous!
Problem #3 – Separate Shapes for Cell and Projectile Collisions While I experimented with my first kinematic body to no avail, I realized that I would soon run into a bigger problem. For the original Cooties I used a single point near the character’s feet to determine its cell location, checked the grid, and accomplished proper move and slide behavior. To handle collisions between the boy and the ‘icky’ girl enemies, as well as the soccer ball vs girl collisions, I calculated the distance between the center of the two objects and triggered a collision if the distance was slightly less then the cell width. This way, even though the character’s heads overlapped a wall located above them, they could never hit each other through a wall (okay, it did happen once in the dozens of hours I’ve played since finishing the game. I think that’s still pretty damn good).
So my dilemma is this. I want to handle grid collisions using a small circle around the character’s feet, which is much more natural for a top down game with vertically drawn characters. But I still need to handle weapon collisions(the boy protects himself from cooties by throwing his soccer ball at the girls) using the character’s full size. This is easy programatically, but I have no idea how best to accomplish it in Godot, since collision layers and masks are attached to the Kinematic body, not the collision shape. I think I might need to create two bodies and set one’s position to equal the other in code, or maybe use rays. I’m not there yet, but already I’m nervous.
As a side not, getting my character to stop slipping between two diagonally aligned walls and onto an empty square beyond them took a bit of patience. I was reaching the limits of the RFO Basic interpreter’s performance and had to accomplish my ‘physics’ , AI state-machine, and ray-casting with as few if/then statements as possible. Eventually I accomplished gameplay that I could be proud of. I know I can solve my problems through clumsy code with enough trial and error, but in Godot I always feel lost.
Problem #4 – Loading Map Grids from Existing Files Most of my games have loaded maps from a grid stored in a text file or an SQLite database, which could be saved and loaded from the built in editors. The maps for most of the games would be easy to recreate, but I have about 90 levels for Abyss, a sokobon-ish puzzle game, that I would like to load in Godot. I’m far more used to loading, accessing, and saving levels in simple 2D arrays, and I’m not sure how to instantiate that data into a Godot scene. In fact I don’t even know how to load levels that were made with the included tilemap editor. As far as I could tell I would need to create a new scene, add a tilemap node, and load a new instance of the player and other nodes necessary for the level.
To anyone willing to assist a passionate amateur game designer’s attempt to return to his old hobby with a modern engine, I offer my sincerest appreciation in advance.
Michael C Palmer,
