Very cryptic final prototype:
up/down = change category
left/right = select item
z/c = drop item into water
x/v = item description
It's all placeholders. :x
Earlier version that is a bit more obvious as to the chain reaction theme:
any key = drop item into water
Hm, so, I kind of suck at jams because I spend a whole day preparing the architecture and stuff. So far I've figured out:
- symbolic link the cart from my git repo
- shell script that concatenates all my source files together into the cart
- setup webstorm with lua support (only works kind-of ok since I have code in a lot of separate files and because of next bullet point)
- figured out how to do an object-oriented architecture (hackish, but it seems to work for now)
- wrote a 2D vector class
- created an OO aggregation arhitecture for scene items and engine parts
- started implementing a physics engine
Result: two circles moving across the screen that don't even collide.
2 days down, 7 to go.
Some highlights from the code:
And the all mighty:
I'm really struggling style-wise. This code is all I stand against (short variable names, multiple statements per line, no new lines) but I read all the zines and it kind of got me scared that I'll run out of space and I should conserve as much as possible. No idea if that's true or not, but it's my first real cart, so I have almost zero experience with this.
I haven't made much yet either but I've found that worrying about characters is less of an issue that the tokens.
From the manual:
One program can have a maximum of 8192 tokens. Each token is a word (e.g. variable name) or operator. Pairs of brackets and strings count as 1 token. commas, periods, local, and comments are not counted.
Which I read as "remove all brackets that aren't needed" and operators and stuff. I've tried to apply my daily programming knowledge and found it feels bloated very fast. I've learned to just keep my objects namespaced with dot notation and then skip any sort of real OO at this point...or at least I haven't bothered to figure it out yet.
BTW...love your Medium magazine, it led me to a lot of great stuff. Hope a new article is coming soon. :)
I've added in collision and gravity! You can press any button to add in more balls. Collision algorithm is O(n^2) right now so it slows down pretty fast. It needs an optimized grid scene with fast queries for nearby objects to bring it closer to O(n*m) where m<<n.
At this point the physics engine is taking 40% of the tokens. Hopefully there's enough left for a game in there? :D
I noticed long names don't matter yeah, since it's mainly token-limited. So I've made everything long and readable. Well, except local variables since that would be overkill to fix.
Glad you liked the mag! Next up is another artist feature, probably when the jam is over. :)
looking good! you should be able to save a lot of tokens by switching to using an operator overloaded vector class something like this:
vec_class = {}
vec_class.__index = vec_class
function vec_class.__add(a,b)
return vec(a.x + b.x, a.y + b.y)
end
function vec_class.__sub(a,b)
return vec(a.x - b.x, a.y - b.y)
end
-- more functions
function vec(x,y)
local v = {x=x,y=y}
setmetatable(v, vec_class)
return v
end
a = vec(1,5)
b = vec(5,6)
c = a + b
print(c.x..","..c.y)
|
Looks quite good, I'll make sure I'll keep an eye at this project as physics engine were something I ever wanted to understand and program.
I have a question though: what are the differences with this code style?
(No "constructors" because they're singletons)
I will answer later, as I'm still trying to turn this sphere water mixing thing into a semi-game.
But just in case, here's my 'chain reaction' physics non-game for now.
Oh well, this was a glorious fail. XD
So there is not much to do in the prototype … You can combine 1 and 2 to discover, wait for it, number 3!
95% time spent on the physics engine, 5% on the game. You can tell I have a lot of experience with participating in jams.
But the physics engine works. Kind-of. I tried better integration methods (newark) only to fail spectacularly there as well.
Let me also address the comments from above.
imbox: WOOOOT?! pico-8 version of lua has operator overloading? I am so new to all this, most things I googled about lua just turned out to not work in pico-8 so I kind of gave up and just relied on things people used in the zines. I'll definitely give it a try.
Also, __index? setmetatable? Is this all supported in pico-8? Have I made my own OO support without knowing there's a built-in one?
If there is any resource, other than the manual, that explains more in-depth what works and what doesn't of Lua, I'd appreciate a link.
Eiyeron: this is what I thought of at first that I'll need to do as well. They're passing the object—just a plain old table—into the method to operate on it. That's how pure procedural languages work, you only have function and you pass as a (first) parameter the data structure you want to work on. Here they've only went one step ahead to organize these functions onto a table, sort of namespaced it, for better organization.
The way I did things in the end you are actually wrapping local variables (the data structure) inside the constructor function, so you don't have to send self to functions, you get an actual instance out of the constructor that you then call methods directly on and self is implicit.
If this explanation makes any sense.
Anyway, good job everybody, I'll go play your games now.
It's not a fail if you learn something from it! seems like you did :)
This could be something cool regardless!
Very interesting to play around with! I included it in my Pico-8 Jam #2 compilation video series, if you’d like to take a look :)
[Please log in to post a comment]
