wsdt / flying_fishes Goto Github PK

Tidy up (make code more legible, comment method, make code more efficient etc.)

This should always be considered!

Maybe we should change the way we do dependency injections (e.g. context/activities not as class members to avoid memory leaks).

A library would be also interesting: https://android.jlelse.eu/fundamentals-of-dependency-injection-and-popular-libraries-in-android-c17cf48b5253

UI-Context in long living objects -> https://medium.freecodecamp.org/mastering-android-context-7055c8478a22 (see scenario 3 and following). That's our bug (see DrawableObj and DrawableLevel-member Context/Activity/DrawableSurfaces).

Maybe use sth. like this for levels/modes/worlds:

• LinkedHashMap (to keep order so we can get elem by pos and index) with indizes of class objs:
  --> .put(Level_1.class, /point obj or lvl obj uninitalized?/) or just an ArrayList with class objs?

Create a unique success-dialog with detailed information about:
-> how many fruits he has collected & missed
-> how many enemies he has killed & passed
-> show total amount of fruits
-> show link to shop, so player can fast jump to shop after reaching special amount of fruits needed to buy things
-> show highscore in a wonderful font
-> be creative, ive added a foto of how i could might look in another universe!

When fruit powers change certain level params (speed of player or enemies e.g.) then this effect remains on level restart, bc. we use it from RAM.

Create a SwipeView for LevelHierarchyActivity

We have a collissionMgr why do we have logic in Gameview?

ONLY IN AlphaV2_Branch. Master branch should work.

Just see last commit for changes, maybe you will find the bug.

CLOSED, bc. Branch deleted

Possible measures:

• Change position of all elements (player, enemies, bg layers, fruits, etc.) to a previous position (appr. 5 seconds a go or a variable number of seconds [e.g. different fruits can do this for a different amount of seconds) --> would be very cool!

• Or just restart level and keep highscore before user died. (not recommended)

Make a nicer UI (maybe user sth. from Amazing UI App) --> Cooler dialogues, Highscore Activity [senseless for AdventureMode, but we can use it later for SurvivalMode etc.]

Add Pause, Restart Button (maybe to ActionBar in GameViewActivity)

Initialized Var is non-static. So initialize gets executed for every instance (which isn't necessary bc. bitmaps are static).

Migrate all initialize() contents so that isInitialized() var can be static without problems. But keep initialze() non-static so we can implement it from DrawableObj.

When flying to top and then shooting or so the shooting site triggers the flying up action.

Solve GameObj-Animation issue (maybe comes along with #I1). So e.g. Happen Enemy animation is not so fast [maybe we can use loopCount param in draw())

• In WorldActivity we have now animations (e.g. by Backgroundlayers). By starting a level and going back to the WorldActivity the layers seem to be added one more time than before.
• E.g. if I added as BgLayer only 3 Flying Elements, I only want 3 elements and not on the back btn 6, then 9, then 12.
• No idea currently, I am tired.
• WorldActivity.class, WorldManager.class, World.class, World_Earth.class

Our Collision-Detections works absolutely fine, for smaller objects, because their collision-area, where pixels are getting proved is also small (ratio). But Barriers can be huge and their collision area too. So we need to create another Collision-Detetion for Barriers, to avoid huge performance looses.

Add another Collision-Detection Concept
in class CollisionMgr or by creating a new class

Create Barriers that can be activated in some levels. Those should either grow from absolute top/bottom position into the field or be placed within the game-view zone.

A collision with a Barrier means an instant Game-Over state.

Barriers should differ in look and behaviour (rotating, horicontal, vertical, with edges --> use tetris as example,
[ ]
[ ] [ ] [ ][ ]

or

[ ]
[ ] [ ] [ ] [ ]
[ ]

or
[ ] [ ] [ ] [ ]
[ ]
[ ]
[ ] [ ] [ ] [ ]

or
[ ]
[ ] [ ] [ ]
[ ]

but this will all be future content, for now we should implement the logic. A proper Design-Sheet is yet to be done. Until that, pure logic. Best case if CollisionManager is compatible --> means, we're using the same concept.
Otherwise we can also use the SVG-Path System, as alternative.

Avoid using Singletons, maybe change to Factory Pattern (if an alternative is needed):

• https://www.tutorialspoint.com/design_pattern/factory_pattern.htm
• https://testing.googleblog.com/2008/08/where-have-all-singletons-gone.html

1 Factory can consist of many classes with a similar lifetime (e.g. level-dependent, etc.) --> so group singleton-like classes into a factory which get's instantiated.

By collecting any fruit, you sometimes dont receive the fruit's specific power.

Classes: FruitPower, Fruit, all specializations of Fruitpowers

Edit: Bug has gone, but lets keep an eye

If #I4 is solved, animate other enemies or maybe also player (additionally to rotation)

Clean bullets after level restart (easy to solve, just no time now)

Provide either a full-level counter (1 - 100 f.e) or a World-based level counter (1 - 1, 1 - 2, ... 2 - 1)

We will be displaying our current Level in the LevelInformationDialog.class at the Top or if theres a better solution, place it anywhere.

Classes: depends on, Level.class, World.class, LevelInformationDialog.class...

Make XML Object for Level-Element in LevelHierarchyActivity. --> A nicer one than just the white box on the blue background or similar.

Should Player.class contain logic of Projectiles? (shooting, adding etc.)

Use Player Draw Procedure (with Hashmap for allowing also different angles) in all other GameObjs. Or if you have a more performant idea, please do that.

Craft GameAchievement Manager. So user can get achievements. --> We might to use Oauth for userContext (see comments in already existing dummy Manager).

Add default interface methods (also private?) to get rid of ugly getReward() and getShootFrequency etc. --> so properties easy to access.

Change App Icon (midmap) --> maybe use one for which we need no copyright

Solve Proguard issue when compiling Release-Apk. (Currently we have in build.gradle proguard and minifying disabled, so change this for solving that)

High probable solution: Add proguard rules (own file which is linked in gradle) to keep specific classes [recherche on internet] to get the correct rules)

We need to create a Design, "ON THE BASE" of what i've done.

• "On the base" because what ive done today isnt worth reading (meaning the coding part)

-> Clean Design
-> Viewable horizontal, move right to progress further
-> Get an Information-Dialog if user pressed a button/level
-> Create an End-port, which leads to another world
-> limit the GUI-System, player is only allowed to get to the next level if he managed to pass the one before
-> if he has a special amount of points or all levels (dont know) access to next world will be gained