DEV Community: Wilucco

Project 2021 Devlog #3

Wilucco — Sat, 23 Jan 2021 23:05:10 +0000

Hello again! This week's entry isn't going to be very long. I really did not do much in the way of game development in the past week. The reason for my indolence is that my other career pursuit took priority for the week.

As I mentioned in the first entry of this devlog, I stream games on Twitch in addition to making games offline. The main game that I stream is a spiritual-successor to Diablo 2 named Path of Exile. On Friday, January 15th, they released a major update and I decided to spend the week playing and streaming that instead of working on my own game. This was for two reasons: first, I wanted to take advantage of the hype around the update and give my viewers on Twitch extra footage to see all of the new additions in the update, and second, I wanted to have my own fill of the update so that I could focus on my development work going forward without feeling like I missed out. The streaming went very well, and I've had a good time with the update for myself, so I'm thinking that I'm about ready to dial the game time back and buckle down on the gamedev time instead.

I may not have done much this past week, but the image included in this post is the one piece of work that I have to share. It's a drawing of a scene similar to the one that I intend to begin the game with. I'm not really ready to reveal the details of it all yet so I'll leave them to your imagination for now. As time goes on, I'll release more and more concrete information, but for now it's just too early in the development process.

Thanks for reading this short little post! I'll definitely have a more substantial post for next week, so make sure to come back next Friday to read it! YEET!

Project 2021 Devlog #2

Wilucco — Sun, 17 Jan 2021 08:54:08 +0000

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!

Project 2021 Devlog #1

Wilucco — Sun, 10 Jan 2021 05:04:57 +0000

Hello everyone! This is the first installment of the devlog that I will be keeping for the development of my next game, which I am currently calling Project 2021. There will be a new post every Saturday for the duration of its development where I will detail my thoughts, experiences, troubles, and triumphs from the week's work. I have yet to truly begin making the game, so today's log will serve as an introduction to my background, this project, what I hope to accomplish, and some challenges that I expect to face over the course of its development.

For those that don't already know me, my name is Jacob Senecal, also known as Wilucco. In 2018 I completed an Associate's degree in Computer Programming, but couldn't find work with it in my area. Near the end of 2018, I decided to start streaming some games on Twitch so I could try to make a bit of money on my own even if I couldn't find any work, and I ended up falling in love with it. I enjoyed it so much that I spent most of 2019 focused on growing my stream rather than using my degree. I was very happy with my progress on Twitch, but around the start of 2020 I decided that I should find a use for my education even if I couldn't find any development work, so I chose to make my own work.

I set out to make one mobile app or game every month of 2020. I made two simple apps in January and February, then in March decided to take on a slightly more complicated project in the form of a game called Idle Climber. It was simply a game about jumping up a never-ending mountain with a currency system, some items that you could get, and your character would continue climbing while the app was not running. It wasn't a complex idea, so I figured I could get it done relatively quick. Long story short, I had no idea what I had gotten myself into, the project ended up taking two months instead of one, and I got really disappointed that it took so long to complete such a simple idea. I decided to take the knowledge and experience that I gained from Idle Climber and try again with a different idea in May. The idea this time was a bit more complex, but still not so bad. It was a game about taking rocks of different shapes and sizes and putting them on a grid to try and fill up the whole grid with every single piece. Even knowing what I did from making Idle Climber, it took six months to complete Box of Rocks, but I was less disappointed this time. I learned a lot more about each facet of making my game when I wasn't in a huge rush to complete it. I had more time to spend getting each piece of art and game-play just right and I believe that Box of Rocks is now a much better game because of it. Box of Rocks ended up being my last project of 2020, so that brings us to now.

It's a new year, so it's time to try a new perspective on game design. My games from 2020 each came from very specific ideas that ended up as very simple mechanics-driven games for mobile devices. They were also both developed under an attempt at a very strict time constraint. This time I'm giving myself much more time; the whole year of 2021. Not only that, but rather than a simple mechanical mobile game, Project 2021 will be a story-driven RPG (with fun mechanics) developed for release on Steam and any other PC platforms that I can publish it on. For now, I don't want to delve into the specifics of the story or mechanics that I intend to include, but as the year goes on I will release more and more information about what you can expect from the game. These releases will come in the form of short stories about the game's world, game-play videos, and even demos as time allows, so keep your eye on this devlog if you want to stay up to date!

Aside from making a good game that many people can enjoy, I have a couple of goals for my own personal growth as a developer that I would like to reach while making this game. The most important one to me is to learn how to effectively use the Unity game engine. My previous games were made in an open source engine called Godot. While many people consider the two engines comparable, I feel totally lost while navigating Unity's UI even after nearly a year of using Godot. I suspect that it will take me most of January to get up to speed on Unity's workflow, so the next few devlogs will likely be focused on my efforts to learn Unity and compare its features with the ones that I already know from Godot. That is my main technical goal. From a design standpoint, I have never tried to tell a story in a game, and therefore, I have never tried to tailor game mechanics into that story or the larger world that it takes place in. As I mentioned earlier, my games were very simple and one mechanic was the whole game. This time around the idea is the story and we are going to need multiple mechanics that fit that story in order to tell it properly in an enjoyable way. It's a very different starting point than the one that I'm used to, but I look forward to seeing how it all works out.

There will no doubt be many challenges ahead in the year ahead. The one that I expect to be most difficult will be the challenge of managing the scope of Project 2021. I had some issues with scope management in my previous games that served to lengthen the development time. Between the knowledge that I gained from working through those scope management issues and the longer development cycle of this game, I hope to mitigate those issues to make an enjoyable game with a compelling story and engaging mechanics without overdoing anything. The key to managing the scope of this project will be in telling a very good story while also finding the right balance between mechanics and story. Mechanics can be very complex and time-consuming to develop, but they are what drives a lot of the fun in video games for a lot people. It's important to include enough interaction with those mechanics to let players have fun, but a story is much less technically complex to develop. If that story is well-told, then it can be just as interesting as actually playing through mechanics, which means that I can spend less time developing more mechanics, and more time fleshing out the story and polishing the game without sacrificing the players' enjoyment. If we can manage all that, then I feel like this game will be a huge success.

Thank you to everyone that has read this far. I hope you enjoyed the post and I look forward to sharing some incredible things with you over the course of the year! YEET!