Log In  

I've been using an "object-like" idiom in my Pico-8 programs so far where I have functions where I basically pass in a "self" and do operations on an object. I also tend to keep a "type" variable. That seems to have been enough to get as "object oriented" as I need to be. I've seen that it is possible to hack Lua to basically give you full oop and inheritance. It looks as though it is a hack and not a built in language feature, and from what I've been reading not very many Pico-8 users use it.

My question is, to those that do, what do you believe the advantages are, especially in the context of making such small programs...? (guessing there aren't any, other than finding it interesting to implement)

P#49689 2018-02-25 22:33 ( Edited 2018-02-27 20:41)

:: Felice

In small games you can definitely pay a price in tokens for OOP. For OOP to pay off, you need a big class hierarchy, really, to offset the overhead.

On the other hand, if you're okay on tokens, OOP is really a good idea just on general principles, since I think a lot of people are ultimately aiming to design bigger games, and I think you inevitably want to be in the habit of using OOP in games with any significant complexity. Compactness, organization, readability (at least when used well), maintainability, flexibility, and growability all tend to improve with OOP.

You just kind of have to get a feel for where to draw the line. Do you represent every pixel on the screen as an object with getters and setters? Nah, obviously not. So somewhere between player 1 and a pixel there's a threshold. You just need to develop a eye for where to put it.

P#49691 2018-02-25 22:39 ( Edited 2018-02-26 03:42)

Same here, using OOP as an overall pattern (ex: to group methods related to a given class), avoiding global function variables (eg using self) and using a lot tables generic methods.

In Nuklear Klone I used an ‘instance inheritance’ approach that works well (imho).
That is: all entities are defined as static tables that gets cloned to create live entities.
A parent table can be specified as a base class.

Note: in real games, all_parts is actually stored in a 1-token string :)

function clone(src,dst)
    -- safety checks
    if(src==dst) assert()
    if(type(src)!="table") assert()
    dst=dst or {}
    for k,v in pairs(src) do
        if(not dst[k]) dst[k]=v
    end
    return dst
end
local all_parts={
    -- parent class
    part_cls={
        update=update_part,
        draw=draw_pixel_part,
        inertia=0.98,
        r=1,dr=0,ttl=30,c=1},
    -- attribute override
    trail={base_cls="part_cls",c=13},
    -- attribute + methods override
    smoke={
        base_cls="part_cls",
        draw=draw_circ_part,
        c=0xd7,
        dy=0.08},...}

function make_part(x,y,src,dx,dy)
    src=all_parts[src]
    return clone(all_parts[src.base_cls or "part_cls"],
        clone(src,{
            x=x,
            y=y,
            dx=dx or 0,
            dy=dy or 0}))
end
P#49741 2018-02-27 02:16 ( Edited 2018-02-27 07:21)
:: eriban

I have used inheritance to good effect in my Bumble Bots game. In particular, I am using the following class hierarchy:

Mover
  Bot
    Enemy
    Player
  Box

In this game the enemies and the player are both bots which move similarly but with different movement triggers, AI versus keyboard input. There are also boxes which can be pushed, which share similar movement constraints and update logic, but not all, e.g. boxes cannot turn.

Here OOP is a good fit I think. The common logic is shared in the base classes, which avoids code duplication. Even though the Lua OOP syntax is a bit verbose, I think it pays off here. Having said that, OOP is also a paradigm that feels natural to me, so I may be a bit biased...

P#49757 2018-02-27 15:41 ( Edited 2018-02-27 20:41)

[Please log in to post a comment]

About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2019-10-18 10:16 | 0.013s | 2097k | Q:21