I’m sure you don’t know, what Traced is at all, so I’m going to tell a bit about of it. It is the name of a new game we are currently working on. When I write ‘we’, I mean our four-person team, Kaylin, Ben, Julia and me. What kind of game is it? Here is a long quote from Kaylin Norman:
“Traced is a hacking type game set in a cyber-punk world where player plays a Grey Hat hacker. SecuDrone Industries has been an established company for some time; putting security programs in every major business and home system. Recently though, there have been reports of computer viruses and power surges worldwide. Evidence points to SecuDrone Industries as the culprit. In a bout of vigilantism the player will be tasked with the choice to either Defend Secudrone Industries by eliminating the evidence, or by investigating them in order to uncover the truth. Visually, the game will look like a normal computer screen with a “special” program created by the player loaded into it that renders hacking easier. The graphics will be minimal, as most of the files and nodes will be represented as primitive shapes.“
In other words, Traced is an old-fashioned cyberpunk game, it will be looking like an old MS-DOS game which imitates an old terminal (and keyboard) based operating system. (Do you remember these early green Hercules monochrome monitors? That’s why green is the main color of the game.) If you think “I’m sure this game won’t be the next Angry bird, it sounds too complex”, then you are right, but we don’t want to conquer the world, we just want to create a small and unique and interesting and quality flash game, and I hope there are a small group of hardcore gamers who will really like our game.
And why I write about our game in my professional blog? Because we have a deadline, Sunday the 21th of October. It is an important milestone, we plan to launch the first playable demo of Traced on that day. The demo will contain almost every in-game feature and the 90% of the necessary programming & scripting, the main difference between the demo and the whole game is that the demo contains only two playable leverls (the whole game will contain 30+ levels). After the demo, the game design and the programming and the tools will be almost done (except the bugs) and the next part comes after than, the writing of the missing texts, the design of the missing levels.
Maybe the demo will be one or two days late, but we will finish it soon or later, we are very close to finish it. I worked in the last 48 hours on Traced and I will work on it also in the next days. (Sad, but tomorrow I will have to travel a bit, so I’m off tomorow, after than I’ll continue the work.) I find the programming pretty intriguing, because I have to write pretty much working and bug-free code in very short time. So I don’t have enough time to write documentation or to draw UML class diagrams to design the structure of the program. Yes, it is some sort of agile development, and frankly, I really enjoy it. “I’m glad it has a name.“
Imagine the following hypothetical situations. You are coding a windowing system with various components and different prefabricated windowses (these windowses are represented by OO classes). You just finish a complex window with a lots of built-in components and you suddenly mention that the next window that you have to create is very similar to the last window, there are only 5 or 6 minor differences. What do you do? If you have enough time, likely you design a decent base class to these windowses or you design the next window in the same way like the last window, step by step. (It is up to the current situation, both of them can be a good solution.) But if you don’t have time, you just add some extra attributes to the existing class in no time, and through these attributes and some constructor arguments, you can transform the existing window into the new window.
Is it a good practice? Not always. When it is a large project and you know that you will extend it in the future, then a such “quick and dirty” solution can cause very much inconveniences. But if it is a small in-game window and you will never change it, then likely the quick solution is the best soultion. Time is always money, if you don’t take care for design, you will have more time for implementation, testing and debugging. You have to take the alternatives into consideration, you have to make your own decision and that’s why the agile development is damn interesting.