The 3 Pillars
In my last post I talked about how I felt I was going about development in the wrong way, at least for me. In this post, we'll talk about what I'm going to do about that.
Let's jump straight into it: making full games isn't working out, so I'm going to take on much smaller projects with a focus on improving my skills. I'm going to organize these upcoming mini-projects into 3 'topics of interest,' each of which encompassing a skill or set of skills that I want to work on. These 3 topics, which I'm calling my 'Pillars', are Design, Architecture, and Tools. Here's a break down of the goal of each Pillar:
I've had a fair number of ideas over the years that spurred me to jump headlong into making a game. It goes great for a while, but eventually I hit a wall. Sometimes the idea just isn't working out and I can't figure out why, other times I get to a point where I don't know where to go from where I'm at. So what I'm going to do is take some of the ideas I currently have on the back-burner and prototype them. No expectation of making a full game, really just creating a single game system. I'll create the system to the best of my ability, trying to achieve the feel that I envision, and then critique it here on the blog.
My hope here is to work on my design skills and my ability to think critically about why a system does or does not work and how it could be improved. Getting back into the swing of prototyping will also improve my speed and give me a better feel for scoping and development time requirements. Finally, any standout prototypes will be candidates for moving forward with in the future.
For projects under this Pillar, I will primarily be using Unity. I know the engine well, it's flexible, well supported, and pretty fast to work with. This should allow me to implement my ideas quickly without running into as many technological hurdles.
The Design Pillar is probably going to be the most important in terms of the skills I'm working on and the projects I'm outputting. With any luck, one of these prototypes will transition into a full project eventually, and I'll be prepared to tackle it.
I'd like to think I'm pretty competent when it comes to problem solving, at least when I'm coding. I can identify the problem, come up with a solution, and implement it intelligently. That said, there's always room for improvement, and practice makes perfect.
Let's jump straight into it: making full games isn't working out, so I'm going to take on much smaller projects with a focus on improving my skills. I'm going to organize these upcoming mini-projects into 3 'topics of interest,' each of which encompassing a skill or set of skills that I want to work on. These 3 topics, which I'm calling my 'Pillars', are Design, Architecture, and Tools. Here's a break down of the goal of each Pillar:
The Design Pillar
I will readily admit, I'm not a particularly strong designer. I can meet specifications pretty well, but making those specs is another story. Looks and feels are just a little beyond me. While I'm perfectly content with not being great at everything, design is hard to work around. You can make bad art work and these days you can even get by without being a good programmer, but a poorly designed game is probably not going to end up being good. And my lack of design expertise has definitely contributed to my poor project performance.I've had a fair number of ideas over the years that spurred me to jump headlong into making a game. It goes great for a while, but eventually I hit a wall. Sometimes the idea just isn't working out and I can't figure out why, other times I get to a point where I don't know where to go from where I'm at. So what I'm going to do is take some of the ideas I currently have on the back-burner and prototype them. No expectation of making a full game, really just creating a single game system. I'll create the system to the best of my ability, trying to achieve the feel that I envision, and then critique it here on the blog.
My hope here is to work on my design skills and my ability to think critically about why a system does or does not work and how it could be improved. Getting back into the swing of prototyping will also improve my speed and give me a better feel for scoping and development time requirements. Finally, any standout prototypes will be candidates for moving forward with in the future.
For projects under this Pillar, I will primarily be using Unity. I know the engine well, it's flexible, well supported, and pretty fast to work with. This should allow me to implement my ideas quickly without running into as many technological hurdles.
The Design Pillar is probably going to be the most important in terms of the skills I'm working on and the projects I'm outputting. With any luck, one of these prototypes will transition into a full project eventually, and I'll be prepared to tackle it.
The Architecture Pillar
I'd like to think I'm pretty competent when it comes to problem solving, at least when I'm coding. I can identify the problem, come up with a solution, and implement it intelligently. That said, there's always room for improvement, and practice makes perfect.
The Architecture Pillar will focus on planning out, implementing, extending, and documenting a codebase. My plan is to work on my own game framework in Haxe, built from the ground up for cross-platform multiplayer between desktop, mobile, and web. Ambitious I know, but mind you this is not an engine. I will work on the game state system and networking layer, but leave other systems like rendering and sound to existing libraries. Furthermore, I'm going to borrow heavily from systems that I like from libraries such as Phaser and HaxeFlixel, just with my own spin on it. In that regard, this will be a bit of a research project, looking into how others have already done what I want to do and making educated decisions from there. This framework will definitely warrant a post of its own when I start getting into it, but suffice to say this will be a great opportunity to use project management tools that I've neglected in the past like wikis, task boards, and issue tracking.
Ultimately, my main goal for this Pillar is to maintain my development momentum. I've read suggestions that working 1 hour a day for week is better than working 7 hours for 1 day a week, so having something monumental to poke at over time will serve me well. Once I get going, my plan is to do something, no matter how small, everyday. This can range from implementing a new subsystem, to simply looking at an existing codebase and taking some notes.
While this Pillar might not produce much of substance any time soon, I believe this experience will be invaluable moving forward. If nothing else, working on this framework is something I've wanted to do for a while, but couldn't justify holding up projects for.
The Tools Pillar
There's this cognitive bias called the the law of instrument that is commonly phrased as "if all you have is a hammer, everything looks like a nail." Unity was definitely my hammer for quite a while. I learned real coding using Unity before college and it was my go-to for many projects throughout my schooling. It also became the hammer for many of my peers, which made it hard to try something new in group projects. All that said, I sort of missed an opportunity to try out the other cool engines and game development tools out there. This cannot stand!
The Tools Pillar is simply focused on learning new tools and software. Right now the only target in my sights is the Unreal Engine, but I do want to explore other options such as Godot and even non-engine tools that can improve my workflow.
For this Pillar, I will basically give myself free reign to mess around with the tool of choice. For learning Unreal, I will not be critical at all of what I create. I will work through baby's first Unreal game tutorials and create abysmal games that I should never show anyone. Trying out Unreal is also a good opportunity to get back into the saddle with C++, as it has been far too long.
Really, this Pillar is devoted to adding more tools to my repertoire to improve my resumé and giving me more options so I can make a more informed decision about what to use when I start a new project.
That's about it for now. Quite a long post, but I needed to get this all written down for my own sake. As you may have noticed, while the projects are going to be short-term, the plan here is definitely long term. I'm aiming to become a better developer, rather than having subpar work out there with my name on it. It'll take some time to get going and even longer for this tree to bear fruit, but it'll be worth it. Stay tuned, we'll be starting something soon.