Writing this particular post is a brainstorming exercise. I don’t know what’s going to come from this article or what conclusions it might reach, but I need to think about where I go next.
Just to recap what’s happened so far, I’ve done the following:
- Created a background
- Created a sprite
- Made the code base better
- Made the sprite better
- Made the background better
If nothing else, this is a good illustration of how software development is an iterative process.
The foundations of software
Some methodologies for developing software prescribe small iterations, some large, but either way, as the code grows and develops, it will always need to be pruned, moved around, fitted to a changing brief. Refactoring is an important part of this process. It makes code more maleable, more flexible, less resistant to change. And when code is less resistant to change, developers are less resistant to changing it, and more willing to change it further, to add new features, to refine existing functionality, or even just to refactor further.
This is a good thing.
By keeping on top of the code base that I’m working on, I know how to change something, where to change it, and can more easily see any consequences or ripple effects that may occur. This isn’t such a big deal when building something that I’ve created a hundred times before, like a typical model-view-controller website, but when venturing into the unknown, I almost need the structure of the code to guide me.
I read in a book about software patterns that even if a developer is unfamiliar with a definition of a given software pattern, they are likely to be familiar with its concept. By practising a particular skill for long enough, one comes to acknowledge that there are certain tricks and ways of doing things that make everything easier. You don’t have to have read about it in a textbook, or know its formal name. Software patterns are just this: well understood ways of solving common problems. Be it the repository pattern, the factory pattern, or even the singleton, developers can quite easily recreate them without being aware of what they are, just how people create correct grammatical constructions in writing and speech without necessarily knowing the names and strict definitions of the underpinning rules.
By applying the familiar (patterns) to something unfamiliar (game design), I’m hoping the code can guide me in roughly the right direction, all the while remaining easy to change and restructure when I inevitably head down a blind or narrowing alley.
Where I go from here with my sprites and my background I’m not entirely sure. I’ve been trying to think about what people want from a game, and what I would expect when I first touch that app icon in the device’s menu. I need a goal, something to reach for, but to keep me interested, I must not be allowed to fully accomplish all goals in front of me. Yes, there must be eureka moments when a player can be satisfied at achieving something, but there must always be something else to aim for. When this is no longer the case, the game is over.
I can think about the mechanics of the game and what makes the sprites move and how I decide how to spawn more and push them off the screen and where to show the day of the week of cash flow all day long, but until I’ve got that human element, that goal, no one’s going to want to play, and I don’t have a core concept to build software around.