A-RPG Gamekit

[LaDestitute]

Update on 4/10/2017:

Since this has been asked multiple times: there is no ETA. I don't want to set a solid ETA or deadline and put myself over in on my head. The gamekit will be done when it's done. Possibly considering launching this on Steam too, as it will include an editor exe so that endusers do not need Construct 2.

Latest Build: v1.1h1

Discord | Patreon | Trello (Feature Roadmap & Quick-Changes Observation) | Gitlab (main source of dev-progress) | Issue Tracker (report bugs here)
YouTube | Twitter | Twitch | Facebook | Devlog Blog (NEW!)

Latest news:
*Older dev-builds publicly released for download (3/10/2018)
*Hotfix for v1.1 pushed and released (3/08/2018)
*v1.1 alpha released for download, is a big milestone as it's intended as the second to last build before launch (03/05/2018)

This is a gamekit/SDK that plays like oldschool action-roleplaying games, such as the classic 2D Zeldas and also possibly a dash of Secret of Mana influence. A Link to the Past is where most of the influence and design will be but I'm considering implementing gameplay mechanics from the other games, including the 3D ones.

This started on the 22th of February (2016), and the project is nearing completion after almost two years. It is past the feature-complete milestone, such as basic a-rpg combat, some functioning items, rebindable keys/gamepad support, neat engine tricks (diagonal slope sliding, smooth movement/movement corner rounding, ledge jumping, bridges with under/over tile-priority), savedata support, dungeon mechanics and an inventory system. A full version (capx and all) will be released on the Scirra Store and possibly Steam once nearly all of the gameplay mechanics are in and bugfree.

The main thanks, as these two are the most important:
Scirra, for this awesome game engine that is so amazingly capable, Construct 2 is one of the best engines I've ever used in recent years
Nintendo, for the video game series that ahem is...a legend

But also this amazing community + others:
amiltonbr, for the original base this gamekit is partially based on (although, the capx has been stripped of most of that, save for the 8d movement)
schueppe, advice and discussion with me on how to handle ARPG mechanics in Construct 2
dpyellow, for his old Zelda capx I found (it helped me integrate a few things, namely the pause menu, shooting/passive AI and bombs/bow/boomerang)
R0j0hound, for his sliding against diagonal slopes example
C-7, for an example of ledge jumping and dynamic lighting
bbenny93, for the new replacement dialogue system (no more using a store-bought one, yay!)
patrons, thanks so much for the spare funding and dev-support/following
all those that showed interest here or elsewhere, thank you for letting me confirm my belief that this gamekit would do well

Screenshots and videos (five latest videos first):
Full map item (more dungeon mechanics, last video for a while)
Video 7 (unstable build, dungeon mechanics)
Video 6 (latest, build 0.9)
Video 5 (build 0.8)
Video 4 (build 0.7)
Video 1 (very early build, when I first started)
Video 2 (mid-build)
Video 3 (build 0.6)
Dev Livestream
Dev Livestream 2 (old unstable build, 6/9/2016)
Images/GIFs (lots, all the way back to build 0.3 from back in Feb 2016)

A list of currently implemented features:
*Tilesets for mapping, with original 16x16 resolution tiles (two tilesets, one on bottom for mapping, and one on top for setting collision detections for walls, etc)
*Eight directional movement with proper animation support
*Variables, gametext, and item configurable gamedata stored in arrays, set predefined by loaded JSON files (planning to replace them with hash-tables)
*Basic pickupable overworld objects (keys, rupees (green, blue, red, purple), hearts, etc)
*Signs, with proper textbox, font, letter by letter text, proper pausing and skipping
*Pushable blocks, they move 16 tiles per push, have animations and sound, and will not move if against an obstacle
*Switches, enough said (trigger on step, can be used to solve puzzles and can be set to deactive if stepped off of)
*Chests, animations and sound, can be locked
*Liftable and throwable objects (pots and grass as example)
*Zone based camera, restricts a zoomed camera to the current room
*Functioning doorways into other rooms (if on a big map, such as one floor of a dungeon or Hyrule Castle)
*Proper collision detection (solid walls, working stairs in a room, etc)
*Heart Pieces & Heart Containers
*Hearts and magic bar system
*Multiple AIs (standard hostile AI for Green Soldier, neutral AI for Buzzblob, ranged AI for Octorock, and example boss AI!)
*Functional Lamp, Bombs, Boomerang, and Bow (uses a function that different outcomes depending on which object is equipped, so it's unified and self-contained)
*Basic combat (collision detection, sword swinging, etc)
*Inventory system (moving cursor, cursor bounded to menu boundaries, sound effects, flashing cursor, and setting item to active use slot)
*Sliding against diagonal slopes
*Jumping from ledges
*Working bridges that can be passed under/over
*Map-changing (such as going inside of houses)
*Lighting system (like in A Link to The Past's Hyrule Castle Sewers)
*Proper title/menu screen with save system support that uses LocalStorage, i.e similar to browser cache but is not lost upon clearing cache (also erasing/copying saves)
*Rebindable keys and gamepad support
*Grid movement system accurate to ALttP, which includes smooth movement (see this gif for example) and sub-tile movement (Link just doesn't move 16 by 16, he can also move a max of four pixels if the input pressure is gentle enough)
*Weighted random drops from pots and grass
*Dungeon mechanics (obvious, but example puzzles, floors, map/compass/keys, simple example boss AI etc)
*Object-environment interactions (such as lantern flames destroying grass-objects)
*Rudimentary debug and config functions (will need more work)
*Hash-table storage as reference for the game's many variables, self contained so the SDK is more self-reliant towards use of variables with code (such as to check a variable for a value or as a condition trigger)

Partially implemented/unused:
*Doorway transition animations
*Compiled tilemaps like this

Planned Features (in order of priority from greatest to least):
*Inventory overhaul (second page, spoils bag ala FFXII's loot system)
*Equipable armor/weapons/etc
*Combat overhaul
*Optional day/night system (can be disabled)
*Expanding gamedata jsons and eventing to include extra mechanics from other Zelda games such as Fire Arrows, Lens of Truth, and Pictobox)
*Detailed starter/example map
*In game engine edit-mode (not sure if feasible, I have a way but requires extra monetary investment on my part)

 

[Xhukari]

I swear everyone does that wall tilemaps & graphic tilemaps split. XD
Wished Scirra made it so you could have some tiles in a tilemap not register collisions... Would save on having two separate tilemaps then.

The pictobox, what is it supposed to do? Because you can easily make Construct screen cap the canvas and store it in json. I believe I do that in one of my abandoned projects.

 

[LaDestitute]

Yeah, was just gonna have it save the canvas and have it download a screenshot for the player but I was thinking of adding additional events that check for "X is on screen" and add some sort of tag stored in a variable, to emulate the Pictobox quests.

 

[Xhukari]

Oh that's a neat idea. Sounds pretty easy to implement too!

So, I have finally gotten around to watching the videos... I presume the 30 fps is due to capture, and that the game actually runs at 60 fps?
I notice the gliding along the diagonal walls is still kinda... blocky. I wonder how you've got it working? I presume you have a way of detecting which way to slide them? I ran a quick test and found just using the Simulate Left / Right actions of the 8 Directional behaviour made a seamless glide.

I also noticed your player was always on top off the enemies, even when the enemies should be on top. A quick fix for that is to have a family which has all the objects which could overlap each other. And then running that family through an Ordered For Each loop, which you order based family.Y, with the ascending order. And for each pass, put them to top of the layer.

Also did you want the push blocks to just 'jump' to their new location, or for them to glide there? Because you could easily get them gliding with the the MoveTo behaviour which can be downloaded. (I use it myself). It's great, because you can define a relative 'move to' point in coords, and it moves there, complete with speed and optional (de)acceleration. And the behaviour has a 'On land' condition check, where you could re-enable it to be pushable with an instance variable, or what have you.

And your pots seem to wobble a bit; is that intended? I would imagine making a new imagepoint in the player's holding hands, and just pinning the pot to that image point (by position only) would fix that.


What you've got looks great; I could never imagine making some kit though, does it add much additional work?

 

[LaDestitute]

Yeah, the 30 FPS is just due to video capture, so besides the frame increasing from 0 at start up, it's almost always 59-60 FPS. I'm experiencing some occasional dips into 45-50 FPS (in the main room with the soldiers) or so, but I'm not entirely sure what's the cause of that. I have everything split into separate event sheets (where the core one, Main, includes the rest) but those don't seem to really affect my FPS at all.

I'm using a method of a bunch of complex events made by R0johound, and I can post a link to his capx example of diagonal slope sliding if you want.

As for the player being on top of enemies, I'll try to see if I can fix that with your solution. I have a System loop ("For each Solids order by Solids.Y ascending") where Solids is a family, with all the solid objects, such as chests, signs, pots, etc. Based on what's overlapping what at Y positions in sub-events below the main loop, I either move Link or the interacting object to the top or bottom of the "Objects" layer to simulate Link going behind objects, having switches under his feet, etc, as all objects are on one layer.

I want to avoid including any third party plugins or behaviors for ease of use, so the gamekit can be fully usable out of the box without the user needing to download additional files besides the capx that will be included. The way I'm doing the blocks is setting their X or Y position like: Self.X/Self.Y +16. I could probably split it into +8 or +4 to make it look smoother and just repeat said strings of events for the set position. Though, looking at A Link to the Past gameplay, blocks do actually kind of move in one 16x16 tile increments. I still have one issue, sometimes the block pushing sound triggers if the block is up against a wall or another block, and I'm not sure what the cause is. My block code is kind of a jumbled mess atm and doesn't use functions, save for picking by UID.

Not intended. To explain exactly, what I'm doing is displaying an animation first (Link lifting), then destroying the "pot" he's trying to lift. A new pot is then spawned, and I use int(Pot.UID) to grab the UID of the newly created pot and store said number to a variable. Then for all the events (throwing, etc), I include a "Pick instance with Pot" where Pot is the name of the global variable used to store the UID of the pot that was created. As for the wobbling, based on certain conditions (animations, etc), the Pot's new position is set to an imagepoint on top of Link's head while he does lift-walking animations. It's probably just more of a matter making sure the image points are precise.

Not much work, besides you know, emerging unexpected bugs (as is their nature, you don't notice bugs generally until you find them occur) and making sure that, when I import new systems (such as from example capxs), that they play nice with the rest of my events.

 

[Xhukari]

I should note, I haven't played 2D Zelda before; which is probably why the push block feels so jarring to me. So I guess it comes to how faithful you want to be to the originals. Hrm... since this is a kit, perhaps you could supply both, and just let the person who is using it, choose via a global variable?

The pot thing sounds pretty complicated. Why are you destroying the old one? Is it a tile? Is it a different object than the held one? Would it be simpler to just have the jar move and turn on / off things like collision and behaviours?

I dunno, your depth thing seems odd; why any checks of overlap? Hrm... where are the default imagepoints on your objects? I have mine all at the base of the object (the align to bottom option). That way it just becomes a case of math & logic; a lower Y coord, means it should be below. So working from the lowest value to the highest, it puts each one in turn, to the top.

My code for the depth thing is as simple as a single 'for each ordered' event and the single action of 'send to top of layer', and it works a treat.

Seeing the capX could be useful.

On a bit of a tangent... I wish we could have families of families and families of sprites & particles. Including particles into the whole depth thing, isn't easy.

 

[LaDestitute]

Regardless, here's a video of block pushing from A Link to the Past. Yeah, I could probably do that, as for providing different options for block pushing. I was going to go along the idea of including certain systems or changes that could be user toggled in the events, such as having the magic meter disabled on startup and instead have it enabled when Link obtains his first magical item, whatever it is, or even have his magic meter granted by the Great Fairy. I still remember that from Majora's Mask...

Hmm, you have a point there. I made the pot lifting by modifying and reverse engineering a public Zelda bomb example I found a couple weeks ago. I could see if just moving the pre-existing pot to Link would work, probably work, thanks for the suggestion. I'm not really sure why I'm destroying the old pot now that you've brought it up, it's purely for picking by UID maybe...just to make sure the associated lifting/throwing mechanics don't mess with any other pots/bushes/etc. Far as I know, I've seen the creating a new lifting object and getting the UID in maybe another example, just one. The only other thing is that the Pots, are of course, solid by default, and they won't fly correctly unless Solid gets disabled beforehand.

Here's a screenshot of how I'm handling the family y ordering stuff, if you want to provide suggestions or input, which I'm happy to hear.

Spoiler

I probably don't mind sharing my capx, but at least not publicly. Not that I want to copyright my methods or anything (that be silly), it's just a work in progress and a lot of my code is either messy and untidy (besides using groups and all) or some are just more hackjob attempts to make a mechanic work.

Edit:
Here is my method of the diagonal slope sliding, or rather what it's based on
https://dl.dropboxusercontent.com/u/542 ... _plus.capx

 

[Xhukari]

The pot solid fly thing is a non-issue; you can turn off the solid behaviour before you move the pot to a held position. (Most likely on the key press.)

I have to ask; why don't you want to use more layers? Layers could make your life easier. Sure the free Construct can only use 4 layers, but it cannot use families at all, so that would be a moot point.

It looks like the switches are never on top of anything else (or solid), so why not just take them out of the solids family and at the start of the layout, send them to the bottom of the layer?
Also with held pots and hearts, why not have a layer above the normal object layer, and just send them to that layer? Or if that causes issues with some of the overlap which I don't know about (pillars maybe?). Perhaps after running the overlap event, just have it place held pots & hearts on top regardless.

Taking into account either the moving to another layer, or just setting the held pots / hearts to the top of the layer. And that your Default imagepoint (0) is aligned to the bottom of the object. This should be able to replace all your overlap code.

Spoiler

I like to have a family that is solely used for this overlap process, that way I can add any sprite that has the bottom imagepoint to it, and it would work flawlessly, without impacting other aspects or families.

I had a look at the capX, and it does run smoothly there. But what I noticed, is that it also replaces the solid behaviour entirely, and seems to work best with square player objects, rather than rectangular (due to the circle it uses for the collision). I presume some of your code works on solids, due to the pots etc? So it seems like a bit of a clash is happening here. Also I wonder how AI pathfinding would work with them...

 

[LaDestitute]

Apologies for the long delay. (also sent you a pm with the link to my capx of the project)

Yeah, I think that's what I meant, I disable it before it gets thrown (as it causes Link to get pushed otherwise if enabled)
I use multiple layers (top to bottom; Top HUD, Bottom HUD, Objects, SolidTiles, Tilemap), but I'm not sure if you knew this, but you can easily manage objects on one layer, regarding things like the player, signs, enemies, etc, just using a family to order them based on top/bottom layer. I started using your method partially, so thank you for that. I hope you know, but I have the paid version of C2 (was also an early adopter)

Yeah, switches are not in the Solids family but I had to make subevents in the family ordering to make sure they show up under Link properly, otherwise they appear on top. Just one subevent, not much.
I think you should see my pot lifting system as is, as you might want to see how I setup it specifically first. As said before, it was a slight hackjob attempt at reverse engineering and modifying someone else's Zelda bomb events, so it's a bit weird in setup.

I guess I'm just prone to not wanting to implement different methods for certain things, due to worry that it'll break a pre-existing event system of mine. I don't mind the process of debugging and fixing at all, don't get me wrong, but still.

 

[Xhukari]

Ah! That lil PM count is so tucked away, I didn't even notice the first one! XD

So after giving a quick look, I have to wonder why you do not use the tilemap object in this, for building the backgrounds & general wall collision? What if a singular map was to be very big? If I recall, Construct 2 either doesn't allow, or struggles, with images bigger than 2560 in width and/or height.
Also, what was the reason behind all the rooms being on a singular layout? If each room was its own layout, you'd have less objects being processed, which improves performance and allows the option of alternate rooms. Like, you could have that when they go through door X, it checks variable Y, and will go to either layout A or layout B, based on that variable...

I noticed a couple other things too...

• When Link starts to push a block, he can still move away from the block, and of course, after a short time, he and the block suddenly move in the push direction.
• In the room with the soldiers, Link cannot go behind the pillars. (Perhaps make them a placeable solid with a reduced hit box to the bottom section?) Or if that is not what you're looking for, then perhaps fix the gap between the well and pillars; it looks like there player can go between the well and pillar, but is met with an invisible wall.
• The soldiers behave weirdly when hit by a pot, especially if that pot sends them into a wall. I don't know how much it would help, but perhaps have a timer on the Soldiers, which is triggered when struck by the pot, which temporarily turns off their AI?
• Also I strongly suggest a customisable control scheme; rather than hardcoding it to specific buttons. Use the Keycode events. And then have variables for each of the buttons. Like I have a cLeft variable, which has the value of 65. (Which is A). This link should help with that implementation. http://www.asciitable.com/ (You're looking for the Dec value).

 

[LaDestitute]

The first layout is just a test, I was just being lazy and needed a full level based layout to play around with as I did debug tests and added new features, I plan to switch to actual/compiled tilemaps later on, right before I implement switching from layout to layout.

Yeah, I'm still trying to sort out the bugs with the pushing blocks. I'm not sure how to fix that, despite that I have it set to ignore player controls.
That's more like a collision issue, still need to fix it.
Thank you for the pointers on the last two things though, those are really good methods.

 

[LaDestitute]

Steaming some game development in a moment for this:
https://gaming.youtube.com/user/SparktheYoshi/live

 

[LaDestitute]

Finished a new build:
https://www.youtube.com/watch?v=u16Hjy4lvPs

 

[LaDestitute]

Bumping this up. New build, and a major one (next build is...dungeon mechanics!)

https://www.youtube.com/watch?v=nKY2KY9sBFc

 

[Xhukari]

I'm liking the progress! Keep it up!

 

[LaDestitute]

An invite based closed-alpha prerelease is now available for my A-RPG Gamekit. To get the download links (which include links for osx, windows, and linux), send an email to: lad3stitute@gmail.com

 

[LaDestitute]

Okay, it's been what, almost a year since I came back? Wow. Well, here's what's up as of lately in that span time and now.

*The gamekit jumped up in two builds in said time span, from v0.9 to v1.1. v1.2 is in the works at the moment and is intended as the last public test build before release, short of final bug fixing and polishing.
*The gamekit changed from distribution of test builds via email to public releases available on the gitlab, which can be found in the OP post.
*Said gitlab also has all previous test builds for download, besides some really old ones I can't find. That's every build besides v0.4 and v0.6, which I do not sadly have.
*You can find the latest public test build here: https://gitlab.com/LaDestitute/A-RPG-Ga ... ags/v1.1h1
*Some of the major new features from v0.9 onward include new A-based pathfinding enemy AI, full use of dictionaries for variables (no global vars!), proper savedata implementation for slot-1 and a reworked in-game debug menu + command console (yay cheats!)
*Currently, inventory is being expanded, which you can see below. Multiple pages + item categorization (ala Breath of the Wild) is implemented now, with equipable equipment (no more static equipment) and crafting soon to follow.

 

[vovuliso]

I'm glad to see an action rpg on the forums. Good luck developing. Very nice looking game so far. :heart: :heart: :heart:

 

[LaDestitute]

It's been a while since this has had any progress. My depression took a severe beating during early August and it became so bad I became a recluse for a full month.

Anyhow, I buckled down to get some major legwork done and this includes:

*Proper enemy stats metadata implemented
*New damage calculation system that uses player DEF/ATK and enemy DEF/ATK
*Overhauled item drop calculation + luck stat
*Enemies now have health meters visible
*Status effects implemented
*Bow improvements (holding the use-item key charges the bow, player can now move using a bow, charge corresponds to damage so longer charge=more damage and added secondary arrows (fire) as a test)
*Combat gamefeel tweaks and improvements, mainly: player now stops if they hit solid objects during receiving knockback, increased swing speed, added an 8x8 box to the end of player line of sight to to facilitate easier hit-detection and made enemies slower

 

[LaDestitute]

New devlog post!
https://ladestitute.itch.io/a-rpg-gamek ... -edit-mode