Create a Google Document or other document, containing equipment.

This equipment will give different buffs/debuffs to different stats. It would be helpful if you included a short explanation of how powerful the equipment is to help balancing it later in development, but it is not necessary.

Example equipment:

Pocket Calculator
Accessory
Magic Attack:-5
Magic Defense:+30
A simple early game accessory. It plays to the strengths of the Math class, giving them extra survivability.

Notebook
Weapon
Physical Attack:+30
A simple early game weapon. It increases physical attack, because you hit things with it.

Some kind of PositionFollow() component that tracks a specific Position component and is moved during the player processor.

The stat calculation and damage formula have been finalized, and the skills/spells are almost done being designed. However, there is still a lot of discussion to do relating to the battle system and balancing.

Random encounters

For instance, how should "random" encounters be initiated? Should they happen at random (like Final Fantasy IV), randomly within certain areas (like older Pokemon games), by running into enemies on the field (like Paper Mario, Earthbound), or should all encounters be scripted?

Resources

On another note, how much do we want to drain the player's resources? (HP, TP, etc) Basically, how much do they have to do in between healing/restorative centres. For example, in Pokemon, there is a Pokemon Center in every area that allows you to heal your party fully. This makes things less draining. In contrast, in FFIV, towns have healing areas, but they are few and far between, forcing you to think about your resources.

Length

How long do we want battles to be? Both short and long battles have their merits. In D&D 5e, for instance, battles don't usually take more than 2-3 turns, unless you are fighting a boss. In Deltarune, most battles can be solved in 1-2 turns, except for bosses, which usually drag on to at least 5 turns. Nobody likes long random encounters though, so ideally the battle system should be balanced for short encounters and long bosses.

Enemies on the map should be controlled by a MapEnemy component. When a player gets close, said enemy should chase the player. Detect contact with the player for when the battle system is completed.

Later, another good idea is to put said MapEnemys in the map files, with a format something like X|Y|EnemyName,EnemyName,...|enemyOnMap.png

We need a way to organize the phases of our work. As @gaioc had said, "We should also have a stable branch that artists/designers/etc can work on without worrying about bugs".

As such I propose that we use the following branches:
Development - Anything that is in active development and not completed yet
Stable - Anything that works and has somewhat been bug-tested, but may still be buggy.
Release - Final release. Most stable branch where everything should work most if not all the time.

Mostly status effects. Examples:
Redirection, shielding, crit chances, etc.
Need to be implemented.

Technically complete (see Battle!.ogg), but I would like to remaster it with the Lil' Sness soundfont I found. Not a fan of default instruments.

Not happening for a while. Should include:

Phase 1:

• Evil theme
• Fragments of other boss themes
  Phase 2:
• Evil theme
• Main theme

Basically, when a player enters a cutscene trigger, a Dialog starts, determined by an NPCBrain. That way, cutscenes can be set up to only trigger once, or when certain conditions are met, or both.

Should have a process() or decide() (or whatever other name makes sense) method that takes in arguments:

• Players and their status
• Other Enemies and their status
• Own status
• Own abilities
• Turn number (mostly for bosses, but could be used for enemies that explode after a certain number of turns)

Other enemy AI would inherit from it. Example: a basic enemy AI could look something like this:

1. If I have a healing ability and one or more enemies are in need of healing then use it, otherwise
2. If I have any other special ability, then use it X% of the time. Otherwise,
3. Attack normally.

AI designed like this would allow for new enemies to be fairly easily created.

Entities that contain an NPCBrain object and a Position will also contain this component (we'll call it a NPCCollider or something).

Player should not be able to move through the locations of such entities, and when they hold the walking direction towards such NPCs and press "confirm", it should trigger the interact() method of their NPCBrain. Said method also needs to be updated to freeze some other tasks like moving the player (as described in #3).

An important thing to remember is that this system extends to more than just NPCs, as the name would suggest, but anything interactable. (anything with an NPCBrain component deciding its behaviour)

Will have to wait until bosses are finalized.

Base class that defines most battle-related things (UI, actions).
Should have an Update() function that returns either -1 (still in progress), -2 (next sub-turn), -3 (end battle), or a string index for the Dict of BattleActions determining what should happen next.

For example, a menu with options could inherit from this class, returning the chosen string index.

Multiple possible directions here. Because people are going to be playing it on replit (I assume) and not natively on their machines, saving game progress becomes a hurdle. It's not hard to pickle and save the player's position and game data, but how do we make sure that data is saved in a user-friendly way? Older games solved this with a password system - we could try something like that. However, those ran under the assumption that the saved data is fairly small - this is definitely not the case. We could try to direct the user towards downloading their data through the files tab, but that's not intuitive, especially because to then load the save, they would have to drop it in the files tab. I'm genuinely at a loss for what to do here. There is one remaining solution, but it's a bit of a nuclear option: Recently I created a working backend in Flask that can handle accounts, logging in, secure passwords, etcetera. I can create a backend in Flask that gets queried by the game. This way, you can create an account and your progress will be saved. This also opens up a lot of other possibilities like achievements, communication with friends, and more. This would be a pretty large undertaking, but I think it could work.

Should have:

• HP, Max HP, other stats
• A system to handle unique buffs/debuffs, potentially with a turn limit tied to them
  • For now, just stat buffs and debuffs, but later we will need a poison/other DoT handler. That will probably fall under the Battle Handler though, as it would activate at the end of every round.

Players and Enemies in battle can optionally inherit from this class if we need additional information/functions.

Will have to wait until bosses are finalized.

As the title says. I believe it favors for programmers and designers to move their work here. Github provides a significantly superior way to talk about code rather than having to deal with Google's comment system.

How should TP scale with level?

Linear scaling makes sense, skills shouldn’t be able to be used an exponential amount.

At the same time, we don’t want a huge spike in tp at lower levels. For example, if we set tp to 3*level, the first few levels will increase tp by a huge relative amount.

I propose something like TP = 15 + 5*level. This way, the spike isn’t huge, and you get less relatively at higher levels.

Simply, disallow movement to tiles that have a walkable value of False.

Will need to be designed. Also, we will have to decide when the title screen shows.

Right now, the flow is:

Login Screen -> File Select -> Game

I believe that we could make the Login Screen a part of the title screen.

Should only need one theme. High-energy

Currently, NPCs have to be added in code. The proposed change would be to change the Activate and Deactivate functions of the map screen to also initialize NPCs at their proper places with the required data. This should not be too hard.

Simply, the Activate() function of the Dialog object in dialog.py should disable all instances of the PlayerMove component, and hitting a -2 code (end of dialog box) should reactivate them.

Should play off of #57 , if not be the same.

Will have to wait until bosses are finalized.

Played when a battle is won. Any suggestions are welcome.

Open to suggestion

Currently, the TileMap component holds some raw string data with a list of loading zones.

This proposed change would first of all, create a LoadingZone class to hold them, and change the readMapData function to implement said class.

Secondly, it would modify the PlayerMove class in some way to allow switching maps using these loading zones.

For this, we either load all of the maps beforehand and activate/deactivate them when necessary, or we load them on the fly, removing the old TileMap entity and adding the new one.

Bonus: add a fade to black transition while loading. You will need to freeze player movement while this is happening.

Create folder audio, with file audio.py.

audio.py should have functions to handle both:

• Music: one track should be able to play at a time. Should have PlayMusic(<track>) and StopMusic().
• Sound effects: SFX should be more spontaneous, and should have at least 2-3 channels reserved. Should have PlaySound(<audio>) and StopSound().
• There should also be a StopAll() function that stops both.
• Music will pull from assets/audio/music, and assets/audio/sfx.

Should be catchy and simple, so that it can be used as a motif across multiple tracks, like the title theme and some boss battles.

Create a system to draw the (640x480) background, and the enemy sprites on top. The specifics are on the UI google doc, but here is (more or less) how it should look:

(small amount of space for player health)
   E     E     E

(large space for player UI)

As planned, Area 1 will take the player through levels 1-4, with them finishing around level 4 after the miniboss and 5 after the boss. The player will fight in approximately 5 encounters.

All of the game engine features required to continue have been implemented to a reasonable degree. ( #33 #35 #36 #38 )

Development can start as soon as planning is finished. We need:

1. A theme for the problem the area faces. (ideally taken from the feedback form)
2. A theme for the area itself. The area itself shouldn't be a total reflection of the problem: it should be its own place, tainted or plagued by the problem.
3. A place/way to find the keepsake necessary to have either Science or History join the party (depending on class choice at the start)
4. Enemy design. This includes:
   a. Appearance/theme
   b. Behaviour and stats in battle
5. Miniboss design. This includes:
   a. Appearance/theme
   b. Reason for fighting
   c. Behaviour and stats in battle
6. Boss design. This includes:
   a. Appearance/theme
   b. Behaviour and stats in battle
7. If possible, the boss should make use of one or more game mechanics that are introduced to the player beforehand, either through fighting normal enemies or the miniboss.

Feel free to discuss below.

To recap, there are currently multiple different stat customization options available. Anything in italic will be a suggestion to add onto the current systems.

• Effort Values: gain one per level, can add to stats. Caps out at 8 per stat. This means that by the end, each character will have 20 EVs from level-up. (potentially planned)Characters can also join clubs. Doing so would give them one EV and a spell relating to that club. Suggestion: create a place where the player can reset their effort points later in the game.
• Equipment: found through exploration. Can be equipped to anyone. There are three different types of equipment: weapons, armour, and accessories. Each character has one weapon slot, one armour slot, and (two, once I code it, for now one) accessory slots.
• Enchantment: Equipment can be "enchanted", to increase its stats. The plan is to have a "Forge" in the hub area where the player can use enchantment recipes found through exploration to enchant their equipment. Suggestion: Enchanting equipment requires "crystals", resources earned through some method (battles? side quests? boss battles?). Enchanting an already enchanted item requires more and more crystals(3x the previous amount), to encourage enchanting multiple gear items. It should also be possible to "disenchant" an item, refunding all of the crystals used. Stronger enchantments could require more crystals.

Right now, battles don't really end in a Game Over. This would require the creation of a Game Over screen, with the following options:

(maybe) Retry Battle
Back to Title Screen (we don't have one yet)
Quit Game

Currently, the npc system is mostly implemented (in dialog.py). The logical next step is to be able to codify this behaviour in text files.

This would entail:

Finishing the GiveItem, TakeItem, and other dialog functions

Creating a function to read in text files and return NPC objects

Already done.

[Enhancement]

The creation of a system to create new maps, and new tile types.

This would entail:

Creating a file, tiles.txt in the mapScreen folder

This file could then be read in by a function which would return a dict of Tile objects.
The format of the file would be as follows:

F
floor.png
True

W
wall.png
False

Each entry would have a one character identifier, a file name, and a bool determining collisions. (True is walkable, False is not)

Creating a folder, maps, in the mapScreen folder.

This folder would hold multiple files that would have the following format.

8 8

WWFWWWWW
WFFFFFFW
WFFFFFFW
WFFFFFFW
WFFFFFFW
WFFFFFFW
WFFFFFFW
WWFWWWWW

4 4 npc1

2 0 loadingzone1
2 7 loadingzone2

Bonus: create a tool which allows level designers to quickly and easily create files in this format (map editor)

Given player/enemy information, create a working UI given the specifications on the UI google doc. This should ideally come later than other things like enemy rendering and the actual functions of the battle system.

A class (component) that will keep track of the state of a battle. Needs a constructor that takes in players, enemies, and (as optional arguments that have defaults) music, and whether the battle is escapable. Should keep track of:

• Turns (players, enemies, sub-turns)
  • Keeps track of whether it's the players' or the enemies' turn
  • Keeps track of whose individual turn it is within that
• Battle Status (player victory, enemy victory, escaped)
• Animations/Text (make sure things are happening in sequence)
• More, I just can't think of it rn

I feel like our current priority should be fully completing the map screen. After that, we should probably finish up the NPC/interactable system, and then we can move on to the battle system, because that still requires a good amount of discussion.

Thoughts?

This means 2 things:

1. Make it work with interactive elements such as option selects
2. Make it work with visuals (gray out text, etc.)

32x32 resolution pixel art
Bird's-eye view

Modeled after the hallway floor, walls, and lockers at CHCI

• \LoadMap MapName X Y: loads map MapName and places the player at coords X Y.
• \Wait time: wait for time frames.
• \MoveNPC npcName X Y speed: starts moving npc npcName towards the destination at speed speed.

Comments can add more

Will have to wait until bosses are finalized.

Many RPGs include some form of active action or timed hits to complement the slow decision-making gameplay. Some examples:

https://www.youtube.com/watch?v=AoImTShEtZE

Need to brainstorm ideas for how to implement this into the scripting language.