next »

[Pehesse]

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

Latest updates here:

06/06/2018: updated the title of the project to use the Quechua spelling of Pachakutiq!

(Up to June 2018: Lots of animation and color updates!)

2017.oct. 21st: The background on backgrounds

Many animation cleaning and coloring updates here

2017.sept 7th: Animation color process timelapse: Warrior

2017.june 22nd: Animation color process timelapse: Acrobat

2017.june 3rd: Animation cleaning process timelapse: Warrior

More animation cleaning and coloring updates here

2017.february: Animation cleanup, Acrobat part 1, multiple opponent combat, bugfixes

2017.jan.21: Walking in water, in wind, gratuitous animation

2017.jan.07: Falling platforms, QoL modifications and combat basics

2017.jan.04: Moving platforms, collapsable floors, moving edgegrab points

2016.dec.17: Warrior moveset part 5: warrior air traversal, expanded acrobat edgegrab, wall health

2016.dec.10: Warrior moveset part 4: ground to air combo

2016.dec.03: Warrior moveset part 3: combat moves, ground and static combos

2016.nov.26: Warrior moveset part 2: damage, block, kick

2016.nov.19: Warrior moveset part 1: move, jump, switch

2016.nov.12: Acrobat moveset part 5: charge jump, flow, music layering

2016.nov.05: Acrobat moveset part 4: wall stick, damage

2016.oct.28: Acrobat moveset part 3: attacks, slides, slopes

2016.oct.22: Acrobat moveset part 2: jump combo, wall rebound, edge climb

Original Intro

Hey all!

I'm back at it again with a brand new project: Pachacuti.



The game is a 2D modular action-platformer, inspired mainly by classic Castlevanias for the system, and by Incan mythology and aesthetic for the presentation.

In detail:

-the game will be linear and comprised of a set sequence levels (10 planned for now). Each level, however, will be comprised of a sequence of "modules" (hence, "modular"): smaller chunks of level design that are picked and placed depending on the player's current playstyle. This will not be "random" or "procedural generation", it will all be hand designed and defined through precise conditions, but the aim for this system is to allow replayability and have the level layouts "change" based on the player's performance and preferred style of play.
The intent is for newcomers to be able to replay and have different and new experiences each time through, and for speedrunners and experts to have an added layer of strategy when controlling their character to try and define which segments of the level they'd rather try to attempt as they're moving through it.

-the main character will be able to switch between two "forms" (think Giana Sisters), one of which will be focused towards combat, and the other towards platforming. Each of the two will have a complete and autonomous moveset designed to be able to overcome most/all of the game's challenges on their own, but the player will also be able to switch seamlessly between the two to expand even further their moveset and possibilities. The aim isn't to be a "puzzle platformer" where situations demand specific forms, but to offer a wide array of challenges that can be tackled through different solutions, which are in turn tracked, to adapt the upcoming layouts and challenges as per the modular principle above.

-the main goal for this game is to offer an experience satisfying both for new players of the platformer genre, and for experienced players to analyse to compete against each other. The biggest victory would be to get it speedrunned at AGDQ! (hopefully, the "awesome" segment of it, not "awful", though we'll see where we end up). For that goal, the game aims to be fun and satisfying to control at a basic level: simply moving the character around should be an enjoyable experience.

-the game will not feature any visible text of any kind: all of the story will be presented through visuals and animations only, and there will be no visible HUD. The player's health will be represented by the height of the sun in the background, visibly setting as they take damage, eventually turning into night, at which point the player will disappear and respawn at the last traversed checkpoint, ready for a new day!

There's lots more design intent and ideas I could cover, but for now, I'll show the current state of the prototype with some gifs, along with the early timetable and milestone goals:

-there's some running...


-...some rolling...


-...some jumping...


-...some falling, or whoops! almost...



-...and some crouching, creeping and crawling.


I started development on the game on October 10th, 2016 and I'm hoping to get it done in 2019. Hopefully before, but solo gamedev takes a while, and prior experience shows I should plan large! :-D

For now, I'm working on a basic movement prototype for the Acrobat form, before moving on to the basic movement prototype for the Warrior form. I'll then expand both prototypes with their additional movesets, and polish them even further through additional detail and transition animations. The first objective is to get a "character control" prototype in a black box environment to playtest and refine the control until it's satisfactory to play on its own. After that, I'll start on rough backgrounds and environments along with placeholder initial level design to get a demo going, to be the foundation of a Kickstarter/Fig/I don't know yet crowdfunding campaign, hopefully sometime in 2017. And then... we reach for the moon!

The game will use the same business and financing model my previous game did (Honey Rose: Underdog Fighter Extraordinaire), the "Pay-What-You-Liked".

It means the game will be entirely free upon release, and it will be funded through the support of players during the course of its development through Patreon and a punctual crowdfunding campaign later on if necessary. You can read more about the model on Honey site or in the devlog here about the game.


If you like this model/game and want to support its creation, be sure to pledge here!

As for this devlog, I'd like it to be of interest to you in regards to the process of development itself, so I'd like to hear what you want to see me write about! Posting progress gifs is all well and good, but I'd like to interact with you all and bring you information that could be of actual use to others, but I'll need your help to know what to write about. So I'm hoping to hear as much from you, as you'll be hearing from me!

[rj]

wait you started dev a month from now

[Pehesse]

wait you started dev a month from now

Whoops, you're right, my mistake :-D Meant October, will fix that right now!

[jamesprimate]

seems like a nice tight concept, and the animations are already cool! i always like UI-free so will be interested to see how that all comes together 

[friendlydog]

offensively well drawn as usual.
will definitely follow your project, as I -unforgivably- missed the last one

[Pehesse]

seems like a nice tight concept, and the animations are already cool! i always like UI-free so will be interested to see how that all comes together 

Many thanks :-) One thing I forgot to mention in regards to the HUD (or lack thereof) is that since there will be no visible information, that also means the design does not rely on visible damage numbers, and that extends to experience points, collectibles, etc... The game aims to be very straightforward, so there will be no level up system/unlockable stuff that turns its progression into a grind! Everything will be available from the get-go, and will be taught progressively to players. That means that experienced (or experimental-minded) players will be able to perform the more advanced actions right off the bat, and access some different modules in the very early levels of the game!

offensively well drawn as usual.
will definitely follow your project, as I -unforgivably- missed the last one

Haha, thanks a lot :-D Though really, Honey just released, so you haven't really missed anything - in fact, it's the perfect time to jump right in, if you're so inclined! :-D

[Fenrir]

Nice to see you back with a new project! Good luck!

About the platforming and movements part, will it be grid based? Are you planning slopes?

[djr]

Are you planning slopes?

Ah, slopes the bane of all platform game developerss 

Game sounds great so far, good luck doing all the hard work.

[Pehesse]

Nice to see you back with a new project! Good luck!

About the platforming and movements part, will it be grid based? Are you planning slopes?

Thanks a lot :-D

The movement and collision will be pixel based (with a single collision box, can't see it in the gifs but it's a separate object for logic purposes), but I'm planning my level design around a grid, yeah, so it's easier to see and read!
And slopes will most likely be in! In fact, since I'm using C2, they're natively in, and from what little I tested, they worked without hitches - I just have to make sure they work with all the abilities and configurations I'm planning to really confirm they're here to say, but so far, they're doing their job :-D
My main source of concern regarding slopes isn't logic, actually, more animation: since I'm using a hand drawn aesthetic with each frame being an individual sprite, I can't possibly remake everything for angled situation, and since I can't rely on IK or other similar techniques, some of the animations might end up looking completely off and justify taking out slopes altogether. But so far, I'm doing everything with them in mind, hope it holds up in the long run.

Are you planning slopes?

Ah, slopes the bane of all platform game developerss  
Game sounds great so far, good luck doing all the hard work.

Haha, yeah, read lots of horror stories about how to handle slopes when starting from scratch, I'm glad Construct 2 handles that part of things on its own :-D

[Tuba]

Woah, new game already?

Nice character design and the animations look great already, hope the level design is on the same level, good luck! 

[Pixel Noise]

Hey! I really like the MC, and the animations looks really slick already. The mechanics/gameplay you are describing sound very cool - and I just learned something about the Giana sisters (I played it when I was like 5; apparently they had different skill sets?).

Following 

[Pehesse]

Woah, new game already?

Nice character design and the animations look great already, hope the level design is on the same level, good luck!  

Indeed, new game already! Can't very well sit on my thumbs now that Honey's out - she doesn't need me to hold her hand anymore :-D

You're right, level design is going to be the thing that makes or breaks the game, which is why I'm planning large time-wise to make sure it's tight and fun to play :-D

Hey! I really like the MC, and the animations looks really slick already. The mechanics/gameplay you are describing sound very cool - and I just learned something about the Giana sisters (I played it when I was like 5; apparently they had different skill sets?).

Following  

Many thanks :-D

For the switching, I was referring to the latest Giana Sisters game (Twisted Dreams, I think it was called?), as I'm not sure the two had different movesets in the original game (it was more of a powerup system akin to Mario, wasn't it? Well, either way, here it's going to be freeform switching an any time with different movesets! :-D)

[Fenrir]

Nice to see you back with a new project! Good luck!

About the platforming and movements part, will it be grid based? Are you planning slopes?

Thanks a lot :-D

The movement and collision will be pixel based (with a single collision box, can't see it in the gifs but it's a separate object for logic purposes), but I'm planning my level design around a grid, yeah, so it's easier to see and read!
And slopes will most likely be in! In fact, since I'm using C2, they're natively in, and from what little I tested, they worked without hitches - I just have to make sure they work with all the abilities and configurations I'm planning to really confirm they're here to say, but so far, they're doing their job :-D
My main source of concern regarding slopes isn't logic, actually, more animation: since I'm using a hand drawn aesthetic with each frame being an individual sprite, I can't possibly remake everything for angled situation, and since I can't rely on IK or other similar techniques, some of the animations might end up looking completely off and justify taking out slopes altogether. But so far, I'm doing everything with them in mind, hope it holds up in the long run.

Good choice for Construct2! And yep, animations will probably be your main concern for your level design. Maybe just keeping slopes to "slide" on them?

[chrilley]

It's so nice to see such dedication for character animations. This really sticks out in a great way, keep it up!

[Pehesse]

Good choice for Construct2! And yep, animations will probably be your main concern for your level design. Maybe just keeping slopes to "slide" on them?

That's definitely an option, yeah! Basically, my main reference for slopes at the moment would be Rayman 1, with low angled slopes you can normally traverse, and high angled/explicitely "slippery" ones you can only slide on. That'll require some additional differentiation, since so far in my tests C2 doesn't care about angle, as long as it's not vertical (leading to some Skyrim-esque slope climbing :-D) but that's really more of a level design matter - as long as I don't use steep slopes, everything should appear fine!

It's so nice to see such dedication for character animations. This really sticks out in a great way, keep it up!

Thanks a lot :-D I believe character animation plays a big part in the enjoyment of a character driven game like this, so I'm hoping to make it fun simply to have her move around!

[Pehesse]

New week, new gifs!








In order, those depict:

-the triple jump recoil combo, taken straight out from the Smurf's Nightmare and some Donkey Kong 94' on gameboy. I didn't go for the usual "double/triple jump in the air" movement, as I'm aiming for a tactile feel with the environment: I'd like the player to make use of the temple and consider its layout, not simply navigate through it.

-the wall sliding/wall kick system. The way it works is by pressing the stick in direction of the wall, you'll "stick" to it for as long as you press, and releasing it will let you go back to falling. I feel this gives more control that a "one and done" stick motion where you grip even while you release the directional control. Wall kicking uses the control stick and jump button to try and offer some degree of control to the player: you can wall kick by keeping the direction pressed and jumping, or use a very rapid timing of no direction+jump or even opposite direction+jump to eject. No matter the scenario, I'll try to adjust the horizontal speed and direction to be appropriate, and even use the length of the jump button press if no direction input is registered.

-edge hanging: this one works by stopping the platform behavior (the main one behind the character's movement) and placing the character in an "EdgeHang" state with different controls. The player can climb up, drop down or wall kick horizontally, and each of these will restore the platform behavior: immediately in the case of wall kicking and dropping, and after the climb is done for climbing. For climbing up, it's a simple check of the Y value for the edge hang collision zone and the edge hang player collision box: once the player is "climbing", I check if the Y value of the player is greater than the Y value of the edge hang collision zone (the origin is on top of the collision zone, and at the bottom of the player's collision box), when not I move the player Y up, and when aligned I restore the platform behavior to let it back on solid ground.
The animation is usually played by placing the animation sprite on the controller box's origin at every tick, but for climbing, I dissociate the two so the animation starts playing at the hang starting point, but doesn't follow the box as it climbs up, so it's easier to get the origin point of the animation itself right.

Considering edge hanging, I'm currently using two modes: "Auto" and "Manual". "Auto" mode, as its name implies, grabs every ledge in sight when the conditions are met, which makes for super responsive control but can lead to slight frustration when attempting to jump over low height ledges, but still have a Y low enough to register as a hang attempt. Manual mode requires an additional button press to register a ledge grab, which makes it more challenging (too challenging, perhaps), though one could argue more player involvement is also more interesting. It negates the "low hanging" issue, as the player is in full control of when and where they want to attempt to hang. However, it currently doesn't play an additional animation to show that the "hang" button is having an effect, and having different animations playing for each possible jump stance might end up jerky and cause some problems with the fall animation playback.

So I'm looking for some opinions here: of the two, which sound like it appeals to you the most? Would having the two as a togglable option be an interesting feature (that's how it currently is for testing)? If using "manual" mode, do you think I should add in additional animation to showcase the effect of the button (the obvious answer should be "yes", but keep in mind it has potential ramification with all systems involving jump/fall)

[NoLocality]

Dig those animations! 

I especially like the close-call at ledges animations (both), the crawling animation (awesome perspective as apposed to seeing her directly from the side and the unusual way she crawls shows physical strength) and her feet-first-flip-jump is badass.

So I'm looking for some opinions here: of the two, which sound like it appeals to you the most? Would having the two as a togglable option be an interesting feature (that's how it currently is for testing)? If using "manual" mode, do you think I should add in additional animation to showcase the effect of the button (the obvious answer should be "yes", but keep in mind it has potential ramification with all systems involving jump/fall)

If given the choice I would go first:manual because options, unrestricted level design, etc...second:toggle because options...third:auto because that low-hanging edge thing could indeed get annoying if it's bugging you while playtesting.


Perhaps consider something like a "soft-toggle" if the timing in manual grab mode is truly to difficult.  Something like if the jump button is being held in mid-air, then she will grab ledges automatically or something similar...I bet you could do something like this using the buttons the player already uses and not mess with her other mechanics.

I think you can have the best of both worlds without having to assign a whole button to toggle basically.


Anyways very nice start with this.

[Pehesse]

Dig those animations!  

I especially like the close-call at ledges animations (both), the crawling animation (awesome perspective as apposed to seeing her directly from the side and the unusual way she crawls shows physical strength) and her feet-first-flip-jump is badass.

So I'm looking for some opinions here: of the two, which sound like it appeals to you the most? Would having the two as a togglable option be an interesting feature (that's how it currently is for testing)? If using "manual" mode, do you think I should add in additional animation to showcase the effect of the button (the obvious answer should be "yes", but keep in mind it has potential ramification with all systems involving jump/fall)

If given the choice I would go first:manual because options, unrestricted level design, etc...second:toggle because options...third:auto because that low-hanging edge thing could indeed get annoying if it's bugging you while playtesting.


Perhaps consider something like a "soft-toggle" if the timing in manual grab mode is truly to difficult.  Something like if the jump button is being held in mid-air, then she will grab ledges automatically or something similar...I bet you could do something like this using the buttons the player already uses and not mess with her other mechanics.

I think you can have the best of both worlds without having to assign a whole button to toggle basically.


Anyways very nice start with this.

Thanks a lot! Appreciate your thoughts on the "edge hang" issue, too! Using the jump button is indeed something I can attempt. It's less a matter of timing, and more of a matter of having to press a button at all, but maybe having it on jump will make the manoeuver easier - though overall, I still prefer the auto mode, I'll admit :-D I tried adjusting the Y values to try and cover edge cases when going through the top of the collision zone, but that's not satisfactory either as it means some legitimate attemps to auto hang while coming from above will not work. I'll also attempt to add a "fast climb" move (maybe by holding jump) to make it snappier, and the auto catching of ledges less of a cut in speed!

I think I'll simply leave the two modes as togglable for now, and will keep looking into the "issue" as the systems develop further, see if they interact badly with some of the others, or if player feedback shows a clear preference!

[Phonetic Hero]

Really digging the concept here, especially as a fan of both the Castlevania series and the culture and aesthetics of South American native peoples.  The animations are looking great and the modular level design sounds incredible, definitely keeping my eye out for updates as they come!

[Vilanat]

Those animations are top notch!

Did you try to adjust the character angle to the slope angle? might result in less clipping when climbing/walking on slopes.