• Register

A hack-and-slash third person RPG for one to four players.

Post news Report RSS Devblog #1

A past look at the first few months of development.

Posted by on

A few months ago, after about three years of off-and-on side projects developed in Unity, I decided to commit to a single project. The most important part of game development (they say) is the part where you actually release the game; everything else before that is hype and speculation.

Unfortunately I haven't had the luxury of being taught game development through a career or school [fortunately did get the programming through school], though I would still love to work for a studio someday. It seems to be a bit of a Catch-22; you need experience to get the job to get the experience. At least with a commitment to a side project, I will hopefully have a portfolio to show, and maybe even some success.

My basic development strategy at the start was to develop as many features as possible in a rough format. The reason behind this was because I know that I will keep certain features and drop others, therefore by trying them out in the larger context it was easier to see which ones were fun and engaging, and which were getting scrapped. The second reason was that iteration seems to be invaluable. I've learned that I'm simply not experienced enough to get anything right the first time. But tweaking it here and there, over and over, for a long time, hopefully it will move in the right direction.

Going over article after article about best practices for new-ish developers was the mantra: start small, your ideas are too big, do something achievable. And for a while developing my game, I did believe that. Features began to feel like a chore to implement, my work felt open ended and therefore too large. My problem was that I was working on a side project and not a fleshed out project.

Nothing in the development of the game so far has been difficult per se, but it felt that way because my energy was being wasted on playtesting the same thing repeatedly. I didn't have a solid plan in place that said something along the lines of, "These 3 features are not implemented yet for this area of the game. Here is a well-thought out pseudocode for each". Especially being on a one person team, it's been difficult to pull myself away from the computer to sit down and write out what I want. But the value compared to time spent has paid back immensely.

It can be hard to make design decisions because wrong decisions mean a waste of my small amount of development time, possible technical debt from leaving code around to clean up, or even just misunderstanding what my target audience will enjoy. But they do need to be made, as soon as possible, completely fleshed out and ready to go before hand touches keyboard.

My other biggest issues of the past few months (that I have been much better about recently) was context switching. I would have so many features in development at once that it meant most weren't in working condition at one time. Playtesting hardly felt like it did justice to what I was creating. Recently I've tried to focus on one area at a time and really nail down a milestone in that feature before switching, as much as I may be tempted.

Development blogs for me always become self reflections of my own dev troubles but writing is generally the easiest way to get these things out. Despite all this, I've been very happy with the progress I've made so far. There are still a lot of major decisions with respect to the gameplay and general direction to be made. Perhaps in a future update I will post some more updated images of gameplay, but for now, this was mostly about the development itself.

Cheers.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: