webalorn / robots Goto Github PK

Upcoming features

• Door tiles
• Two robots that can throw portals
• Wall that can, or can't, receive a robot's portal on one of their sides (only one)
• Tile that only let pass projectiles

Suggestions:

• Lasers and receptors
• Tiles that change robot's direction
• "Tranpolines" (change robot direction too ; Difference ?)

• Test if there is a next level
• Get the next level of a level
• Load next level from the game

• Load elements in background
• Init the scene before it disseapers
• add the loading screen before removing old scene

Create differents sprites for all tiles with differents states

• Portal
• Space
• Buttons

• Add end tiles
• Select a robot, or "any_robot"
• Show wich robot is selected

Processor must compute, with a robot id and a direction, all movments

• Must be stoped by walls

• Must be lost when enter space

• Must be destroyed when loop

• Compute mouvment

• Return mouvments

• Move robot in UI

• General properties editor with orientation (only if needed) and description
• Editor for the button's targets
• Editor to link portals

on any panel, return to previous panel
on the main panel, show the "exit" dialog
If the exit dialog is already showned, close this dialog

• A button that is activated only the first time (lever ?)
• A button that is activated only when a root enter (toogle)

• Change langage

State -> is active, or not
Default value is true.
Linked portals must have the same state.

• Handle in generic scene script
• Try to close popups before letting the scene doing anything with the notification

• touch a robot makes arrows to appear
• touch an arrow moves the robot
• touching the screen anywhere else makes arrows to disappear (If it is on the robot itself, they disappear, on another robot, the robot's arrows appear. On the GUI, no action)

Move grid
Move robots

• Robot panel
• Put robots on cells
• Robots description

How many states must the game store ?
Store in a tmp file if there is too many states ?

Create an object that store the differences between two states, in order to be able to restore the first state only with this object and the second state

• Portal tile
• Easy-to-use link system
• Add portals to Processor
• Now, robot can be destroyed when they loop

Process to generate debug and release templates for android with godot and any number of modules must be automated

• User must be able to use every different type of tiles
• Tiles must be classified by type
• User can place robots (once per type)
• User can save the level inside files (user://editor_levels)
• attach datas to the level (username, creation time)
• Save and launch level
• Autosave level
• Create. save and load level in the editor

Save files on android
Permisions

Exit button, or pressing "back" button, will show a popup: "Are-you sure you want to exit the editor and save the level?"

• Generic button tile (virtual, extends Floor, portal allowed)
• Simple button: invert state of an object (portal...) when a robot push the button
• Simple button -> when the robot move out of the tile, state inverted again
• The first and last cells in processor receive special events

On a little screen, we can't see the gameboard entirely in the editor: camera center differs from the viewport center

• Use "exclusive" property
• Do not close exclusives with back button

• Get arrays and dictionaries
• Store in files
• Load a old game

• Wall tile
• Space tile
• Cast tiles

Robots aren't erased from the board.robots dictionary

• Two robots must have the ability to throw portals
• magic_wall can receive portal
• Portals can be placed directly on the magic wall in the editor
• Maximum one portal of each type

• Each game_elements can add a animations
• Some animations must end before the next step of the move
• The others must end before the player can control the game again
• Change "processor" function
• Use game state
• Effects and actions only took effect when game state is on "game"

Global code for game and editor
"add_step" must be called from the different panels

Camera must be focused on the robot, so the user can't move it away from the robot. Zoom must be activated.