Marin0 SE

Mods, guides how to use and install mods go right in here.
Post Reply
User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 13 Mar 2015, 23:30

No, you didn't read that wrong, I'm just bad with names and nobody corrected me.

What the hell is a Marin0?
It is a WIP reworking of the latest stable release of Mari0 SE geared towards being as flexible as possible. The way I put it to others is a gmod-styled ... mod. It is meant to serve as a standard base that people can work with. Its primary goal is to reduce the number of conflicting mods out in the woodwork by means of reducing the potential points of conflict, in addition to gmod-styled addons.

Here's a video of it in action.

What did you do?
  • Love 0.9.1 compatibility. No more bad love. I wanted to reduce the number of people writing depreciated function calls to zero.
  • Crash reloading. If you're editing and you manage to fix the code, a file watcher will reinit the game to the best of its ability.
  • Graphics fallbacks. Not a new feature, but now you can reskin enemies without changing the base files. It has several fallback locations so the player can pick a system skin to use in addition to allowing modpacks to provide their own. This prevents things that aren't skinned from becoming invisible on a given graphics pack. If you are making a pack, warnings will be generated in the console when an image that isn't skinned falls back. If I catch you shipping graphics that are already included I will break your hands, 'cause there's no need for it. If you are making a mod off of this and you see a purple checkerboard, that means you forgot to give something a graphic.
  • Sound fallbacks / packs. Just like graphics packs, mappacks can provide their own sounds and they will fall back just like graphics do. Crazy how nature do that. If you hear a skull trumpet that means you're referencing sounds that don't exist and now everyone will suffer because of it.
  • Made it more debuggable. Better integration with ZeroBrane in addition to in-game utilities like a console.
  • Built in screenshot uploading, hit f11 and it will automatically upload your current screen to imgur and put a link in your clipboard. It will also do this when you experience a crash so that fixing things is easier.
  • Mass refactoring of code. Like, so much. I reduced the number of variables in global scope, fixed a lot of repeated anti-patterns in the code, split large files into smaller chunks with less responsibilities. Monolithic files make it harder to merge mods in so this was a good for everyone, really.
  • Scope reduction. A lot of the game was responsible for things that didn't make sense. Why were globals responsible for portals when they could be objects? Other things like that.
  • Entity overhaul. Instead of having a wall of includes, entities are being migrated to a Based Entity system that makes greater use of Middleclass' mixins and other fun things. This means that your new entity can just include the behavior of the companion cube and it will be carry-able.
  • Sanity. All the entities that aren't yet based entities are now Sane Entities, they're not as smart as based entities, but they're smart enough to let the engine do some of their work for them.
  • Baked in networking. A major advantage of migrating to the new entity system is that it allows the netcode to iterate through objects better and reduce the number of codepoints your entity needs to modify. Ideally, you would only need one lua file to make a new relatively basic entity that works with everything. Instead of just forcibly resyncing player position, the netcode also emulates movement keypresses for smoother and more accurate locations.
  • New gels. White, black, water. White makes things portalable, black makes them unportalable, and water washes away any existing gel.
  • Powerup routines. A powerup can now specify what state a player goes to. Want NSMB-styled powerups? Now that can happen, because your fireflower will now revert you to big mario. Unless you tell it not to. It is your call. This behavior isn't final but it's good enough for now to allow for things like mini-mushrooms with minimal effort.
  • Gmod styled hooks. Want something to happen when another certain thing happens? Now your code can run without needing to touch core files, as long as there's a hook for it. Not enough hooks? Make one or ask for them.
  • Control improvements. Every input that is handled in the game will eventually be handled by a library. This means that you can use crazy key combos if you want. It also means you can use the level editor without touching the mouse or keyboard. Tried to come up with a better controller default. Your mileage may vary.
  • No more linear level names. Want a warp pipe to take you back to 1-1? Well, you're an asshole, but you can do it. Maps are on a per-name basis. As it stands, the only thing that a mappack needs is 1-1 and from there you could be taken anywhere else in the game. Whether or not the area you are transferring to is a sub-level depends on what flag you use on the warp-pipe.
  • Killfeed. Why would I include a TF2 styled killfeed in a platformer? Makes you think.
  • Editor improvements. Dropper tool now allows you to select entities. Buttons for making new maps. Better tooltips, entities get their graphics from their base graphics images, not from the lookup. Better point-entities graphics and tooltips. Map list shows you all maps for a given mappack, not just world one through eight. This means you'll need to click "new map", which will create a new map from your current map. Think of it as a "save as". The editor tells you what tool you're using, where your cursor is, and even has an animated outline for where the block you're painting will appear when you click. Editor menu background is now checkerboarded to make it easier to tell when something is transparent.
  • Editor tool system. Want to write your own editor tool to do something way cool? Now you can! That way you don't have to bury your functionality miles deep in the editor.lua, work is being made to automate generation to an undo stack. Undo only the blocks you changed, not an entire map state.
  • Editor shortcuts. ctrl+1-7 selects different tile groups. F1-4 now opens the different major tab sections. ctrl+t takes you into test mode immediately. ctrl+s saves the level. ctrl+e toggles to the eraser tool, hitting it twice will toggle to the entity eraser. Tab opens the editor menu to wherever you left it.
  • Weapon system. Want to make a cool new gun that isn't a portal gun? Great! You could have a gel gun. Or a gun type that nobody has even started thinking about! Can you imagine that, being the person that made something nobody else has done before?!
  • No-portal areas. Want the player not able to put portals somewhere? Okay, but you better have a good reason. This change was made by making the portal into a bullet, so there's tons of stuff you can do with this.
  • Bowser is now an enemy. Why does he get to be so special? Now you can have your own boss as frequently as you please.
  • More gates and events. You can now re-create the scene where mario touches the axe entirely with gates and events. That's pretty crazy. The animationtarget entity and event now provide a channel of communication between gates and the event system.
  • Foundation for more gamemodes. Don't like being a flag toucher? If you insist. Now you can collect red coins, or even create your own gamemode with the foundation we're laying.
  • Excursion funnel spread and bob. No longer will things be carried dead center, they will all bob and wave along with the waves of the funnel. This means that gel will be easier to spread. Lifetime of gel was also modified to be indefinite so that big rooms and more collaborative puzzles would be possible. Putting too much gel on your screen will lag you. I'm working on optimizing the graphics so that's less of a problem.
  • Magic. It's so cool.
  • Generators. You know when bullet bills and cheep cheeps start attacking your face? Now you can specify a region for them to exist in. Want a vertical level with cheep cheeps? Make them pop out of a pond instead of from literally everywhere.
  • TMX/JSON maps. Don't like working with the existing map system? Tired of pumping variables into places that you're not comfortable with? Good. I'm lifting the maps from a global to an object, meaning that multiple maps could be loaded at the same time.
  • Unlimited tiles. A side effect of TMX maps is that this allows you to edit maps externally and removes dependence on the "extra tiles" png. Go hog wild, include as many tiles as your heart desires. No more compiling a master sheet of all the things you like, keep 'em separate.
  • Enemy riding. Ride those little fools like they're SMB2 shyguys or moles.
  • Hats. What would I be if I didn't provide more hats?
  • Damage types. Players and enemies alike can inflict damage types with their own defined callbacks. Things that kick shells technically score assists due to being the last thing that touched a physics object. Things that go through portals are technically "touched" so that whatever goes through them belongs to their parent. You can be credited for a kill by using a portal gun and a cube.
  • Player localization. Each player object is now responsible for their coin count, lives, and score. There's also health. The player and enemies have health. Test this out with the strong goomba.
  • New shaders. crushed reduces the colorspace to 4 colors only. greentint tints everything a select shade of green. Use them together and you can pretend you're playing on a Game Boy. Also added a bunch of shaders to simulate forms of color blindness. Mess, Stretch, picture-in-picture are two fun but ultimately useless shaders that I threw in the repo because who knows?
  • Enemies. In addition to all of the flavorful attributes we introduced, we also imported alesan99's enemy.lua with what was the latest at the time.
What are you going to do?
  • Finalize it. I want everyone to have their hands in this because I want the community brought together, not pushing a redistribution of the game that can't be combined with someone else. Part of this means that I'll be helping anyone that asks to make their code compatible with Marin0 if not outright merging it upstream.
  • Everything it says here, to some capacity. And anything that you put over here.
Can I touch it?
You can, but it's very much broken. I didn't want to bring it public because I know it will get swarmed with loads of bug reports. Bug reports are good, but half of them are due to the game being in-transit to what it should look like in the end. Y'dig? The reason I'm bringing it out is because I want other developers to get their hands in the pot and tell me what they want to make the game easier to mod for others and easier for everyone's code to work together.

Check it out on github: Marin0SE

Can I see it?
Here's a bunch of images of it from when I was documenting bugs. You never take a picture of things when they work, huh?
http://i.imgur.com/EfIfJRK.gif
http://i.imgur.com/hVI5f5t.gif
http://i.imgur.com/MzjjiEK.gif
http://i.imgur.com/xdlVs8O.gif
http://i.imgur.com/r0oXKni.gif
http://i.imgur.com/gLTye5F.gif
http://i.imgur.com/ngFGY3g.gif
http://i.imgur.com/Um5LaVN.gif
http://i.imgur.com/lX6jU0Q.gif
http://i.imgur.com/TlwbyBV.gif
http://i.imgur.com/6wJoRwl.gif
http://i.imgur.com/atpmKfC.gif
http://i.imgur.com/psC70zi.gif
http://i.imgur.com/MMLtPRl.gif
http://i.imgur.com/INInw4w.gif
http://i.imgur.com/EEWBDB7.gif
http://i.imgur.com/0Zj8IFF.gif

Shouts
Hammy got me to do the bulk of this, but he also helped. Mari0Maker also made my cursory visit into this post by asking politely. So good on him!

User avatar
MM102
Posts: 970
Joined: 11 May 2012, 06:08
Contact:

Post » 13 Mar 2015, 23:58

Spoilers so they don't load all at once
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image

B-Man99
Posts: 1868
Joined: 02 Jul 2012, 00:32
Contact:

Post » 14 Mar 2015, 04:17

Holy hell.
This looks equally as powerful as it is fun. Keep up the good work! I'm impressed with how you've managed and planned so far :)

User avatar
TurretBot
Posts: 4412
Joined: 15 Mar 2012, 23:18
Contact:

Post » 14 Mar 2015, 05:02

well gee if alesan's mod for 1.6 still getting more attention than my mod wasn't enough this probably takes me out of the business altogether thanks

good job on the mod hope you finish it :)))))))

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 18 Mar 2015, 02:57

Making a Roadmap
So it's no surprise that I'm having a bit of difficulty deciding where to take things. This is because I am a single person and I can't make decisions on behalf of my fellow modders.

Here's what users can do:
  • Nominate mods. The more interest expressed in mods, the easier it will be to tell where to focus my efforts. Post a link to the mod, and any additional information on what the mod does that the author might have left out, like if it adds new controls, new entities, and what version of love/Mari0 it is based upon.
  • Talk to your favorite mod authors and see if Marin0 SE is right for them. Ultimately it's their call if their work gets integrated upstream or if they want to make their mod compatible with Marin0 SE or if it is supported at all. They can't do that if they think there's no interest in a globally compatible version of Mari0 or if they're simply unaware of Marin0.
  • Ask questions. Want to write mods, but don't know how to? It's probably not going to be as easy as making graphics or levels, but, with enough questions I can make guides for doing certain things with Marin0.
Here's what modders can do:
  • Look at what I have so far. Sometimes I think I made good decisions, other times I'm uncertain if others will agree with the decision I'm making. If you see anything that doesn't make sense, warn a brother! Be sure to check out the commit history for any reasoning surrounding a given file. There's also a chance that the trello had some discussion regarding something.
  • Ask questions. I will answer any questions you have. A lot of code was relocated and flows were changed up. Any questions you may have are likely going to be asked by others. If you happen to find your answer yourself, please make note of it in the Marin0 SE Wiki. I should probably say this elsewhere, but the wiki also has information that would be useful for modding the current version of Mari0/SE.
  • Enroll your mods. Have a mod that's really old that you don't feel like implementing, but would still like to see converted or merged? Just nominate it as described above and I'll add it to my list of things to convert. If you're still developing and supporting your mod, no need to hault development until Marin0 is ready, just post that you're interested and we can work together on the problem.
  • Contribute. See something that needs to be done? Do it and submit a pull request. If your first few pull requests look good, you'll be given write access to the repo. Knock out some issues in the trello or waffle.io.
  • Vote. Every once and a while I'm going to post a milestone consideration post and open the discussion gates with issues that I would like everyone to have a voice in. Don't tell anybody, but I think one's happening right now.
Editor's Pick Awards
Here's a list of concerns, now is your chance to tell me what is most important and any other ideas you might have regarding each of them.

Map Format
Image
At least a handful of mods have probably altered the map format by this point in time. If they haven't done it directly, then they're supplying supplemental text files that effectively add more data to the mappack. My primary consideration for a new map format is to use Tiled and its TMX Map Format in addition to TSX for tileset information. It has per-tile properties, per-map properties, and per-layer properties that would effectively recreate many features we already have and want. Plus it has an external map editor that enables us to test new features without implementing a GUI to edit it. Also the in-game editor kinda got blown the fuck out while I was screwing with everything.

However, my concerns are more focused on how to effectively utilize Tiled.
As (partially) illustrated in the screenshot above, here's what I had in mind.
  • smbtiles and portaltiles are their own tilesets with given properties, these can be overridden in a mappack (discouraged) or one could simply replace the graphic that smbtiles references
  • each tile layer should have an accompanying entity layer before it if it is meant to have entities, layer order will be handled according to tiled's order
  • entities should be objects (rectangular squares) with their types set to their respective entity names, any additional properties that an entity makes use of (named parameters)
  • enemies should be an object of type enemy with the property enemytype to specify which enemy they are
  • overlays and foreground/background parallax can be recreated using either image sources or by being built with tiles
  • entities that make use of a region should use their object size as their region
  • entity objects should, in general, be the size of the object they represent
  • entity objects that are not the size of their object should be a single tile large in the top left corner of the location they're to appear in otherwise they're invalid
  • entities that span multiple tiles but don't physically consume 100% of that space will be centered unless otherwise specified
Are there any features we might be under-utilizing or straight up abusing?

Linked Entities
The link system is a bit cumbersome to work with. I have no idea if anyone has solved this issue. Particularly, I didn't like AND gates being limited to only four input sources and building a pyramid of AND gates didn't particularly appeal to me. If you've ever used Wiremod you probably have a good idea of what I'm looking to implement here. The thing is, this is one of those situations where data structure directly drives the design and implementation and there's a few ways to go about this:

Using properties:
  • linked entities will be able to have named inputs/outputs and/or infinite anonymous inputs or outputs
  • linked entities will be output oriented meaning that objects that output keep track of the coordinates of the object they output to, and should it move / go missing they update / remove the link accordingly
  • named links will be in the form of link_(in/out)put_(name) or just link_(in/out)put for anonymous links as properties of the object
  • the link properties will contain coordinate pairs, like: "0,0 33,38" which would associate that output with a given location(s)
  • using this method, entities would never be able to be off-grid because of ambiguity regarding which entities are in a given coordinate location and typing exact decimal coordinates isn't exactly user friendly for out-of-game editors
Using pure polylines:
  • polyline links would be of type "link"
  • I have no idea how to interpret a multi-segmented polyline unless we used that ability to visualize line routing
  • polylines must stop and start on top of an entity to be valid
  • pure anonymous links would assume direction of the links by translating the location of the lines' start and end point
  • links that communicate to named inputs and outputs would contain the names of inputs and outputs on their respective input/output entity
  • links to/from named sources to/from anonymous sinks would refer to the anonymous input as "*" or some other reserved input/output name
Using polylines & entity properties:
  • the first three lines of the properties section and the polyline remain true
  • instead of coordinate pairs, it would be a list of internal object IDs or polyline names
  • polylines would have to have unique names and IDs that could break reference to one another while editing out-of-editor, same issue as coordinates
  • the issue wouldn't be nearly as bad because there would still be a visual representation and a reminder to check the lines
Some other idea?

Weapon System
I generalized weapons down to three basic inputs (primaryFire, secondaryFire) and probably even a reload. This can be as sophisticated as people want it to be and at the end of the day it's most likely just going to end up borrowing from the gmod / source weapon API. Ammo isn't implemented at the time of this writing, but it would only be two or four lines to change to put it in for all existing weapons. (And even more to put in a collectible ammo entity.) At the moment, weapons are parented to the player so it would be possible to listen to the player's input map. I'm hoping that this will discourage people from using raw love listeners for particular keys and instead use agreed-upon modifier inputs. Additionally, weapons are presently responsible for drawing themselves and any UX related to them (like the portal lights and the dots). This is so that a weapon could be dropped on the ground and still be visualized and possibly even picked up again.

Mount System
There's already a pretty interesting Yoshi entity floating around and while I can't recall exact details, it had quite a few codepoints in player.lua. How should we handle mounts so that we don't have to make a new case for each possible mount? Technically, if all goes well, a mount system could be implemented purely through using the hook API for certain parts of a player's movement. There should, however, be a mount and dismount method in the same way that there's fire methods for weapons.

Modpacks
You figure I would have thought about this sooner. Truth is, I did, but since all the features I'm working on should be considered "core", I couldn't properly envision what sort of access a mod would need. I had the following in mind:
  • Mods are treated like file system mounts for certain files and paths, meaning that any images, maps, entities provided by a given mod would be given priority over the userdata location and the executable data in that order if they were registered properly.
  • Mods would be loaded in an arbitrary order, last in line wins.
  • Entities, weapons (technically entities), etc. would be automatically registered using a standard syntax like assigning to an expected variable name.
  • Mods will always have access to hooked events.
  • Mods, once loaded, could potentially extend base classes. I haven't decided if there is a situation where overriding/loading would be permissible.
  • In the event of it being absolutely necessary to modify core lua files, it can be done so with diff patches. If a patch can't be applied then it's incompatible with another mod. Incompatibilities (and diff patches) are a sign of needing further abstraction so developers don't run face-first into one-another.
  • Mods would have one or more auto run files (init.lua for a simple require syntax) to set itself up for anything that wasn't automatically registered. I'd like to reduce the necessity of arbitrary code executed but until we figure out patterns this might be necessary.
  • It's Lua, sandboxing lua from within lua is possible but everything can go to shit if things aren't locked down so I'm not going to even pretend that we can do that at the moment. In the very least, unless the lua is obfuscated, mods will be in plain text. Don't run code you don't trust, etc.
Your Concern Here
Maybe I completely forgot something. It's possible, this is a long post.

B-Man99
Posts: 1868
Joined: 02 Jul 2012, 00:32
Contact:

Post » 18 Mar 2015, 03:20

I said "Holy hell." again.
I'm not exactly a Mari0 expert as I've only played a handful of maps and never successfully managed to make one myself, but I would definitely like to commend you for putting so much thought into this and giving us a ton of information and ideas! that post is larger than the entire thread of when I made something
Your second post covers the topic of using Tiled quite a bit. I would agree that it's a great idea... I'm sure I've heard it suggested before. My main concern is that it wouldn't be reasonably achievable to port an entire preexisting game to use this. Again, I don't know much about either of these, but have you determined any feasible method to use this format with Mari0 yet? I would imagine the conversion would affect a large portion of the code. What you've managed so far shows signs that this isn't too much of a stretch. If you can manage to pull it off, that's something huge. Unbelievable. Amazing. It's just generally a good idea to know how to go in a general direction before thinking too much about what your specifics are going to be, that way your specifics can get even better :)

User avatar
TurretBot
Posts: 4412
Joined: 15 Mar 2012, 23:18
Contact:

Post » 18 Mar 2015, 03:43

Code: Select all

?looktimer int (timer) 0 No idea what this does.
?raccoonstarttimer int (timer) 0 ^
?raccoontimer ^
?raccoonascendtimer ^
?tailwagtimer ^
?tailwagframe int (frame) 1 The frame the player is currently in in their tail wag animation.
These variables deal with the "raccoon" character property. Basically it functions like SMB3's raccoon power-up, added to a character through its json. Specifically, I believe the first three are for flying, the last two are for wagging your tail.

Not sure about looktimer though.

User avatar
Qcode
Posts: 1479
Joined: 05 Feb 2012, 18:00
Contact:

Post » 18 Mar 2015, 04:17

...
Last edited by Qcode on 21 Oct 2021, 19:24, edited 1 time in total.

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 18 Mar 2015, 04:27

B-Man99 wrote:I said "Holy hell." again.
I'm not exactly a Mari0 expert as I've only played a handful of maps and never successfully managed to make one myself, but I would definitely like to commend you for putting so much thought into this and giving us a ton of information and ideas! that post is larger than the entire thread of when I made something
Your second post covers the topic of using Tiled quite a bit. I would agree that it's a great idea... I'm sure I've heard it suggested before. My main concern is that it wouldn't be reasonably achievable to port an entire preexisting game to use this. Again, I don't know much about either of these, but have you determined any feasible method to use this format with Mari0 yet? I would imagine the conversion would affect a large portion of the code. What you've managed so far shows signs that this isn't too much of a stretch. If you can manage to pull it off, that's something huge. Unbelievable. Amazing. It's just generally a good idea to know how to go in a general direction before thinking too much about what your specifics are going to be, that way your specifics can get even better :)
Marin0 (in one of its branches, probably map-refactor, in one of its commits) is perfectly playable through loading a json-formatted tiled level. It does so by translating json into the variables that Mari0 is used to using. From there I can use the in-game console to save a level using either the new tiled save function or the old save function. Getting complete independence from the existing system only requires a little bit of the following:
  • Changing all references to map[x][y], which is partially implemented to refer to to the object dmap. (For the time being, thr global map is a reference to the dmap, which is a child of the world object.)
  • Fixing the coordinate system. Tiled is 0-indexed and Mari0 is 1-indexed, like lua. I've been 0-indexing map related stuff wherever I bump into something.
  • The editor, everything about it gets confused. That's why it is largely broken.
  • Spritebatches/level rendering. I used PROBE to profile around and found the level render was taking up a pretty big hit on the render step. I sorta corrected it, but not entirely. Fortunately the library I am bringing in for tiled also handles spritebatches.
Even with its incomplete implementation, the most important parts of things are functional.

The sort of process I've been using to make enhancements is to implement something on the side, slowly integrate it with existing globals, then all at once replace it everywhere. So far it has been working.

User avatar
LightningFire
Posts: 1828
Joined: 10 Mar 2012, 17:24
Contact:

Post » 19 Mar 2015, 00:38

This one guy is the single most organized user I've seen in a good while.
Definitely looking forward to this being a success, even though I don't work with Mari0 stuff anymore.

User avatar
MM102
Posts: 970
Joined: 11 May 2012, 06:08
Contact:

Post » 19 Mar 2015, 19:55

I don't know how to feel about this mod because in a way I fear it would stop mari0 se. Once the updates stopped and it was put in hiatus the community kinda started taking it over. I was worried that once it gets to a certain point and it turns into a thing of its own and there'd be no motivation for the official version.

But it is a great endeavor and I commend you for how much work you've put into this. Looking forward to it :)

User avatar
HugoBDesigner
Posts: 2188
Joined: 19 Sep 2012, 02:23
Contact:

Post » 20 Mar 2015, 00:05

As long as this doesn't break everything from vanilla mappacks, this shouldn't be a problem.
I still have to read the main post entirely though :P

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 20 Mar 2015, 00:38

HugoBDesigner wrote:As long as this doesn't break everything from vanilla mappacks, this shouldn't be a problem.
I still have to read the main post entirely though :P
A thing I have planned is to allow the game to read legacy mappack formats via internally converting them. Over time, conversions should get better, but I will always recommend feeding it data in a specified format. Especially with the multitude of ways people have implemented infinite levels and sublevels. Plus the game itself could output the mappack in a new format if anyone wanted it that way, for fine tuned conversion after anything the converter missed.

That said, I will need a pretty good sample set of mappacks to run any conversions against, both vanilla and mod-dependent mappacks.

For everyone's trouble, here's an image of me trying to put all the objects and their draw code inside the map's draw handler -- all running on the tiled_example mappack.
Image

and a sneak peek at the profiler and how it destroys framerate once it opens

User avatar
TurretBot
Posts: 4412
Joined: 15 Mar 2012, 23:18
Contact:

Post » 20 Mar 2015, 00:45

EntranceJew wrote:implemented infinite levels and sublevels.
Actually, Mari0: SE at least seemingly already supports this (and inf. sublevels was in 1.6, too). You just can't access them normally.
I almost feel like you were probably actually just talking about that though.

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 20 Mar 2015, 01:52

TurretBot wrote:
EntranceJew wrote:implemented infinite levels and sublevels.
Actually, Mari0: SE at least seemingly already supports this (and inf. sublevels was in 1.6, too). You just can't access them normally.
I almost feel like you were probably actually just talking about that though.
Basically that.

Image

At least I got scaling done. Now I just have to wrangle all the other things that make levels work, like physics and further internalizing properties to objects instead of leaving them all global.

If you're tooling along with me, hitting F9 will cause lurker to scan for changed files. Or, if you're on the crash screen you can hit "s" to do it there. shift+F9 opens the regular lua debug console, separate from the in-game console. F8 opens the profiler and F7 shows just the framerate itself. Lurker scans automatically every minute or so, if you see the framerate dip to 200 for a moment that's probably the reason

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 26 Mar 2015, 00:18

Based Entities
I mentioned them, they're sorta weird sounding, what's going on with that?

How Things Were
Entities have/had a lot of codepoints to cover and I'm not happy about that. (Déjà vu?)

It should go without saying, but this meant that every entity meant another copy and paste in a bunch of spots and that wasn't cool.

How Things Are
There exists baseentity that I was using as a foundation to repackage the many objects in the game that we have. You can see inside it that it checks for a variety of mixins that a given entity might use. Let's walk through one. This might require an understanding of classes, inheritance, and properties.

basedents/box.lua is a fair example of this.
You'll see that the first three lines are just making a new variable called thisclass that inherits from the baseentity class mentioned above.
Then we set a bunch of properties, like thisclass.static.STATIC_PROPERTY_NAME. For those of you that are familiar with how we use JSON variables to set up an enemy, we're using a bunch of properties established in a class.

Then we do a handful of thisclass:include(MixinNameHere). What these do, is include behaviors that already exist. Let's look at basedmixins/HasGraphics.lua as an example.

The first thing we do in there is assign a bunch of properties that our class will inherit, that's pretty normal. We also give it a bunch of helper methods that should only be available to things that have graphics, like setGraphic and that sets the graphic accordingly. The interesting method is down at the bottom, "included", that is executed as soon as a class is loaded (all basedentities are loaded when you start the game, this might change but for now it's what it does). So by setting the property GRAPHIC_SIGS, we give the HasGraphics mixin the ability to load all of the class images into memory.

So from here, we have come up with a set of methods that should be available to a class that uses graphics. This is good, it breaks the complexity of one entity down and reduces it to a set of traits. From here, our mixins are setting a bunch of properties up in a global space automatically, like registering it for the editor, allowing input/outputs for the link system, and giving it the ability to hurt things so that all we have to do is supply a handful of values.

As you can see in box.lua, we only have code that is exclusive to box.lua. We can override methods we inherit from mixins or we can extend them, like in thisclass:init() we perform baseentity.init(self, x, y, 0, r). Let's break this down:
  • We reference the baseentity from which we are derived.
  • We pass a reference to our class to the baseentity's init method.
  • Our parent class constructs us as it would itself, so anything you see in baseentity:init now applies to us as the self.
If you look back in baseentity.lua's init method, you'll notice that we have the pattern if mix[MixinName] thrown about. We're using this pattern to detect certain features available and setting them up accordingly. This is because certain attributes can only be communicated to our classes at run time, so when the level loads, it creates all the boxes and buttons and tells them where they will exist in the world and what graphic it will be using.

As a side note, bigbox has a lot of duplicate code in it when it should not. Line two should read as _G[classname] = class(classname, box) but it doesn't. This is because basedentities are just iterated over and don't attempt to resolve dependencies. I'm working on that. Not to mention all the properties in box.lua don't refer to thisclass.static:method() when they should.

What Might Happen
Creating the mixins are a great way to reduce redundant code and simplify certain branches of said code, however, it creates a central codepoint that has to be modified whenever we add a new mixin that has to make use of a classes init methods. This is the same problem that caused player.lua to become over four thousand lines long. I cannot manage that, for several reasons, and it is what I am currently tearing through in my own branch.

I'm going to look into coming up with some sort of hook system for mixins so that they can, at least, have a method that is executed when they're initialized in the order that the mixins are included. I don't want to put down hooks for every method because that might lead to some really ugly things that we should address when the time comes.

And Now For Something Else
Image
Here's an example of the way things are in the test branch. In the middle of swapping out the map system, I found it a little bit easier to just swap out the physics engine to use box2d. Will I keep it that way? Maybe, it would make slopes easier and I don't want to deal with the pain and struggles of getting slopes working on a grid-based collision system. Who knows, it might even lead to angled portals on slopes and the like.

I'd also like to give shouts to Hammy for coming up with sweet graphics for the upcoming animation system. For reference, the "animations" that everyone is used to will be renamed to "events" and animations will be reserved for things like what happens when the player jumps or when a koopa is walking. In the upcoming system, you could specify a graphic for each potential angle (rounded to the nearest degree) that the player points, with a potential for having as many frames in a given animation as the graphicspack desires. This might reduce the complexity of hacks that add or remove frames from an animation while keeping them compatible with the character system.
Last edited by EntranceJew on 26 Mar 2015, 02:00, edited 1 time in total.

B-Man99
Posts: 1868
Joined: 02 Jul 2012, 00:32
Contact:

Post » 26 Mar 2015, 00:44

Hammy sounds cool
Props to you Hammy
Also thanks for the update EJ you're continuing to be awesome
I like how you used _G because _G is super fun to use

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 02 Apr 2015, 02:11

Animations and You
Image
StrawPoll: How should Marin0 handle animations?


The existing animation system is very tightly bound to the logic of the player's state and inputs, it's the sort of (understandably) complex mess that made me put off trying to uproot the logic there for so long. It makes sense to keep these things together, but it also makes it hard to do things like allow passing the control of something to a goomba with much simpler capabilities and then reuse that portion of code in a more complex enemy like a hammer brother.

An example of the new graphics format signatures:
Image

Getting the new format to render:
Image

Getting animated animations (that sounds weird) to work:
Image

Switching animations (manually, via hitting the spacebar): gifv
Image

What you see is pretty straight-forward, it's using anim8 as its underpinnings, but it has some flaws in its current implementation. Before I considered anim8, I was going to use a home-rolled dealio that would make things like frame speed or sizes redundant because it would handle the animation speed and other junk. This would mean that it could switch between animations by just saying switchAnimation("swim") and it would track the rest.
Then I figured "well, there are a lot of animation-specific things going on in the code so we'll probably need configuration" so what you're about to see was an idea that was changed between conception and implementation.
Let's take a look at what the animation signatures look like:

Code: Select all

thisclass.static.ANIM_SIGS = {
	jumpman_super_2hgun_0_idle = {
		frames = {1},
		grids = {1,1},
		size = {32, 32},
	},
	jumpman_super_2hgun_0_duck = {
		frames = {1},
		grids = {1,1},
		size = {32, 32},
	},
	jumpman_super_2hgun_0_jump = {
		frames = {1},
		grids = {1,1},
		size = {32, 32},
	},
	jumpman_super_2hgun_0_swim = {
		frames = {0.3,0.3},
		grids = {'1-2',1},
		size = {32, 32},
	},
	jumpman_super_2hgun_0_walk = {
		frames = {0.2, 0.2, 0.2, 0.2},
		grids = {'1-4',1},
		size = {32, 32},
	},
}
holy wow that's going to be a chore to populate for each potential variable
Vars at play:
  • frames is a table of the frame delays
  • grids is a table of anim8-compatible grid definition strings where the first parameter is the x of the frame and the second one is the y -- since all images in this scenario are linear strips, they can be calculated away using its size
  • size is a table of sizes for all the frames
There are some things that need to be reconsidered, like, in the current solution, speed-based animations (like running) aren't exactly there and we'd need a property per-animation to handle that fancy jazz. If we're going to have more complex configurations, we're going to need to make things a bit easier, like this:

Code: Select all

thisclass.static.ANIM_SIGS = {
	characters = { jumpman = {} },
	powerups = { 
		_global = {},
		super = {}
	},
	holdtypes = {
		_global = {},
		["2hgun"] = {},
	},
	animations = {
		_global = {
			size = {32, 32}
			hitbox = {16, 32}
		},
		idle = {},
		duck = {
			hitbox = {16, 16}
		},
		jump = {},
		swim = {
			speed = 0.3,
		},
		walk = {
			speed_based_velocity = true,
			speed_based_factor = "x",
		}
}
the above could be represented as a json file for all I care, that way graphicspacks can define what they need, kinda like characterconfig
So what does this here do?
  • Initializes a list of characters, powerup states, hold types, and animations.
  • Applies some base properties to a special animations._global attribute, which means for all animations in that base group will have those properties shared between them. This means that other properties only need to be supplied where necessary.
  • All these animations are supplied in a generic environment that sets them as the default for each holdtype, for each powerup, for each character. Kinda like how we just used _global to set attributes across every animation, we just multiplied our base defaults to each possible state we defined and can override them later as we wish.
This is just an example, where we're still automagically handing the aim angle and things are still broken up by the factors mentioned above. Frame count is still unbounded but frame size still needs to be supplied. This goes back to the strawpoll at the beginning of the thread.

Does this make sense?
Is there anything that might make more sense? Are there some special attributes you would like to see that would give you the power to recreate a feature in an existing mod? Are there any attributes you'd like to control? Am I spinning my wheels working on things you're never going to use? Probably. If you have any propositions for alternate config formats (in either lua or json) please post them.

User avatar
MM102
Posts: 970
Joined: 11 May 2012, 06:08
Contact:

Post » 02 Apr 2015, 18:37

While a lot of what your doing is cool I'm worried about how user friendly this mod will be With all its changes. for example you meantioned something about using tiled as an external level editor but most people probably never used it before and leaen how to might be a hassle. Also how hard is it for someone with limited knowledge on coding to figure out how to make animations?

User avatar
Superjustinbros
Posts: 2119
Joined: 29 Mar 2012, 20:39
Contact:

Post » 02 Apr 2015, 20:20

Well this is pretty... interesting to say the least. I'm liking what you're doing so far with the project.

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 03 Apr 2015, 01:13

MM102 wrote:While a lot of what your doing is cool I'm worried about how user friendly this mod will be With all its changes. for example you meantioned something about using tiled as an external level editor but most people probably never used it before and leaen how to might be a hassle. Also how hard is it for someone with limited knowledge on coding to figure out how to make animations?
I can understand where you're coming from and I'm glad you're asking questions.

Tiled (as an external editor) is a consequence of the map format changing. When Marin0 is done, it will also have an in-game editor. (In fact, it has some editor enhancements already.) Tiled will not be the only solution people have for making maps, it is just becoming one due to changing the engine.

As for animations (the thing that sprites do): That is the question I am asking you, based on what I have said so far. I can only make things as easy as people ask me to (within reason), which is why I'm opening this up for discussion. If it doesn't make sense, then people should make alternate prepositions or try and state why they don't understand what's going on. I can't read minds.

Compare this to the existing animation system (the thing that happens when mario walks): they're already inflexible. Making a new player animation is more difficult now than it is with the proposed system. Wrapping your mind around the player's state before you can start mapping graphics to them. If you don't need new animations, then you can change just the graphics and everything will be okay. If you want to change the properties of an existing animation, it should be relatively simple to do that based on any existing examples the game ships with. If you are creating entirely new animations, you will probably need to write a pretty simple mod (as in the kind that will be auto loaded into the engine, not the kind that requires redistributing a new love file) in order to use them. How else is the code meant to know when to use the animation someone just made of mario doing a wicked-sweet dance?

As for events (the feature formerly known as "animations"): Those will still work without any programming what-so-ever. Adding a new one will require programming, because I'm not making the next gamemaker over here (yet).

User avatar
zorua7551
Posts: 193
Joined: 10 Jul 2013, 04:23

Post » 09 Apr 2015, 00:30

my mind is fully facking blown with this, its just awesome with what you can do with it.

Just 1 thing. The controls always remain default even though i set the keys and it says the set keys, Why?

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 10 Apr 2015, 17:38

zorua7551 wrote:my mind is fully facking blown with this, its just awesome with what you can do with it.

Just 1 thing. The controls always remain default even though i set the keys and it says the set keys, Why?
The controller config menu (like most of the GUI) is out of date, if you want to change your player settings you'll need to do it in:
  • %appdata%/options.json - player config options
  • marin0se/globals.lua:controlTable - binds for the controllers and keyboard are handled here
This isn't how they're supposed to be in the end, this is just how they are while the GUI/Interface code is in flux.

User avatar
Wary
Posts: 598
Joined: 03 Jun 2012, 14:30

Post » 24 Jun 2015, 01:07

Is this dead? The last change was done two months ago.

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 24 Jun 2015, 17:15

Wary wrote:Is this dead? The last change was done two months ago.
It's not dead, but I also got tied up with several other projects and work. I can't say for certain how long it'll be until I can start putting more time into this.
I actually started to play around with Unity a bit to see how things are done in other environments just for the sake of learning some patterns that could be useful later. I learned a bit about entity component systems and got a better idea of how to go about that in projects going forward.

This mod itself actually started to reach its (inevitable) tipping point where doing it from scratch became easier, mostly because of bizarre race conditions that spawned from gutting so much code. Hence the creation of a different repo m0de over here that stagnated roughly around the same time. I got to the part where I had to re-implement entities and collisions before I took a step back to see how other people were doing things. I also spotted some upcoming love-based engines and libs that might change things immensely such as Grid engine that makes HUD, entities, and networking really simple which fits into the scope of what my original goal was. I wanted to let Grid mature a bit before going forward on what I already had together, 'cause you can only really restart once especially when engines are involved.

Or I could just do it all in Unity, but I don't think I'd achieve most of my goals easily if I did that.

Edit: As a consolation prize, about a week ago I started integrating neural network code into Mari0 1.6 (inspired by MarI/O) and I might have something to show for that pretty soon*.

*Provided this upcoming game jam I'm competing in doesn't start before I finish that.

CrisZ03
Posts: 4
Joined: 18 Mar 2015, 13:26

Post » 12 Jul 2015, 19:53

How to dowload and run??

RinoTitan
Posts: 1
Joined: 26 Aug 2015, 23:43
Contact:

Post » 26 Aug 2015, 23:46

Is there a 32bit version of ssl.dll ?

User avatar
EntranceJew
Posts: 93
Joined: 05 Mar 2012, 05:37

Post » 27 Aug 2015, 19:26

CrisZ03 wrote:How to dowload and run??
On the github page, click Download ZIP
Image
Then you just launch run.bat.
(If you're not on a windows system, you should just use your regular love 0.9.2 launch method but put the ssl compilation from below in your love directory or something.)
RinoTitan wrote:Is there a 32bit version of ssl.dll ?
Yes there is, however, it's only ever used for the screenshot/crash functionality (due to uploading to Imgur). In the future this will either be replaced with a native love solution or by using luajit-request bundled with its mandatory version of libcurl.

Post Reply