-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactored code and created separate classes for Ball, Brick and Bat #20
base: master
Are you sure you want to change the base?
Conversation
- There were lots of unused variables in game.py which were decalred in almost every method of BallAndBrick class without being used
- The class handles movement, drawing and collisions - Having a seperate class for the ball will allow for having multiple balls at once if needed
- made a new class called Bat which encapsulates the scroller functionality. It acts as a bat - It can be moved, it handles drawing and clamps its position inside the screen
- as of now only encapsulates static brick functionality, has no collision checks and acts as a rectangle with draw method
- added is_lost, set_position - also changed bounce_against
- gameLoop has been modified - states are now defined in an enum - balls are now stored in an array this will be helpful if there are multiple balls at the same time in future for eg: with powerups - collision checking and State management logic has changed slightly:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flake8 fixes are better left for a different PR, you could open another PR with these.
Reviewed 49eada6, not tested. |
The flake8 fixes are mostly of the code that is committed in this PR |
I'm saying open a different PR for it, this PR is about refactoring and not flake8 fixes. |
- vw vh get x and y relative to viewport dimensions
- as state was a constant, so for convention made it in all caps
Can you please explain what you mean here, because it is working fine with me |
Black canvas on Sugargame based activities can have a number of causes, and I've had a quick look at master and don't find the obvious causes. That it is reproducible for one person and not another is common, because it has to do with a race condition. You can both help push this forward by answering a few questions;
Next coding level diagnosis may be to compare the code against the Sugargame test activity. During development of Sugargame we found there were several ways in which it could fail to start. |
From the activity ring.
Yes.
No it doesn't.
Haven't done any comparisons yet but will as soon as I can. |
From the terminal through the sugar-activity3 . command
Yes
No I will also look into the sugargame test activity for diagnosis |
Okay, we have seen difference in behaviour like this when using sugar-activity3 directly, because there are missing environment variables and process partners. When testing for black or blank canvas, please also test with the Sugar activity ring and sugar-activity3 separately. |
Hi @chimosky and @sourabhaa please review, This PR refactors and restructures the code for this activity. I was trying to implement the powerups but as it turned out it would've been very difficult to do so with the existing code structure. The ball was coded in as a single variable, its velocity and states as well. also the code had redundant variables and many variables were being redeclared every function call which made the entire process hectic.
Thus, I ended up refactoring the code in a manner where implementing the powerups will be easier. I will be having a separate PR for powerups sometime later this month as I will be working on classify-cats now.