LÖVE

Righto then!

[Having trouble using the game? : Read further below on "Using this Demo"]

Ive been meddling on this project for a long while now and decided that its in a good condition to get feedback and advice on it!

The project is fairly extensive and is designed with network-play and modular like systems.

What Is Insanity Games?
Insanity Games is a (currently) multiplayer game comprising of (planned) 2 gamemodes.
It is based on games such as DOTA; LOL and HON-
YET it is not a MOBA so to speak, but rather based on the idea of player characters competing in an arena of sorts.
The basis of Insanity Games is the 'bomb strapped to your chest' and 'Every one wants you dead'

Gamemode 1: The Bomb Strapped To Your Chest.
Each player spawns in a random or predefined location on the arena, and each has a figurative bomb strapped to them.
This bomb is timer based, and once it hits 0 the player permanently dies for that round!
Each kill you make earns you some time onto your timer, so you last longer!
BUT each time you are killed you respawn with the same amount of time left before death AND a little of that time lost!
You have 4 abilities or a plethora of weapons(To-Be-Decided) available to you, each having its own unique effect!
-Imagine a mana-burn that converts enemy mana to time!

The round is won by the last player to be alive after all perma deaths.

Gamemode 2: The Insane Game Of TAG!
Each player spawns in a circle around the centre of the arena (Think HUNGER-GAMES)
A random player is chosen to be 'IT'.
While IT a player constantly gains points each second,
When the player that is IT is killed, whom ever dealt the killing blow becomes IT, the player whom died is permanently dead until new round.
BUT if a not-IT player kills a not-IT player, BOTH not-IT players DIE permanently!
AND the player whom is IT gains more points for killing other players! (To-Be-Decided)
There are a plethora of weapons available to all sprawled across the arena!

-
Note that the actual gameplay ofthe game is not anywhere worked on, only the core components needed to create the gamemodes are developed at this stage and there are still some further systems I wish to implement before i truly consider starting the default gamemodes,
BUT remember that I am developing this to be focused towards customization by users to allow for a rich, diverse gameplay.

Now about the modular design of the game!

The Asset Module :
The games foundation,core, what-have-you is designed in a modular fashion, nearly everything is mod-capable by users!
The assetModule will automatically register any assets once pointed to a folder!
Other features of the assetModule are :

-Should an asset 'type' (say entity, map, bullet etc) not exist in its database-of-assets it will automatically register the type and continue!
-Assets are supported by the network! A base function/method exists in assets which allows users to explicitly state what information is accessible client-side!
-Assets are instance-based! Infact, all 'assets' are an instance (or extention if you will) of the Base_Object asset!

Currently the default base assets and asset-types provided are :
-WEP - the weapon asset!
-Entity - basic objects that allow for love.physics use!
--Clients automatically detect entities and renders them.
-ATOM - the bullet atom! (i refer to bullets as atoms in game)
--ATOMs instance Entity as bullets are physical entities with special characteristics of their own.
-MAP - a special Entity-like asset-type that allows for maps to be made, well the outer walls so far

The asset system is easily extendable provided that you simply ALLWAYS extend Base_Object or anything with Base_Object as its root-parent.

Other Features of the Modular Systems :
Events :
Events are simply a single table containing a series of tables with strings as its keys.
To users creating events and hooking into them are fairly easy!
-The event system automatically detects if an unregistered event is fired - it will print a warning to the server!
A series of predefined events are already present for your play!
(More on those later)
-

Features not yet Added/Planned :
SoundModule - Handle 3D/2D sounds client-side, aswell as allow server-sided assistance of sounds the client does not have.
VisualModule - Handle the drawing of images and animations client-side. Server-side assistance -such as uploading missing images to clients.
FileSystemSynch - Servers automatically provide missing files to clients, based on client-side preferences.
EnhancedNetwork - Servers are account based, providing unlocks and saves to clients, aswell as the support of across-server shared accounts.

There are many more things planned, yet what i currently have is possibly the best I've achieved yet!
More detailed documentation - on how assets/events/network/etc are WIP and will be provided shortly, Expect this post to be a prelim to the documentation.

Using this Demo
Currently the game BY HARDCODE connects to localhost.

-Run the game using LOVE2D as per normal, then once all modules are loaded, press "]" to create a server Instance,
-To create a client instance press "[" - NOTE you can run both server/client on same love2d instance, BUT allways run the SERVER first.
-On the server press "p" to toggle simulation on/off
-[BROKEN] On client press "o" to toggle rendering on/off

Current BUGS
1. For some reason creating enough bullets in game can cause the client rendering to freeze until the bullets disappear - I am unsure as to the cause, ANY help is GREATLY appreciated regarding this bug. (IF you wish to help, but want more info please do ask)
2. Toggle of client Rendering is not working - minor issue/not important.

If you notice any bugs please report, thanks in advance.

Change-log now provided as of A2.3.10.

Download : Current Latest Version : VA2.3.11.5
https://www.dropbox.com/sh/ahqi2jsui3twwhp/3H_1iDsd0I

I can't run it, it complains about module 30log not found.

Argh, i think the issue i had with creating a .love before is happening again, can you still run it with it extracted (the drop onto love.exe or any of the run.bat scripts)?

Case matters when deploying cross-platform.

In 30LogCC.lua, I changed: Then I got a black screen.

The black screen is normal, reading the OP you can see a section on using the demo/game atm...
I haven't implemented loveFrames yet, and it will take a fairly long while till i reach that in my roadmap, currently i am focused on sound system and synching files clientside.

REMEMBER that this is merely a series of core files, i simply uploaded so that any feed back possible can be attained now, that and i need assistance with a annoying bug regarding creating too many bullets in the demo.

Press these buttons in order to begin game/demo, "]" , "[" , "p"
These are my debug keys for now, the first is server instance creator, the second is a server instance creator (that will immediately try to join a localhost server)
and "p" is the simulation toggle (only works in a love instance with a server instance)

I currently have one of my friends feedback-ing on my project now and then.

I am going to attempt the first documentation tomorrow afternoon.

-snip-

I fixed the .love my-side last night, going to do the replacing once i double check.

Screenshots are not going to show much, its really a simple love.physics environment, a single cube you can control/shoot bullets-that-die from and some walls to collide with.
Again graphics is lacking but its the internals itself which I am working on at this point.

Documentation on using assetModule and events to come this afternoon, along with fixed .love.

Ok, I could test with josefnpat's fix.

Is the character supposed to move very slowly? I've seen some games work with that in mind (makes you value every step), but even then it seem like the slowest game ever.

I'm a noob, so I couldn't give you a better sollution to the bullets causing the freeze, but what if the bullets disappear on impact?

currently i made the bullets hook into the onTick event to temporarily combat the issue, and making them delete on impact is easy enough,
regarding movement, it is a test entity, but to be specific to the planned game-modes , the character will accelerate faster, and have a capped speed - the reason for slow movement is that its easier to position self for now...

Once the SoundSystemModule is started ill push in more things to experience in the showcase/demo/game to present what is possible.

As a side note, if anyone is interested in using the core and wishes for some specific events that require going into the core code feel free to ask!
Also ill be starting on documentation asap after this post is made. Thus expect a detailed tutorial on using the current systems (namely assetModule,Events,Network)

if you have any issues with the systems please inform me.

*EDIT

During the writing of the documentation, I have noticed a critical issue with the systems aswell as the all the unneeded steps and work required by users to simply allow new entities to spawn.
Specifically speaking, there is infact no way to run user code without modifying core code in place.

Thus as a result all other systems are on pause until a mod/user file loader is created.

UPDATE

Version Alpha 2.3 build 10 | A2.3.10 |

New things this Update :

1. Proper Mod support! Mods are loaded via the UserData/Mods folder in Appdata/LOVE .... (More on this below)
2. Logging, use assetModule.toLog(msg) whith [msg] being a string of what you wish to add to log, automatically prints to console aswell,
Also log file is created on startup in /Logs/ folder in Appdata/LOVE, uses date as name.
Logs only print out to file on exit, lastly some configs are available :
- LogData -- Boolean, Whether the logger should actually log msgs or not, usefull to prevent generating lengthy log files.
- printToConsole -- Boolean, Whether any toLog calls should print the msg to console aswell
3. Changelog now included, it presents a to do list aswell for future builds.


MORE :

Mod Support :

To create a mod simply create a Mod.lua in a folder inside the Mods folder,
The new Mod.lua MUST follow these rules to properly load : First, why the UniqueID ? :
UniqueIDs are specific to your mod and yourmod only, they allow you to use your mods functions and allow other mods dependant on your mod to allways be sure what "name" to look for...

Dependancies use a table of strings, the strings are the UniqueID of the mods required. ie _Dependancies = {"WeaponsMod","AmmoMod"} etc

Error checking is EXTENSIVE, it ensures that mods will not crash game upon load or bad syntax, the only crashing mods should do is internal to the code and not the syntax, ie if trying to print a boolean without using tostring <--- will crash

The [_load] table specifies paths to files the mod wishes to load, this is great for specifying mod-files to load for testing,
There is also specifics required for creating other files, such as scripts, to load using the _load list : How to access functions from mods :
First you need to know its UniqueID, in this case its "SomeMod"
Next you access functions from scripts like so :
assetModule.MOD.UniqueID.Script.Function()

-A shorthand, AssetMod is assigned over assetModule.MOD for ease of use.
The UniqueID ensures that modders can have similar function names, as they will never overlap or overwrite.
The "Script" is the table you named in the script File, thus for this example its "Script",
NOTE that table within table within [etc] also work, thus in this example "Script.Graphical.Function()"

--
The mod loader, as mentioned above, is thorough when checking integrity of mods, it will not load mods if the Mod.Lua is invalid, but it will NOT unload if any of its _load files are invalid, the invalid _load file will simply not be loaded.

Mod.Lua files for mods are automatically found and loaded in the game, no need to tell anything to load your mod.
Lastly, mods will be getting their own Log files in a later update to facilitate the debugging and testing of mods.

An example mod can be found in the .love under assets/scripts. All core scripts will be going here hopefully.
Happy using, hope this helps with the issue of .08 having you need to modify core code.

Feedback awaiting.