how much code do you usually write in there?
at around 400 lines it's getting hard to manage for me.
I've made two incomplete games, one sitting at about 400 lines and the other at about 600 so far.
Some things I found to help:
Make lots of small comments, short and to the point.
Make lots of functions.
Name the functions well, you easily know what they do by name alone.
I like to name my function starting with update or draw. ie. draw_lines() or update_actors(). This goes back to naming them well.
Holding alt and pressing up or down jumps you to the previous or next function. By segregating tasks into functions (even if not necessary) you can later find the block of code you need quickly.
Hope that helps.
yeah i've found that keeping my code super organized helps
all init functions grouped, all update functions grouped all draw functions grouped in a common order.
The best shortcut though is still alt-up/down to jump to the previous/next function. But yeah, keeping clean code on such a small editor is quite hard and I'm really tempted to copy/pasta this into vim/Sublime text/notepad to have a better view of the code :/ ...
My LD game got to about 600 lines and by the end I definitely wanted to take vim to it to rearrange some of the functions, thought grouping things like akilism mentioned (draw functions, update functions) helped tremendously.
If I had to pick a few vim features that would help a lot,
- marks - I don't use these a ton in normal vim, but a list in the top-left would be lovely
- keyboard visual selection - the mouse is nice but implied scrolling is always a little weird
- tags - either as a simple "jump to word under cursor" or "jump to [function <word-under-cursor>] or a more sophisticated system this'd be lovely (looks like ctags supports Lua too!)
311 lines on my super-simple fly-through-the-walls game. I'll probably hit 400 if/when I update it to have a title screen and 2-player/difficulty options.
I kept my code mostly grouped by which part of the game they handle--effects in one place, player's update/draw functions in one place, wall update/draw functions in one place (the collision-handling code went in between them) and then _init, _update, and _draw in that order.
I kept thinking that I'd be happier using Sublime Text to edit this stuff, but I wound up doing all my code in the built-in editor. You'd think I would miss my find/replace, but I really didn't need it.
I have Sublime on the right and pico on the left, cut and past back and forth as needed,. mostly still reading the API but I can see it will be tight to work fully in the little terminal,.
Hmm, I just open the p8 file directly in Sublime, switch the syntax coloring to lua, and code away, no need to cut-and-paste around.
Slightly less convinient to launch the game (after saving in Sublime, switch back to pico-8, and press up,up,enter,up,up,enter (= go back in history to load, and go back in history to run)), but MUCH more convinient to code. :)
Ohh, and you must pay attention that the p8 file contains all other data besides the code too - so if you modify your sprites or sounds or whatever, you must remember to save in pico-8, otherwise you will overwrite you non-code changes with the previous version from the open p8 in Sublime.
I found this ugly trick to avoid reoad load/run manualy each time when switching back from an external editor.
Put this at the end of the lua souce (replace cartname wiith the current one)
if peek(0x4300) == 0 then poke(0x4300,1) load("cartname") run() else poke(0x4300,0) end |
Run once > edit in external editor & save > switch back to pico8 > Ctrl+R
Thanks for that trick, toffer! I've been using the heck out of it 'cause I can't live without vim keybindings :)
@toffer -- that's ingenious!
How about this:
Using CTRL-R to run automatically reloads the last loaded/saved filename if there are no unsaved changes.
So if you make edits to code both externally and in pico-8's editor and then CTRL-R, only the later will be observed. If you don't use an external editor at all (and you don't otherwise mess with the cart file while editing), CTRL-R will have the same behaviour as it currently does.
[Please log in to post a comment]