Week 15 – Refactoring

Fowler's Refactoring

Hi everyone and welcome back to our blog!

This week deals with a specific refactoring project. In order to achieve active awareness of refactoring whenever we are writing code, we should refactor a given project according to Fowler's idea of refactoring.

Below, the refactoring-projects of each team-member are linked.

Of course, this is not all what we have done so far. Following, new developments of our tower defense game are described.

UC Upgrade and Sell Towers

According to this Use-Case serveral functions were added.

First of all, a range indicator according to the selected tower has been created. For this, a circle with a radius depending on the tower range is drawn and filled with a transparent background (like shown in the picture on the left).

Furthermore, a popup window has to be created. Within this popup, the stats of this tower as well as an image of the tower and the tower stats after the upgrade are shown. In addition, there are two buttons: one to sell the selected tower and one to upgrade the tower (like shown in the second picture on the left). When clicking on the sell button, one receives the half of the current value back. When clicking on the upgrade button, money according to the amount of the price is decreased. Right now, the maximum level of all towers is three. According to this, the text of the upgrade button changes to "max reached" and there will nothing happen when clicking on the tower.

The last necessary feature to add within this Use Case is a sign to show the level of each tower. We decided on displaying stars for the tower-levels. When upgrading a tower to level two, one star appears on the top of the tower. When upgrading to level three, a second star is added and when selling this tower, all stars disappear.

UC Edit Settings

The use case Edit Settings should give the player the possiblity to pause the game and change some important settings. Therefore by clicking the pause button a menu is shown where the player can toggle sound, background music and animations. Another button beams the player back to the main menu. If the dialog is cancelled the game will continue exactly at the same time it was paused. This feature costed us unfortunatly many hours, because of our current use of Java Timers which cannot be paused. So we had to calculate a delay for the towers for their next shoot and also for the waves to spawn and so on. Otherwise towers would shoot directly after continuing although they may have a pause time of some seconds. That would allow the player to cheat more or less. To calculate the delay, every object has to log its time of the last action to be able to retrace the necessary pause time for the next action if the pause button is clicked.

Even if the layout and also the Icons will be adjusted in the next weeks, we are now finished with implementing the functionalities of all our planned use cases. The game is fully playable now. But there will be some more cool updates including more towers and enemies with special abilities to improve the game flow.

6 Gedanken zu „Week 15 – Refactoring

  1. hey dudes
    i saw all pf you committed only on master.
    try ro make branches with speaking names for every step you implement and the do a pull request. its so easy that its not even too much effort for this kind of repo/project.

    1. Hi Team GreenClothaWay,
      thanks for your feedback!
      Sadly, we failed to see the aspect of using branches in this project and cannot change the use of branches anymore but we are using a lot of branching in our real tower defense project :).

      Kind regards,
      Nicolas

  2. Hey guys,

    overall your refactoring looks nice, just a few small remarks. Maybe you could also include the IDE specific files in your .gitignore, they could lead to problems when others clone your repo, although not important for this small example. Next, some of you renamed the statemant-method, I know it’s not the best name for that function, but I’m not sure if it’s a good idea to do this in a refactoring, as „old“ code that relies on this method will be broken after that change. At last, your tests include everything I believe, but a few more scenarios would be even better.

    Apart from that refactoring, great to see that you had time to work on two more use-cases. Our team wasn’t that productive this week.

    Looking forward to see more.

    Yours,
    Marlon from Clairvoyance

    1. Hi Marlon,
      thanks for your detailed feedback!
      Your hint concerning the .gitignore is really good, thanks!
      Some of us renamed the statement method because we did not think that this method name is chosen well and wanted to make the whole code as clean as possible.
      If the given project is actually a part of a bigger project, the IDE will refactor the remaining snippets of code as well.

      Kind regards,
      Nicolas

  3. Hey
    I looked at your repos, it looks like you did a good job. I just think you could have made the output string a little more general so you don’t always have to manually type / t for tabs for every other word. I would only define a constant for this Luca.

    Best regards
    Mr CardGame

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.