I got some good advice from Brian Hook as well, namely that I should focus on completing a game, something realistically achievable. I am getting to the point in my life that I would like to try to go indie, finish a game and try to market it. In order to do so, of course I need to finish one first. I've invested a lot of time and effort into the initial Golem project, but over the past few months it has become increasingly difficult to make concrete progress. Not only is the codebase crippled by numerous bad design decisions and liberally polluted with bad programming, I feel that I also bit off more than I can chew with the scope of it, and while I believe I could eventually finish it (given a couple years) I wonder if it would be worth my time to do so. As Brian pointed out, the game is strongly similar to Diablo. (As he put it, from a distance the screenshots look identical.) In making it so, I may be shooting myself in the foot by trying to compete with Diablo. I don't really want my game to be so strongly overshadowed by comparisons to Diablo that people don't focus on the things that are unique. I want my game to stand on its own, as Golem, rather than as a 'Diablo clone.'
In addition to that, there are things I have in mind for the design of the game that would be difficult to accomplish with the current engine. From the beginning, a part of my goals for the project has been to somehow capture a bit of the essence or feel of classical roguelike gameplay that Diablo itself failed to achieve--some of the quirkiness, if you will. By slavishly duplicating the Diablo style of control, I have limited the ability to step outside the bounds of that system of control, and that is not really what I intended.
I have already begun a fork project of Golem, which is a refactoring of the engine base to implement a 3D characters on 2D isometric background hybrid system. Taking what I have learned from the initial Golem effort, the project is already more solid and well-designed. The hybrid system removes or reduces some of the limitations I faced with the initial Golem project, most notably the size of the asset database. Even with only a handful of monster animations completed, and 5 tilesets, the on-disk size of my graphical asset database was getting wildly out of hand. Each monster implemented up to 6 attack and spell-casting animations, a walk cycle, a run cycle, a standing idle cycle, a react-to-hit sequence, and a death sequence--all of which quickly adds up. The isometric perspective compounds the problem by requiring separate rendered sets of the animation for each of the possible facing directions. If a monster can face in 8 possible directions, that means the animation sets are duplicated 8 times. 16 facing directions doubles it, 32 doubles it again. When you implement the sprite frames as RGBA images, 100+ frames of animation per facing direction quickly bloats out of hand. (Probably the very reason Blizzard themselves used 256 palettized graphics for Diablo 2.) Texture compression, encoding and other tricks can circumvent a lot of it but in any event the limits this sort of memory usage places on the system are horrendous.
The simple switch to 3D characters has largely eliminated this as a problem. First of all, 3D geometric data comprising 100+ frames is far smaller in memory usage than the equivalent set of sprite frames, by orders of magnitude. Instead of having to pre-render 8 sets of animation data, I simply rotate the 3D model to face in the correct direction. No artificial constraints to 8, 16 or 32 facing directions. No jerkiness arising from too-few animation frames; mathematical interpolation from keyframe to keyframe ensures that animations with even only 5 or 6 frames are smooth and fluid whatever the animation step speed.
I could go on an on about the various advantages and drawbacks of the new system. Suffice it to say that I have decided once and for all to shelve Golem 1. I have cannibalized it, and will continue to cannibalize it as needed, in order to contribute to the new engine design. But I will not continue further development on it. I am in the process of recycling what assets I can (tilesets and static objects which can be billboarded in the new engine, scripts implementing various systems, etc...) and what code I can as well.
Additionally, I will not be doing any intensive development on Golem3D and the editor. I may work on it during those times when I need a break of routine, but for the most part I am going to focus on the new Golem hybrid engine, with the goal of completing a small game for my debut into the world of indie development. It will be nowhere near the currently designed scope of the initial Golem--I am thinking small, maybe 16 to 20 levels of gameplay. I'm still working on the design, so details are sketchy outside of the technical (engine) aspects, but I am going to steer away from the stat-intensive, vast array of experience levels, skills and randomly generated equipment that I was working on with Golem, and try to focus on a more limited (and realistic, for a one-man team) system. Less of an emphasis on building and balancing a bunch of stats, and more emphasis on action and puzzle-solving.
I've learned a lot from Golem, and I'm certainly going to miss working on it. (Well, kinda. But not really. I mean... ahhh, nevermind.) I learned a lot from it, as it was by far the largest project I have undertaken to date, and I am a better programmer because of it. And a vastly better artist as well.
So for anyone who has been following old Golem and awaiting the long-promised demo release, I apologize for disappointing you.
I will be updating my website with details and info on the new Golem, so keep an eye on it.
Josh
