LÖVE

The Hacksperiment !

A social coding experiment for LÖVE!
Repository: Github

Wiki
List of all Modules
Documentation|| Module ||Game ||Object ||Flux ||Anim8

Latest Version Demo



What is it?
"The Hacksperiment" is a coding experiment where people work togehter to accomplish "something"!
The project is meant to be easy to join, it works by adding modules that are an powerful yet easy way to create content. A core part of the project is "communication".



How does it work?
There is a code base everyone can add their own modules to. The base automatically hook up new modules and provide some basic functionality to load modules created by other contributors.



Wow, isn't this going to be a huge mess?
Potentially yes. But it's up to everyone what the project become.
To keep things kinda organised I'll manage the project. I maintain the code base, add new helpful stuff - I'll update the Wiki Page frequently and make sure that entries do not crash the project.
So I can tell that I'm going to do as much as I can to keep the project stable and updated.



Am I restricted to something?

To keep things clear and to make sure the project does not crash there are some restrictions for your module(s)

• Do not change the main code (`main.lua, conf.lua, game.lua`)
• Do not change modules made by other contributors without their permission
• Make sure your module(s) work as expected before publishing
• Do not call love callbacks directly from your module (e.g `love.keypressed`, `love.update`, ...)
• Do not call game functions directly from your module (e.g `Game.init`, `Game.update`, ...)

If your module doesn't stick to these restrictions, I've to reject your pull requests. If so, I will contact you about why it got rejected, so that you can solve the problem and send a new pull-request.



How do I create a module?

You can find an example here.
To add new module files you can create a new directory in the /modules/ folder named with your username or with a title for your modules.



Contribute

To contribute to the project send me a pull-request of your module(s).
Feel free to update, rework and polish your module(s) as often as you want.
If you have any compatibility problems with other modules contact the respective authors.
Also if you miss some base code functinality or library, feel free to contact me and I'll see what I can do.


If you've questions just post them here or send me a PM
As everytime - sorry for my bad english and thanks for reading!

Didn't something like this happen before, or, at least was talked about, and had some issues with it?

This seems like it'll be a really cool thing to try out. And, looking at the structure of the project, this will inevitably turn out into an awesome type of mess . So we can just add in basically whatever?

MadByte wrote:[*] Make sure your module(s) work flawlessly before publishing!

This is impossible even theoretically. Read something like "The Art of Software Testing" by G.Myers about that.
Literally years(!) need to pass before code could be considered stable enough (but never ideal). Many projects don't live long enough to achieve such stability.
And even then, when including in higher level system even simple you can't be sure that code will be flawless.
What if "print" is redefined in some other module? What if you print with background color? Current render target? And plus one more million other such things.

Neat idea! Going to run through the project a bit, see what I come up with For what it is worth, I notice the github project is spelled "Heck" not "Hack"

What synchronistic timing! I just started work on an Entity-Component System library for Lua. The grand idea is, since these systems can be so dynamic and independent (as in, no dependencies, no inheritance morass), why not have everything as content packs which can be chosen by the player? If you want zombies, add that pack. Hate zombies? Just don't load it. Maybe you want survival-style gameplay - load a pack which adds simulated hunger and whatnot to PCs (and a new little panel on the HUD showing them). Or add both of them - now you've got a survival-horror game. Any entity could be player-controlled - an entire ship, one of the crew inside, or perhaps you're just giving them all orders.

I was planning that the base content pack would be a framework to easily patch together custom-specified games. There would be a module for top-down physics, one for side-scrollers, one for Box2D. Simple but oft-used things like camera control, multiplayer, path-finding, tilemaps, configurable unified controls, saving and loading state to HDD, lerping and other handy maths, in-game hints or developer commentary. All those wheels it seems we keep remaking. It would have a hotkey-toggled editor to manipulate components in-game. As people made more modules, we can combine them in ever-more interesting ways. Make Tetris, add fire!

My ideas for modules I'd like to make, in rough order:

• The aforementioned base pack
• Builder (make structures, vehicles, etc. by connecting shapes. Like Reassembly, Captain Forever, or Space Engineers)
• Starship (using the above, make my own ship-building game)
• Fire (tweakable effects, ability to spread, extinguishing)
• Flora (plants which can have wind effects, life cycles, fragility... I don't think I'm doing crossbreeding this time)
• Submarine (surfacing and diving, hull pressure, sonar, all that good stuff)
• Zombies (eventually... Only if I could make it something unique)

The idea was partially inspired by Gmod and Space Engineers. In both of them, players choose what content to put in their game, then start building stuff in the resulting chaos. I've also noticed that games' success (and especially longevity!) depends strongly on their degree of moddability and community involvement.

zorg wrote:Didn't something like this happen before, or, at least was talked about, and had some issues with it?

I have no idea

TheOdyssey wrote:So we can just add in basically whatever?

Basically yes, as long as it works. I need to say that this experiment is kind of based on trust that nobody just want to troll everyone else. And as every experiment this can fail hard - but why shouldn't we try it at least ?

arampl wrote:-snip-

Okay, it may sounds like that but all what it means is "it shouldn't crash the project and shouldn't cause performance issues because of bad coding". I'll change that line.

kbmonkey wrote:.. the github project is spelled "Heck" not "Hack"

Damn, fixed

Taehl wrote:-snip-

The idea is good and I would be very proud if we can establish something that epic - but for the moment we should keep things low I guess. Projects like this are doomed to die on forums (for good reason I guess). It has huge potential in both directions - either it become a huge mess or it can end up in something like a solid game. There are a lot of problems to solve and a lot organisation to do. Basically everyone is able to participate and if someone wants to add something that breaks the immersion of the current direction of the project then we have to accept that

Another thing is .. I'm not sure if my base structure of the project fit to such an ambitious project. We'll see.

MadByte wrote:Make sure your module(s) work before publishing them!

Waaay better! No idea though, what I can add right now. So many libraries has already been implemented by lovers...

MadByte wrote:

zorg wrote:Didn't something like this happen before, or, at least was talked about, and had some issues with it?

I have no idea

So, i've looked into the forums and found these threads.
In any case, it might be a fun thing to do

zorg wrote: So, i've looked into the forums and found these threads.
In any case, it might be a fun thing to do

These projects were way different. Both had a predefined timeframe and the rule "no code can be altered or removed". Also they didn't provided a code base to build on top. They were meant to be pure chaos - my project is meant to build something (and as a consequence it might end up in chaos, too. But who knows)