Godot 3.2 is an exciting new launch with many new features. I did encounter a little issue with my current project when switching to Godot 3.2 that my solution may help people out.
I wrote a finite state machine for use with my game. In this state machine, a state calls on the player controller. For some reason, the state machine is loaded before the onready commands are called in the player controller, causing any onready vars to not be prepared. To fix this, and to add a little bit of lazy programming into the player controller, I implemented the following code:
onready var kinematic_controller : KinematicBody2D = get_node("Character_Controller")var kinematic_controller : KinematicBody2D = null ... func get_kinematic_controller() -> KinematicBody2D: if kinematic_controller == null: kinematic_controller = get_node("Character_Controller") return kinematic_controller
This way, if for any reason the onready call to set a controller is not called, we can call it in the get function. I got my game from a non-running state to running perfectly again.
This blog has been idle for a significant amount of time. I have fallen too busy to follow my passion in game development. This is due to the fact that I do work another job full time, and I was pursuing my Bachelor of Science in Computer Science degree full time. Game development just took a back seat. Well, now this is changing. I graduated from my program in December of 2019. Now, to fill in the time that I spent working on my degree jumping back into game development full time.
Now, let me lay down my intentions and plans with this blog, so that anyone reading on this site understands my actions and intentions. Getting back into game development is my attempt into changing my career to become a game developer. Over the next three and a half years, I intend to put a lot of effort into developing a game for release. This blog will go over my development journey, while focusing on tips, techniques and procedures for others to succeed in their attempts at learning game development.
First off, the tools that I intend to use for development are going to be fairly varied to work on my projects. I will write about these tools and their usage in game development as I work on the projects.
Game Engine: Godot
The engine I will be using from here on out is the Godot game engine. There are a few reasons for this. Namely, the flexibility in usage in the most I have ever experienced in the past. I have worked on RPG Maker, Unity, App Game Kit, and others. All of the proceeded tools are fantastic tools and they satisfy a place in the market.
RPG Maker is a great entry point to new developers who wants to see the process of adding content, however, it is quite difficult to change mechanics. There is a high reliance on plug ins with specified orders and such, but lacks the flexibility of a full fledged engine. However, it makes up for this with ease of use. For my purposes, RPG Maker is not flexible enough for what I want to achieve.
Unity is an amazing engine with many options for developers. It is why it has become one of the top engines on the face of this planet. However, with the closed nature of Unity and it’s growth, it has become rather bloated. The way components works with each other leads to situations where it is exceptionally easy to create an interlocking system that is convoluted and harder to work with. There are also fewer and fewer ways to script for Unity.
App Game Kit is an excellent tool for pure C++ usage, it’s workflow is too narrow to achieve what I want to do. There is also much more work needed to achieve a full project to be released.
Godot offers the flexibility of Unity with options to code in GDScript and C++ (With Mono C# as well). Working with compiled C++ gives a new level of optimization that is not possible with Unity. I can work in C++ for computationally intense work while using the simpler GDScript for simpler tasks. This is also neglecting the fact that I am developing on Linux, which none of the other tools can really do as well as Godot does.
What can I say? Tiled is so easy to use and powerful that there aren’t really any significant alternatives for the work that can be done.
Similar to Tiled, Aseprite is so power in it’s workflow, and reasonably affordable.
Blog, and the future
As covered, this blog will be my game developer’s journey. Many of the blog posts will be about the proceeded tools, but more importantly, I plan on focusing on techniques that are universally applicable. I plan on a blog post about every week or two. Whether it is a simple update, such as this post, or a game development concept, there will be something with regards to game development regularly. Think of it as a replacement to the essays that I worked on in college. For this posting, it is simply a status update. I look forward to developing with you.
It has been a long time since I have done a proper blog post. This one is the first part of a multi part series of importing Tiled maps to AGK. I use AGK in Tier 2 as a game framework using C++. This is the real draw to AGK for my use, as I have the simplicity of AGK with the power of C++. However, this tutorial is written using an AGK Tier 1 snippet as there is no need for any added complexity. I will eventually write a C++ variation that is more flexible, but none the less, let’s start part 1 of this tutorial. It is important to note that this does not only work with Tiled, it can be used to load any tileset/atlas image easily, but Tiled is my motivation for making it.
This is a code snippet that creates a file that can be used for tilesets, created in the AGK expected format for tilesets. I will write a full tutorial on how to use this code in a future post. See this post on use of the snippet.
//Change these values if your tiles are a different size in pixels tileWidth = 128 tileHeight = tileWidth numHorizontalTiles = 16 numVerticalTiles = 16 //Open a new file to write. I found no success writing to .txt. fileid = OpenToWrite ( "myfile" ) //Variables used in the loop. string$ = "" //This will be what gets written to the file. tileid=0 //Used to count up and assign each tile an ID //This is the same as saying for(int i=0;i<numHorizontalTiles;i++) with the i++ at the end of loop. i=0 //Start at 0 While i<numHorizontalTiles //Same as above, nested for loops. j=0 //Start at 0 after each loop. While j<numVerticalTiles //increment tileid each loop. In Tiled 0 is no tile, so we start with 1. tileid = tileid + 1 //Assign the line to be written to string$ string$ = Str(tileid) + ":" + Str(j*tileWidth) + ":" + Str(i*tileHeight) + ":" + Str(tileWidth) + ":" + Str(tileHeight) //Write string$ to file. WriteToLine saves it in ASCII readable format. WriteLine(fileid, string$) /* Remove to watch progress. Print(string$) Print(GetWritePath()) Sync() */ //Remove to watch progress. //j++ for the loop j = j + 1 EndWhile //i++ for the loop i = i + 1 EndWhile //Close the file CloseFile ( fileid )
This is just a quick update on the progress of my project, “The Lost Shipment”.
*Starter Town and events related
+Morticulus and events related
+”Castle Town” and events related
+Equips, skills, enemies, and combat balancing.
-Mountain dungeon and events related.
*Being all needed finished, + Being in progress and almost done, – Being has yet to be started.
Being that I just reached the half way mark of January, I am a little further behind than I would have hoped. I should catch up this weekend though! Stay tuned!
In this tutorial, we will be covering how to check direction checking. This first half will be covering pseudo methods and just theory, the second half will be implementing it into RPG Maker VX Ace.
This portion of the tutorial will be usable in any game making engine as it is all pseudo, and not limited to RPG Maker.
What we will be covering in this tutorial is how to make an event trigger only when facing a character, and rom a specific distance. Sound simple right? Well, let’s get started!
Now, let me show an image of what we are going to achieve.