Frogger Game

[crealime]

Frogger Game

Demo |
Code base

The code is submitted in a dedicated feature branch.

Only code files are submitted.

Please, review.

[github-actions]

Hey!

Congratulations on your PR! 😎😎😎

Let's do some self-checks to fix most common issues and to make some improvements to the code before reviewers put their hands on the code.

Go through the requirements/most common mistakes listed/linked below and fix the code as appropriate.

If you have any questions to requirements/common mistakes feel free asking them here or in Students' chat.

When you genuinely believe you are done put a comment stating that you have completed self-checks and fixed code accordingly.

Also, be aware, that if you would silently ignore this recommendation, a mentor can think that you are still working on fixes. And your PR will not be reviewed. 😒

Frogger Arcade Game -- JS OO exercise check list

Relates to Object-Oriented JavaScript task.

Check-list - definition of done

• employ ES6 features like const, let etc. (with exclusion of ES6 class syntax)

• the code is very DRY

• Requirements re Constants:

  • all numbers like block dimensions, initial locations are defined as named constants (e.g. const STEP = 101;) as otherwise numbers scattered across code base look cryptic; named constants add semantic meaning and improve readability
  • every number that has a semantic purpose (like those listed above) should be defined as constants; think of how your code reads - the closer to plain English the better
  • there are core constants and derived constants
    (e.g. derived constant const FIELD_WIDTH = BLOCK_WIDTH * BLOCKS_NUMBER;)
  • arrays of constants are also constants
    (e.g. const INITIAL_POSITIONS = [1,2,3,4].map(rowNumber => rowNumber * BLOCK_HEIGHT);)
  • const objects help organizing and structure const data even better
    (e.g. const PLAYER_CONF = { initialPosition: {x: 1, y: 5}, sprite: '...', ...etc... };

• Requirements re OOP:

  • OO is implemented using JS prototype chain object model (not ES6 classes syntax)
  • classes do not refer to any global variables, like global variable player, which is an instance of Player class
    (referring to global constants and globals provided by the gaming platform like Resources is OK);
    Hint: pass Player instance as an argument to every enemy
  • Separation of Concerns principle is followed
    (e.g. update method does only rendering and doesn't contain any unrelated inline code; for example collision check is defined as a dedicated method and only called from inside update)
  • Nice To Have: properties common for some classes are generalized into a base class
    (e.g. there is Character base class, which is extended by Enemy and Player classes)
  • class extension is implemented using Subclass.prototype = Object.create(Superclass.prototype), not Subclass.prototype = new Superclass(params);; Helpful resource

• Most common mistakes

  • Make sure target = condition ? valueWhenConditionTrue : valueWhenConditionFalse is used instead of condition ? target = valueWhenConditionTrue : target = valueWhenConditionFalse; Conditional (ternary) operator

Universal recommendations:

• Give variables and functions meaningful names. Avoid generic names like item, element, key, object, array or their variations. Exception: helper functions that are specifically and intentionally designed to be multipurpose.
• Function names should start with a verb as they denote actions; variables are normally nouns; boolean variables/functions start with is, does, has etc; variable containing multiple entities and functions returning lists contain entity name in plural form.
• Have consistent code style and formatting. Employ Prettier to do all dirty work for you.
• Use common sense or seek for an advice whenever requirements look ambiguous or unclear.

Also take a note of the requirements above and follow them in all your future projects.

By the way, you may proceed to the next task before this one is reviewed and merged.

Sincerely yours,
Submissions Kottachecker 😺

[OleksiyRudenko]

@crealime pretty well done!

At times calculations look overcomplicated. Probably, operating with concepts of row and column (truly questionable as enemies do not jump across the columns) would make it simpler.
Pixels make sense only at image drawing phase and characters intersections.

Player and enemy collide when they are on the same row and player's x is within specific range based on enemy's x. Collision with gems can be done based solely on row/column match.

This code works. But as a peer developer I feel I gonna struggle with understanding and deducing a lot of maths involved.

Can we simplify it a bit?

[OleksiyRudenko]

What is this mysterious number - 530? As a peer developer I want to read and understand the code in order ro be able to contribute effectively.
This refers to this number and other numbers across the code that are not defined as constants.

[crealime]

Changed to WIDTH_CANVAS.

[OleksiyRudenko]

Consider dictionary pattern here (use appropriate domain-specific naming).

const valuesDictionary = {
  1: 'a',
  2: 'b',
  3: 'c',
  4: 'd',
}

const defaultValueKey = 4

valuesDictionary[2] || valuesDictionary[defaultValueKey]

valuesDictionary[999] || valuesDictionary[defaultValueKey]

You most likely may also re-use the dictionary in the other fragments of code.

[crealime]

Thank you! This is a good idea. Done.

[OleksiyRudenko]

As a peer developer I am tasked to add 5 more player levels.
Can we please have next state calculable based on current player level? I see the repetition pattern here.
See also comment on dictionary pattern below.

[crealime]

Done.

[OleksiyRudenko]

enemies part already says the variable contains many similar instances. Referring of data type is redundant and abbreviation (arr) makes it obscure anyway. There is a reason we do not write numY, numSpeed, strMessage, arrAllEnemies.

[crealime]

I understand. Fixed. And I change the functions creteEnemies and createStars so that they change the arrays allEnemies and allStars directly.

[OleksiyRudenko]

Can we calculate pixel y positions based on something more comprehensible, e.g. playfield row number? Add row offset, multiply by row height?

[crealime]

Done.

[OleksiyRudenko]

Also please before submitting your next task make your code editor do indents with 2 spaces, not tabs.
Tabs expand in different ways on different environments. 8 spaces indentation at times makes reading and following code structure a bit painful.

[crealime]

Thanks a lot for your review! Сode got really better. I think I redid everything you suggested. If I misunderstood something, please write to me.

[OleksiyRudenko]

@crealime great job!
Check the comments below and take these as a source of learning and inspiration.

[OleksiyRudenko]

Use maths more often whenever there is any correlation.

[OleksiyRudenko]

You may want to group constants per their common features.
e.g.

const FIELD = {
  rows: 5,
  cols: 6,
}

const FIELD_PIXEL_BASED_PROPS = {
  width: 530,
  height: 999,
}

const FIELD = {
  PIXEL_BASED: {
   TILE: {
      width: 50,
      height: 110,
   }
  },
  ROW: {
    count: 7,
    start: 5,
  },
  COL: {
    count: 8,
    start: WHATEVER * 5,
  },
}

const FIELD.PIXEL_BASED.DIMENSIONS = {
  width: FIELD.PIXEL_BASED.TILE.width * FIELD.COL.count,
  height: // .similar calcs
};

Look, how reads full path FIELD.PIXEL_BASED.width. Practically, you replace some underscores with dots, yet the constants definition has some logical structure.
The above is a quick example (so naming is not well elaborated) to give you some ideas and illustrate how we can leverage nested data to put data into some logical structure yet keeping things readable.

Also it might be more reasonable to have essential numbers in a constant object different from a constant object that contains calculated constants.

[Mifaresss]

The best frogger I've ever seen!