Like most in my age range, I grew up playing the classics. The games that always stuck with me the most were the Metroid games though. I loved the 2D ones, the Prime ones, and I even thoroughly enjoyed Other M until we moved to Maryland and I lost track of it. (I did give Hunters a fair chance. Like, I really tried. I just couldn't though.) So naturally, a "Metroidvania" style game is where my heart and focus have been in all of my post-Half-Life attempts. There is something nice and resolved of the simplicity, and the genre is certainly a departure from anything I ever worked on for Half-Life.
Now, I don't know about you, but when I fall for a game I fall hard. For the past couple of years it's been Overwatch for me, specifically on the X-Box. (The Overwatch character Brigitte is actually my inspiration for this screen name.) The unfortunate thing about multiplayer games in general is, they are stressful. I'm a yeller when it comes to game frustration, and I've definitely had some of my ugliest moments ever on the voice chat. Anymore, I have to enjoy the game in very small doses and keep a stern assessment on my overall experience. Good game, but lost--how jittery do I feel, or did I yell at all? etc.
What I'm getting to is, I think the contemporary focus on multiplayer games is a multifaceted whammy, and I find it distracting from the art form of game development. I have the most fun playing single-player (or perhaps local co-op), story-driven games with relatively static content and low-grind factor. Like, a Metroidvania!
So local (co-op) 2D games are what I will keep in scope. Thus, my first major architectural decision: Crossing off 3D-everything. This early decision frees up further architectural decisions across all boards, but thinking through 2D game content creation cycles raises a lot of flags for me. In terms of my previous post--tools, workflows, etc. that I want--I refuse to accept the static-leaning nature of 2D content. I want my characters to be truly animated and to actually interact with the environment, not just endless arrays of static sprites. And thus, my second major architectural decision: all non-static content will be driven by textured meshes and skeletal animations, and animations will be informed (constrained) by the environment.
One thing that always bugged me when developing content was all of the different tools you'd have to use just to get your content in a game. One unaffordable model editor for "models" (which are treated differently than the world), an unaffordable plugin for it just for skeletal animations, another tool for world editing, tools for managing whatever proprietary archive files the game uses, custom texture formats, etc. It's a mess, at least the last time I was seriously doing it (which was admittedly a long time ago). For my games and my development cycles, I want something integrated: tools not only meant for my engine, but that are literally part of the game run-time. So, the engine will contain content creation tools that can be used to create and adjust content in the middle of running a game. And there we have the codename I've given the engine: Integral.
Patrick, I remember a lot of your experiences when you were growing up. I enjoyed your blog. You described how you have to keep getting tools in order to come up with something. The same scenario comes up with anything technical as a hobby. I wonder about using a low-level language to get more into the nuts and bolts of what you want to create. Of course, that would be exhaustive. I hope that you will keep writing your blog.
ReplyDeleteLove,
Dad