Merge branch 'master' of gitlab.com:alexjgriffith/min-love2d-fennel

This commit is contained in:
Alexander Griffith 2021-02-01 20:09:31 -05:00
commit cea47c5b1b
2 changed files with 15 additions and 1 deletions

1
.gitignore vendored
View file

@ -3,3 +3,4 @@
/appimage/love-prepared/ /appimage/love-prepared/
/appimage/AppRun-x86_64 /appimage/AppRun-x86_64
/appimage/appimagetool-x86_64.AppImage /appimage/appimagetool-x86_64.AppImage
/appimage/squashfs-root

View file

@ -14,11 +14,24 @@ rm -rf .git
#+END_SRC #+END_SRC
* Phil's Modal Callbacks (PMC) * Phil's Modal Callbacks (PMC)
Phil Hegelberg's [[https://gitlab.com/technomancy/exo-encounter-667/][exo-encounter-667]] is structured using a modal callback system. Each game state has a mode and each mode has a series of specific callbacks. Phil Hegelberg's [[https://gitlab.com/technomancy/exo-encounter-667/][exo-encounter-667]] is structured using a modal callback system. Each game state has a mode and each mode has a series of specific callbacks.
If you design your game as a series of states in a very simple state machine, for example *start-screen*, *play* and *end*, with unidirectional progression, you can easily separate the logic for each state into state/mode specific callbacks. As an example, in order to have state dependant rendering that differs between start-screen,play and end you could provide a *draw* callback for each of those states. Similarly if we need state dependent logic and keyboard input we could provide *update* and *keyboard* callbacks. As you iterate you can add and remove callbacks and states/modes as needed with very little friction. If you design your game as a series of states in a very simple state machine, for example *start-screen*, *play* and *end*, with unidirectional progression, you can easily separate the logic for each state into state/mode specific callbacks. As an example, in order to have state dependant rendering that differs between start-screen,play and end you could provide a *draw* callback for each of those states. Similarly if we need state dependent logic and keyboard input we could provide *update* and *keyboard* callbacks. As you iterate you can add and remove callbacks and states/modes as needed with very little friction.
* Emacs Setup * Emacs Setup
Once you install the latest version of [[https://gitlab.com/technomancy/fennel-mode][fennel-mode]], you can run Once you install the latest version of [[https://gitlab.com/technomancy/fennel-mode][fennel-mode]], you can run
=C-u M-x fennel-repl= followed by =love .= to launch a repl. =C-u M-x fennel-repl= followed by =love .= to launch a repl.
* Project Structure
The =make= process as-is will only compile the contents of the root folder and the =lib/= folder+subfolders, so make sure to put your game files in either of those.
Specifically, every =.fnl= file needed at runtime needs to be situated in the root folder, and every file which is not a =.lua= or =.fnl= file needs to be put inside =lib/=.
In order to use macros, they have to be put in =.fnl= files inside =lib/=.
* Release Process
Use =make linux=, =make windows=, or =make mac= to create executables for each platform, or =make release= to do all three. Make sure to read the makefile for more commands (and remember to edit your game data in it!)