Let's take a look at one of the best classic games!
(https://www.youtube.com/watch?v=ia8bhFoqkVE "Super Mario Bros Gameplay") (Watch from 0:00 - 1:00)
If you already understand the basics of how Super Mario works, feel free to skip to the prompt!
Originally made for the NES, these days many of these simple side-scrolling games can be made in our own web browser. Given a brief demo of what can be done in the game, design a similar Super Mario game using the web browser.
Let's say that any player is able to save and pick up where they left off even after closing the browser. Couple of things to consider:
-
We want to create properties for important objects in our game. What would these properties be, and how would they possibly interact/overlap?
-
Basic function design. On a high level (don't actually code out these functions) what would be some functions we need, and what would they do?
-
Database design. Although this is not your typical CRUD app, what kind of tables would we need for our player to be able to save and pick up where they left off?
We're going to group the design of the game into three categories for today:
- Properties
- Functionality
- Database Schema
Now let's go over what each one could look like. Reference this for the schemas: https://docs.google.com/document/d/1t920UMPhfSka0w2XwzLbA-zqmfBk4NIlYfP1NBvW0L4/edit?usp=sharing
We should start by naming our important "objects" in our game. Bigger objects that we would likely want to consider:
- Player
- Enemies
- Mario (Wait, isn't he our player?)
- Blocks
- Items
- Fireball
- Level
Questions to address:
Why differentiate our Player from our Mario?
- Our Player object will deal with things related to our game state, where Mario will be our avatar doing all the action. This distinction can come in handy if we ever try and expand to multiple player games with many Marios.
What are Blocks and Items?
- A block will be anything brick that Mario can hit from underneath. The block can either break, or give and item, or be hit multiple times, and we need a way to set these properties. Items that come out of these blocks will have their own set of properties, such as what the type is (star, fire plant, coin, etc.).
What goes on in our Level Object?
- The Level Object, on a very high level, will deal with things like the timer and other portals to other levels (kind of like a tree or linked list). Level 1 should hold a reference to level 2, 2 to 3, and so on (this can be done differently, but this is one way to get sequential level loading). If we want to get even deeper, certain levels hold pipes to other areas, and we want to hold references to these as well.
Enemies?
- We can use a type property to differentiate unique enemies from each other. Goombas die from getting jumped on once, where Koopas do not. This itself can be made into a property.
Why make a specific Fireball?
- The fireball object, although very specific, is very separate from any of our other objects so far. It is a projectile that can hit enemies and defeat them, but the fireball itself cannot "lose lives". This gives room for a separate object with extra properties such as speed of the projectile and when the projectile dissipates.
After thinking about all the possible interactions and functionality we have in just this one level, this suddenly becomes a long list. We can break it down into a couple main functions per "Object".
List of possible functions can be found in the link above.
Here are some main functions that we would want to consider:
- Losing lives: Our game need a way to determine if we lost a life and possibly lost the game.
- Winning the level: Once Mario reaches the end of our level, we need a function to progress the game further and increment our score.
- Updating our score: Going through the game and collecting items should increase our score.
- Getting an item: When Mario makes contact with an item, a function should be made to give him the appropriate perk.
- General movement: A function should be made to correlate input with our avatar moving and jumping on the screen.
- Getting the next level: This may go with our "winning the level" function, but a function should be made to load the next level in our game once conditions are met
- Updating the time: In our User Interface, there is a timer giving us a limit to how long we can spend on a level. We need a way to update this in real time.
There are many other functional possibilities that can be made here, but these are just a few highlights.
In terms of simple save data, we would want to make two main data tables, one for our Players and one for our Levels. Let's assume that the rest of our game data is provided for us elsewhere, and is available upon loading.
Storing Players
- We want a way to keep our unique players stored in our database, so that when they log back into our game, we can fetch the correct data. This will have a relation to a Level, which will help us load the correct level.
Storing Levels
- We can fetch a Player's current Level from the log in, and then prompt to load that level.
Now there are many more things that a simple game like Mario will end up having. The main focus here is to be able to divide up the different areas or "objects" in our game and decide which would be the most appropriate area to assign our logic.