Inny's general techniques (project bronxcombat1999)

[Inny]

Although a game about fighting double-dragon style in the bronx would be amazing, that's not what this project is (yet?). This thing is me trying to organize my general techniques together. Since I'm in a sharing mood, the repo is wide open for anyone to peek in, grab what they want, and swing out like a rum-drunk pirate.

The thing to note is that I organize according to this general idea:

Objects are composed, so the class-system is prototypical type where the __call metamethod sets the __index metamethod pointing at the parent, and then the rest of the objects all copies in. Everything deriving from object has on/off/send methods ala observer pattern. _init is called only during derivation, so each class has to care if it's a leaf or an inner-node on the tree.

Input and Graphics are big manager singletons that present an interface. Sound hasn't been added yet, but it'll follow the same pattern. Input's interface are tap, hold, and holdlen, and every input is translated into game-usable codes, so things like input.tap.menu_pageup are all most code should care about, with the input manager translating from love's inputs to game input. Graphics follows suit with regular things I want to do everywhere without going object-oriented, like writing text to screen.

Oh man am I regretting using the name bronxcombat1999 for this

This thing only presents a single gamemode, though I'd certainly want more like menu, credits, and so on.

Jumper physics is there just because I needed something to test against. I'll probably come up with a few more genre types that I could see myself wanting to stamp out games for. And of course loading tiled maps is a must, though I think going via the lua plugin is the way to go, rather than loading the tmx files.

Now of course the biggest thing I have to fight is the desire to rewrite this over and over. Maybe publicly shaming myself like this will do me good.

Github link: https://github.com/inmatarian/bronxcombat1999

[Helvecta]

Hey Inny, thanks for sharing this source! I've been needing to dissect code that has this structure (OOP?) for a long time. I see a lot of people on this forum aspiring to use or actively using this type of structure and it seems interesting at least - if not more efficient in general.

The way I structure code looks similar to this; I split everything into different components (graphics, mouse, level editor, map generator, menu, etc) and keep a list of active ones, updating and drawing them via main.lua. I keep all of the components in their own subdirectories; when a component is initiated, it requires that folder and the folder's init file requires all of the functions associated with that component. It works well to keep the CPU usage down - not so much memory.

Anyways, thanks again for letting the forums poke around at this. Oh, and

Input's interface are tap, hold, and holdlen, and every input is translated into game-usable codes, so things like input.tap.menu_pageup are all most code should care about, with the input manager translating from love's inputs to game input.

tap, hold, and holdlen? Genius.

P.S. run.bat is also genius, +imaginary karma

[Inny]

I probably should also add that I don't believe my techniques are unique beautiful snowflakes. Everyone has their own methods and they tend to be similar, just that the angle of bisection into modules is different. inheritance OOP based on taxonomies is where we get into trouble, and why its best to be avoided, but the idea of inheritance and having really good base classes is a very worthwhile thing. I mean, this should be a totally possible thing to write, and have it do something:

Code: Select all

local level_three = water_level()

[davisdude]

I do something to the tap, hold, and holdlen. Maybe not the most efficient way to do things, but this is how I role.
(Edit: Fixed link)

[Inny]

I do something to the tap, hold, and holdlen. Maybe not the most efficient way to do things, but this is how I role.

There's charm to that. I'd probably simplify it, since all of the subtables are identical to start: on a keypress if the subtable is missing, then add it, and leave them all missing initially.

Actually, my way has the problem that if love or SDL hickups and doesn't give me a keyreleased event, then my gamekey symbol will be locked in a forever pushed position. I can probably doublecheck things with love.keyboard.isDown, or I guess just keep the keys separate to catch when a duplicate has been pressed and treat it as a repeat and not increase my refcount.

[davisdude]

Yeah, I guess. Don't want to derail this too much, though.
Your utilities are quite nice! I may end up using some of them!