Text Adventure Game: Step by step code evolution
Hello, World!
Hello, I’m one of the interns at 2Performant, name’s Cristian, and this is part 3 out of a series of 4 post. In the previous post, Mihai talked about the obstacles our app has been through. This post is about the changes and improvements in our code. I will talk a little about the git project, collaboration and planning, and more about the reviews and our code.
Git Project
Since communication and sharing code was important, we decided to create a git repository, so that our code is up to date. It helped a lot since the updates to the code were frequent, and new features kept popping in our heads.
3 things that you should not forget
- Post issue. You found an error, bug, bad code, etc., don’t think magic will happen and it’s solved. Write a detailed issue: problem is …, in file …, row/rows … and maybe even a solution to it.
- Assign issue. Your colleagues won’t start to randomly read your mind to know what you are working on. You found an issue that you want to solve, assign it to yourself so that they know.
- Close issue. After you solve an issue, don’t leave it there, close it, so that everyone knows it’s done.
Keep these 3 things in mind and all is good. We learned it the hard way. Errors solved late because someone thought they were already done without checking. Hours lost because an issue was taken by 2 people without assigning it. Waiting on an issue to be done (closed), when it was already done but not closed.
Reviews are important
As we coded, talked and designed our game, the deadline for the presentation of the code, and the review that comes with it was fast approaching. We had a total of 3 reviews, all of them revealed faults and gaps in our code. Those reviews were made by our senior developers, their precise and on point evaluation were of great help to us, not only in solving problems, but also on learning from them.
First code
On our first try, it was a little messy: some variables and methods had inappropriate names for what they did, files weren’t sorted, they were all in the same folder, and we had methods that were too long, or did more than they should.
Review 1
After the game was coded and deemed playable, we had the first round of presentation to see how it will be reviewed. It got a good reaction at the presentation and gameplay, the code review put light on our not so user friendly code. At the question “If someone who never coded read it, will he understand this code?” we realized our naming sense could use some work.
Second try
The second try was much better:
- Cleaner: less duplicate code, shorter one liners, less lines on every method
- Appropriate names:
use(item) — use given item
split in
use_consumable(consumable) — use given consumable
change_wearable(wearable) — change equipped armor(head, chest, gloves, etc.)
change_weapon(weapon) — change equipped weapon
- Closer to the concept of beautiful code: better indentation, snake cased names
But still a long way to go. The files were all still in same folder, and we still had code that could be improved.
Review 2
Our second review’s feedback was better than the first one, but we still had a long way to go. Due to early and on the run optimization and the redesigning, it had a different kind of mess. As our seniors said, some parts of the code were not needed, they were there because we thought they will be needed in the future, which was against the YAGNI principle.
We were also asked how would the code change to make it work on other devices, like Alexa or a browser, where input/output differ. Answer? It would have to change a lot, since it was designed with a terminal in mind, and relied on it. Those being said, our next task was another redesigning with this option in mind.
Third code
This one was made from scratch, because we decided that we needed a fresh start, in order to avoid previous mistakes. The best so far (like the saying, third time’s the charm), almost no mess, meaningful names, specific methods for specific task, a menu and an interface were made to manage the input/output for various devices, and it was quite a beautiful code.
Review 3
The result? Could have been better (it can always be better). The code was well structured, files in their folder, specific methods for specific task and could be used on all devices. All in all, we did a pretty good job.
Conclusion
Developing code, and developing high-quality code (that can be used and understood later by anybody), are two different concepts. The second one implies lots of planning, talking, reviews made by qualified people and good communication between team members. Stay tuned because there’s still one more post about our journey through this project as interns.
