krisgun / noisy-bird Goto Github PK

Komplettering

• Update the description! Super out-of-date.
• Add a screenshot of the game (added demand as the description seemingly hasn't been updated since the fall of Rome).

Feedback

Overall, you've done a really good job here! I will mostly be giving you feedback on the project process and structure, rather than the code.

Stuff that needs some work

• Reference issues in commits: It becomes much easier to track progress if commits that are related to issues reference the related issue. From the issue side, it's easier to see that there is progress, and from the commit side, it's easier to understand the context of the commit (i.e. why it was needed, what it intends to do etc). Referencing an issue is done by adding a hash sign followed by the issue number in the commit message.
• Milestones: It seems like you have just created milestones, and then kind of forgotten about them. Your MVP milestone isn't even finished. To be honest, this project is a bit too short for milestones to be really useful, but when you move on to the larger projects (e.g. MVK), make sure to make good use of milestones and deadlines!
• Have an up-to-date description: This is your komplettering, and it is actually quite important. For example, if you are making some awesome open source software, and your description is bollocks, then it is very unlikely that anyone will ever have a look at it. Remember, the README is the first impression a visitor gets of the project. Even if it is a closed project, it's often the case that not all project members are totally aware of the project as a whole, so a good description could help get everyone on the same track.
• Testing: There is no evidence of testing, at all. Even if you don't resort to unit testing (which to some degree you should, honestly), there should be some kind of documented testing. This could be for example in the form of bug issues (you have one, in which I don't really agree that it is an actual bug).
• Some things that should not be in the repo: You have obviously used Intellij, and have some project files and stuff that shouldn't be in the repo. For example, the .idea and out directories (the latter containing compiled code) should not be included, and the noisy-bird.iml file should also be ignored. Google something along the lines of intellij gitignore and you should find some decent gitignores for intellij projects. You've also got that pesky .DS_store file in there, which is some Mac OSX thingy with directory info, which should also be ignored!

Stuff you did good

• Nice project structure: It is easy to find stuff in there. I especially like that you clearly separated assets from source code!
• Not using the default package: You have your source code in a package, very nice! This can be further expanded on with a proper package structure. It is common to prepend the reverse of the organization's domain name, so here se.kth.inda or something like that could be prepended. This will minimize the risk of import conflicts between projects that have the same package names, for example, se.kth.inda.code will not conflict with com.sun.code. Also, code could be named something more informative, but the main point is that you did use a package, so kudos!
• Overall good commit messages. You have some inconsistencies with past tense and present tense (should choose one), but these are minor and overall the commit messages are quite similar in structure.
• Divvying up the work: Judging by the commit history and repo statistics, your contributions to the project are very nearly equal. You also seem to have been working in tandem, as there are no long sprees of only one of you making commits. Well done!
• Nice end product: Your end product is quite nice. While it is missing bells and whistles such as sound, menus, restart on death etc, what is there is quite well polished and is working just fine.
• Good try at separating different functionalities: Although you haven't quite separated game logic from visuals (for example, the Game class knows about the View), you've divided up your project into a decent amount of coherent chunks. The next step would be to follow an actual design pattern, such as MVC. You can check out the example I made (see Slack) or just google around the web for different design patterns that may be suitable for games!

That's what I've got for you, fix your komplettering and you are all done!

When starting the game, a screen overlay should pop up. It should contain player high score (optional) and prompting the player to start the game.

thenewboston

Static bakground has been achieved by commit f881963 the problem now is to figure out how to make it move and repeat.

It will be easier to create the scrolling animation with a ground asset that matches the width of the background picture.

Description is very clear. The commit messages are also easy to understand.
Lot's of Milestones have been used. A very proper amount to be sure.
Issues have been labeled and used to a great extent which is very nice indeed.
Branches have been made continuously and then rebased into master giving a
somewhat straight branch structure in the network graph. Well done!

As of now the player in only hindered when touching the ground, the game should reset after crashing in to the ground or an obstacle

After losing, a screen overlay should pop up displaying number of points, high-score and a retry button.

This should be fairly straight forward since we have the y-value of the ground and the y-value of the character.

Your planning is looking good, but you should expand on the description of the project. Instead of saying what this is a derivative of (because then I have to go check what that original thing is), describe what the game is supposed to be like.

Clean-up