CPSC 4160/6160: �Milestone 1 Presentation�

Grace Gattman

CPSC 4160

Game description

Name title:

Mage Potioneer

​

Genre:

Mage Potioneer is a casual puzzle and resource management game.

​

The player navigates the game through two main game screens: a top-down open space to collect a variety of ingredients, and a potion-making interface where the collected ingredients can be combined in a variety of ways to create many different potions.

​

Game description

Game Objectives:

​

The player is a mage who wants to open a potion shop, but wants to make sure they know how to make every kind of potion before doing so. As such, they explore the wilderness near their home to collect materials to test different ingredient combinations.

Game description

Game Objectives:

​

Each playthrough, the map for player exploration has randomized ingredient placements. Ingredients are not limited to spawn in specific areas of the map, so players are encouraged to explore as much as possible to gather a variety of ingredients.

​

A timer at the top of the screen will display the amount of time left in the collection mode, with the starting time being 30 seconds. This time limit decreases as player progression increases, with the fourth and final level having a time limit of 15 seconds.

​

The amount of total potions available for creation is 16, with 4 made per level, not counting the bonus potions that grant power-ups for creating every potion for a level.

Game information

Skill rating: 8+ year-olds.

​

Younger players need to be able to explore in a time limit, and think creatively to combine ingredients in new ways.

​

This is not a combat or action-focused game, so players will tend to be less interested those topics.

​

Audience: All above 8 years old interested in non-combat focused games.

Game references

Color palette

Color palette

Entities – Player character

1. Main character
1. The mage traverses the open area quickly to try to gather as many ingredients as possible.
2. The mage’s appearance is meant to fit the cute, casual nature of the game! I would have opted for a more gender neutral character, but I think this was the best option stylistically available.
3. Arrow key inputs will be used to determine the player movement direction, with the idle for the last input direction used when no input is given.

​

Entities - Items

1. Entities
1. Ingredients: stationary, same item typically grouped in similar area; Potions: stationary, in potion “library” in mixing interface
2. Appearance examples shown
3. Ingredients: Randomly scattered around the collection map, collision detection with player to determine if player picks it up; Potions: created through mixing interface

​

Game mechanics

• Collection: The core gameplay of "Magic Potioneer” revolves around item collection and unique combination of those items.

​

• Run: Players can make their mage move with the arrow keys. Colliding with an ingredient will add it to the player inventory, which can be reviewed during the mixing phase.

​

• Potion Mixing: The game features a potion-making screen that displays after each day’s collection phase. This screen has several components:
• Inventory: Shows total ingredients collected for this level, such as “7x Eggs” with corresponding icon
• Potion Storage: Shows all discovered potions for this level and the ingredient combination used to obtain each one
• Potion Discovery: Newly discovered potions display the potion icon and name in the middle of the screen before adding it to the potion storage (repeat potions not displayed in this way)

Character Control

1. Technical description:
1. How are you planning to control the character?
1. The character will be controlled with the arrow keys, for which key detection will be used.
2. Are you planning to use a fancy algorithm to control the character’s speed?
• No; the character speed will be a single setting that increases by a static amount with the Level 1 reward power-up.
3. How large do you intend to make the explorable space?
• The explorable space tends to be on a 1600x1600 grid, with the final level being adjusted to be more confined to better fit a higher difficulty (more obstacles in a smaller space with a smaller amount of time).

Effects

1. Technical description:
1. What effects will be implemented?
1. Glow above player when ingredient gained to confirm collection, see right ->
2. Color-coordinated magical FX when creating potion depending on specific potion (see incredible free pixel FX below!)
2. What will the implementation look like?
• The animation cycle for each effect will be triggered after a particular game event.

Collision Detection

Think technically what modules you will need to create your game.

1. Technical description:
1. How are you planning to control collision?
1. If the distance between a sprite and the player is within a certain threshold, collide_rect will be called on the rect objects of that sprite and the player. This prevents collide_rect from being called on ingredient sprites that are far from the player’s location.
2. The “Alive” sprite attribute will be used to control which sprites are blitted to the screen each frame.

​

Physics/Dev Plan

Think technically what modules you will need to create your game.

1. Technical description:
1. What kind of physics are you planning on implementing?
1. I am planning on implementing very little physics in order to keep the gameplay simple and straightforward. Rather than a sprint function, player movement will have a power-up boost after Level 1 to make movement feel more fluid and rewarding.
2. What does your development plan look like?
• After sketching out the backgrounds for the collection and potion making screens, base implementation of the player movement and ingredient collection was my first priority.
• Secondary is development of the potion making screen, which was highly reliant on FX implementation. I started out with a single potion, then expanded the possibilities. For cohesion and clarity, I limited the displayed potions and ingredients to be level-specific.

Software architecture

Software architecture

Collision detection and user input will be handled in overall game loop.

If statements based on game phase will handle what is printed to the screen and what player actions are considered, ex.

• Collection phase will handle arrow key input for player movement, whereas mixing phase will do nothing with those inputs
• Mixing phase will handle clicks on specific screen sections for ingredient selection, whereas collection phase will do nothing with those inputs

​

The transition from collection phase to mixing phase is automatic for each level, and the mixing phase for level 1 progresses to the collection phase for level 2 (for example) with a player-input click on the final mixing screen overlay.

Timeline

1. How are you planning to develop this game?
• Drafts for interfaces done by October 21st
• Backgrounds for both phases done by October 28th
• Player movement, ingredient placement, and collision handling in collection phase done by November 4th
• Base mixing menu done by November 11th
• Potion mixing implementation done by November 18th
• FX, inventory consistency, and any additional fixes done by November 20th

(Dates subject to change based on progress and expected progress per milestone)

• What modules are going to be a priority?
• As shown, I am prioritizing backgrounds and building the program from there.
• What module will be difficult to achieve?
• I think keeping the ingredient inventory consistent will be difficult to achieve across phases.
• What modules will be developed first?
• The sub-modules of the Collection phase will be developed first.