erodozer / ff1-battle-system Goto Github PK

Animations should be capable of being drawn on screen as evoked by a scripting, with parameters defining either pixel position on the screen to draw it or in relation to another sprite.

Scripts should be able to evoke battles

Battles can have defined backgrounds or default to the background of the terrain the party's player is standing on.

As the title says, for some reason whenever you head back to the world scene, the memory usage goes up instead of using the memory already reserved for the map.

Even if we have a nice amount of contents and maps thrown together, it's nothing of an rpg without a story. We need to think of an overall plot and then create dialog and events to tie it all together.

Items need to have capable functions that can be executed in menus and in battle. This would be easiest performed by having items with a spell parameter for use in menu and another one for battle.

This would also mean spells need to be altered to allow for constant values on effects, so something like a potion will only ever cure 50 hp.

Saving and Loading has already been implemented code wise and even tested using JUnit. Sadly, it has not found its way into the game yet. All that really needs to be done is call the save method in the engine, but because in FF1 saves only occured in Inns and Tents, and items nor inns have been implemented yet, this has not been made accessible.

Fastest way to get this task done is to implement an Inn NPC. It'll be sloppy, but good enough until the full scripting logic has been implemented.

Alternative is just have F5 do a quick save state and F6 load state for testing purposes.

Screen hue should be able of being defined for atmospheric effects without having to use mapping techniques involving a large image with hue, and shadows all being drawn in.

Add a simple pathfinding system using Dijkstra's algorithm for npcs to use.

When called it should generate the optimum path from a passability adjacency matrix from tiles and npcs. Only time it should reupdate before the npc reaches the end of their path is if going to the next tile in the optimum path it is suddenly blocked (usually caused by another npc stopping on the path) but make sure to wait a tick first in case the other npc would move off in that time before recalculating the optimum path.

Optimum path should be saved into a list, popping each location after moving. If recalcuating occurs, just take the first and last index and run dijkstra's from that start to end point.

Allow maps to be effected by in game time. This can work in combination with complex lighting and screen hue changing. For example, a parallel event can be running to be checking system time, and if the system time passes a certain point, lights can be turned on in the map.

The world clock will always be running, but with a simple true/false variable in the map.ini, you can have it so the map is effected by the system or not.

Allow maps to consist of multiple layers of tiles. Amount of tile layers should be unlimited. Because this can lead to massive overhead drawing each layer for render, allow layers to be divided into 2 types, below and overhead. Render the two types into two buffers,

rendered in the order of
background fill < below < npc < overhead

Buffered should be generated on instantiation then only referenced.

Passibility should also be merged into a single array to help collision efficiency
below < overhead < map defined passibility

Scripting should be capable of performing simple sprite/npc manipulation on the map. NPCs should be capable of being moved in a predefined path using a script. Things like turning in place and setting the frame of animation are additional functions.

Have a tab for editing Items. Items should be able to link with spells if they're usable, or they can be set as equipment

Spells and Weapons have animations in battle when the player uses them. Animations for all the spells and weapons need to be drawn up using the .anim specifications

Add ability to undo and redo changes when editing the map. History should be stored across all layers and should store only areas that were changed per step instead of the entire buffer.

Have a tab for making and configuring jobs. Jobs should have 3 different sub tabs, one for starting stats and equippable types, one for stat growth per level, and one for spell list.

Have a new tab for editing and making animations.

The sprite creator has absolutely no content as of now. Some images that'd be great as layers should be designed so people can stack and create more npcs for the game.

I already have written a complex animation class/system in python for UlDunAd. Adapt those animation files so they work with JFFBS's Sprite class. Add things like anchoring to sprites or to screen for relative positioning.

Animations should extend Sprite. A ticker is needed to keep track which frame (defined by each line) the animation is on and what needs to be drawn. Only one sprite sheet is allowed.

Example of a .anim file from UlDunAd

9
parent
1,.5,.5,1,1,-45
2,.5,.5,1,1,-45
3,.5,.5,1,1,-45
4,.5,.5,1,1,-45
5,.5,.5,1,1,-45
6,.5,.5,1,1,-45
7,.5,.5,1,1,-45
8,.5,.5,1,1,-45
9,.5,.5,1,1,-45

Line 1 - number of frames defined in the spritesheet of same name
Line 2 - anchoring in battle (screen, parent = actor executing command, and target = actor being attacked)
Line n+2 to eof - Line of frame animation

Frame animation is defined as
1 - sprite sheet frame cell

(these values are presented as percentages, allow either percentage relativity or specific pixel relativity)
2 - x position
3 - y position
4 - width
5 - height

6 - angle as present in degrees

Multiple frames of can be drawn per frame of animation, each one should be defined by dividing with a "|"

There's currently only one tileset, and it's a rip from FF1. There should be some more custom tilesets for the game.

Ones that'd be good would be
Everfree Forest
Ponyville buildings
Canterlot buildings
Underground tunnels (Diamond Dogs)

Scripting should be able to move the camera object around, allowing things such as free-moving and lock to npc. Since the party uses an NPC to display itself to screen, there should be a specific global tag used to refer to the party's representation on maps for functions to use.

Tile sets should support something that's commonly referred to in the RPG Maker community as autotiles.

Auto tiles look like one tile in a sprite sheet, and you paint with it as if it's one tile, but it's auto calculations which tiles to place depending on their layout. Autotiles are for placement of things like repeating terrain, such as water, grass, and trees, that can have corners and edges.

Obvious in its title. LibGDX is the bread and butter to my games and frameworks nowadays. It's much more stable and predictable, so it's a good idea to rework it for that. Additionally, a lot of this code is just a plain old mess because of how rushed it was in production for a class a few years ago. There's plenty of time to rework it, as well as the editor, that it may just be worth the hassle to get back into this project.

Allow passability overriding on the map so a map can have areas with their own defined passability instead of duplicating tiles on the tileset and having confusing problems from doing that. This could allow someone to make a map with a tileset, then throw in a secret invisible passage or something without having to extend a tileset with their own content that would make it non-standard.

Instead of having to create multiple maps for multiple rooms, allow zoning of maps.
Zoning feature these things

• Only the zone that your party is currently in is being drawn and updated
• if the camera extends outside the zone borders it will draw the clear color instead of more of the map
• only loaded as your party enters them
• only the previous zone is saved in memory for fast returning
• rectangular in shape
• specified using the top left tile coordinate and bottom right tile coordinate

Need to extend the system to allow for further out of party management. This way you can have more than 4 people system wise, and still be able to work with them.

Order scene should allow for scrolling but only show 4 members at a time, if you select someone to switch they should be displayed at the top in a small window if they're not in the current 4 being shown.

In the main menu, it should show the 4 on your team right now, but you can scroll down to show more. Members not in your party will be shown with a darker blue or black background.

Only the first four members in your party index wise will be in your battle squad.

During the attacking and message phase, all animations for some reason are accelerated quite a bit. Reason why needs to be investigated.

Allow particle effects on screen for animations and other cool things

Tiles should be able to define specific sides that they can be stepped through.

Have a tab for editing spells. Spells should be able to have all their numbers configurable as well as what animation they use.

As the project gets larger with more content, there's possibility of wanting to overlap names, which is the current form of identification. By having an SQLite Database, which is easy to manage and an open file type, there would still be the openness desired for the project while at the same time making things a little bit easier to manage than a whole bunch of files.

The game engine is missing a key feature, and that's sounds other than music. The sound system should allow for multiple sounds to be playing at once and allow specifying of looping, looping a set number of times, and caching of sounds so it doesn't have to load the file and create and object every time. The sound system should load in .wav, and it should be capable of being used for battle sound effects, transition sound effects, and ambient sounds on maps.

A standard markup should be designed for the scripting language to be used with the engine. Java should be able to parse it as a text file, lines of code ending with a defined symbol to make things easier.

Each function added should be recorded in the wiki with a description of what it does and what parameters it takes in what format.

Additionally, when adding the code to parse the function, be sure to Java Doc the specific method for parsing the function. Each type of function to be parsed will have a method with the parser detecting which method to call while running through the script at load time.

JSON files are just overall more flexible and useful for a project like this.

Easy to parse, easy to edit, predictable, and can easily be managed using something like Gson or LibGDX's Json parser.

Since mdp is being implemented into maps and tilesets, a parallel effort needs to be made to have the editor capable of editing these things as well, so the editor does not break the game.

Add some more things to SFont like incorporating the word wrapping and cropping into the class itself.

Scripts should be able to evoke a shop scene

Shop evocation should start with the Shop keeper's pic, the shop title, then a list of items for sale

Something like this

changeScene Shop:
keeper -> "derpy.png"
title -> "Muffin Shop"
items -> "muffin", "mufin", "mufn!", "le muff";

Basic OpenGL rendering for the sprite, window, and font classes.

A global parameter should define whether or not to use OpenGL for rendering. If OGL is enabled, have the paint function in the class pass to the OpenGL drawing function instead to perform the graphics and blitting.

There shouldn't be anything too complex, just allow sprites to be rendered to planes to allow for Hardware Acceleration. Shaders are not planned, nor is allowing 3d objects to be rendered.

Maps should be capable of either having a solid clear color or have a parallax background.

Parallax backgrounds should be capable of having scroll speed defined in relation to the character as well as scroll speed that's automatic.

Something like this may even make complex map creation easier, with a person only needing 3 types of tiles (passable, overlay, and impassible) to map with. While this isn't recommended by me, it's another way to do it, and also practically matches how the old map system was like.

Some clever techniques could also involve a map that's actually only 640x480 in resolution, but has 10 frames of animation which can be drawn by having the image be 640x4800 with an automatic scroll speed of y = 480. In preference I'd say just have a static parallax with events that run parallel with scripting that performs animation in the spots on the map that you want animated.