Hello again! It has been a week since my last post, so it's time for another one. Since the last post, I've looked into Unity's component system, input handling, and physics. After that was all figured out, I didn't really have anything specific that I needed to look into before diving into the process of making the game. I spent the second half of the week planning story arcs, conflict mechanics, and concept art.
My first goal when studying any new game engine is to make a character and make it movable through user input. In Unity, this meant starting with the component system. You put a GameObject into a scene, then you can add components to it to change its behavior. Most notably you can place a sprite into a scene, then make it interact with the physics engine simply by adding a RigidBody2D component to that sprite. At first glance it seemed reminiscent of Godot's node and scene system, but in truth, that system is most similar to Unity's prefabs. To make a physics-based object in Godot, you need to make a scene (basically a prefab) that has a sprite node (basically an object) and a seperate RigidBody2D node, then instantiate that scene into your game. With Unity's components you can do all of that in one object easily. It remains to be seen how easy it will be to manipulate complex objects programmatically compared to Godot, but so far I like how components work.
The next system to study was Unity's input handling. This is where I started to regret my decision to change from Godot to Unity a little bit. Unity currently has two ways of handling input: the input manager and the input system. The old way is the input manager, but when you go to use it, there's a warning that recommends using the newer input system. I had a cursory look at the input manager anyways and it seemed more complicated than it needed to be, so I went with the newer input system. The first thing that put me off about it was the fact that it is in its own separate package that you have to install and enable in each of your projects. That's not a major problem in the grand scheme of things, but something as important as the new input system really should be built in. I was actually really interested in the input system because it looks very similar to the input handler in Godot. You define an input action, apply the keybinds that should trigger that action, then implement the action's function in code. Embarrassingly, I got stuck here for a while. I defined the action in the input system, added the input handler component to my player object, wrote the code to make it move, then hit a wall when trying to wire the code to the keybind. The problem ended up being in the input handler component on the player object. That component has a field that asks for the reference of the object that contains the code that should be run when input is detected. What I didn't know was that the code needs to be attached to an object, and you need to reference that object in the input handler's field rather than the code file itself. Figuring that out caused a bit of frustration, and there were a couple of other minor issues that I ran into, but nothing so crazy that I couldn't figure it out from reading the documentation.
The last system that I felt obligated to look into before officially beginning the development of the game in Unity was the physics engine. I gotta say, the physics in Unity is a lot more interesting than Godot, and as I mentioned earlier, it's a lot simpler to use. Throw a RigidBody2D and a Collider onto an object and you're good to go. Godot's physics aren't that much harder to work with, but making a game is a lot of hard work already. Simple systems go a long way to make that work easier. On top of the simplicity, Unity has a lot of built-in physics components that have no equivalent in Godot like Joints or Effectors. They add a lot of very useful functionality and require very little work to implement, so I am enthusiastically happy to have access to them in this project. Once I had watched a few tutorials and gotten the physics applied to my player object that could now move around my test project, I didn't really have anything else I felt I should know before starting the game. Honestly, I was nearly disappointed that the physics engine was so easy after the struggle I had with the input system. My only step remaining was for me to begin the early stages of development.
I expected to take all of January studying topics in Unity, so I wasn't really ready to start work on the game right away. For a while I felt like a deer in the headlights trying to decide which piece of this monumental project to work on first. I settled on planning out the story and conflict mechanics first, while also working on concept art for the main characters. The story's premise has been nailed down for a while now, so my main focus has been to decide on the details, the quest-to-quest happenings, and tailoring the game's mechanics to those happenings. The concept art is by far the hardest of those three tasks. I went through some articles about the importance of creating a clear concept before attempting to implement some kind of crazy idea into a large project and I went through some tutorials on how best to make concept art. There's only one main obstacle between me and a bunch of well-defined concepts; my artistic capabilities. I had never been much of an artist before 2020, but I've made leaps and bounds of artistic growth through the projects that I took on last year, and through this concept art and just about everything else I'll be looking to continue those leaps, but for now I'll just say the concepts look a little rough. I'm not overly worried about the quality of the art for the concepts because they are in the traditional style while the game's art will be 90% pixel art which is a medium that I am much more comfortable with. That said, I still want the concepts to be as good as they can be. To that end, I have committed for the foreseeable future to producing two pages of sketches of the game's characters and environments every day until I can make some art that passes for good. While doing so I'll be sure to continue studying the fundamentals and deeper concepts of art so I can apply them to my sketches each day and continue growing, rather than just making bad sketches for the sake of bad sketches.
That's just about everything I've done this week, so I guess this is where I'll leave the log for now. Thank you to everyone that has read this far. I hope you enjoyed it! The next installment will be published here on January 23rd if you're interested in reading more about my progress. Next week I will talk a little bit more about the scale and style of the game in addition to the things that I have made and learned. Look forward to it! YEET!
Top comments (0)