Results 1 to 4 of 4
  1. #1

    K.I.S.A Alpha (v1.0)

    Follow Development

    + Devlog
    + Twitter
    + IndieDB
    + TIGSource

    + Game Maker Community

    Downloads

    Alpha v1.0: Largely an engine tech demo, w/ tutorial. [Download]

    Technical Features

    - Created with GM:Studio

    - skeletal animation
    - ragdoll physics
    - cloth + hair physics
    - delta timing
    - overlay lighting
    - joystick + gamepad support

    Gameplay

    The game is a side-scroller with elements of platforming, combat, and puzzles.

    Description

    K.I.S.A is, essentially, a fairytale. It is a story about knights, kings, princesses, witches, monsters, and heroes, but they are probably not of the kind that you are used to. Like most fairytales, it is likely that this story sometimes says one thing and really means something else - or even a lot of something elses. There is also probably a moral to be found in there somewhere.

    The tale pivots around the titular Kisa, a lowly jester who is accused of witchcraft and sentenced to burn at the stake. The night before her execution a disembodied voice instructs her to break out of the dungeon, and propels her on an epic quest across a treacherous land to rescue a princess from terrible danger.

    Screenshots



    Final Note

    I aim to make this game as technically impressive and beautiful as possible. I'm proud of what we've created so far, and can't wait to see how much farther I can push both GM:Studio and myself. Your feedback is welcome; please let us know how we're doing.
    Last edited by Oracizan; 18-07-2013 at 09:04 AM.

  2. #2

    Ladders in K.I.S.A

    I've got a devlog going on Mutant Dream for this project, and I just made a new post. It's called Ladders in K.I.S.A, and you can read it there or below.

    I couldn't come up with a punny title for this post, which says a lot about how mundane this topic probably is. But I think that if you delve deep enough into the mundane, you find that it actually becomes pretty interesting. That's my justification, anyway, but I think it's true.

    Ladders are pretty common in 2D platform games because of how incredibly useful they are. By allowing a character to move vertically, ladders open up possibilities for level design in a way that no other element can. Jumping is limited in distance. Trampolines can extend this distance, but they don't belong in some environments. Teleporters are also rarely environment appropriate. Flying may open a level up too much, and not all characters have that ability. Stairs and floating platforms are just space consuming, knock-off versions of what you really need: Ladders.

    (“But flying is cool! And trampolines and teleporters don't have to literally be trampolines and teleporters, you blithering idiot.” I don't hate these other elements. They have their times and places, and I actually employ all of them except flying at some point in K.I.S.A. I was trying to make ladders seem cooler by dissing other design elements...and I'm not sorry because ladders are the best.)

    I realized that K.I.S.A needed ladders when I was working on the layout for The Dungeon. My first attempt was a linear progression, a straight left to right line from the dungeon cell to the exit. It was a horrendous affront to the twisty little passages of labyrinthine dungeons everywhere, so I deleted it and thought for a bit. You already know what station my train of thought pulled into: Ladders, all aboard. They were a perfect fit for environment, and they allowed me to branch out onto multiple floors and create a dungeon that actually takes a little effort to escape from.

    The actual implementation of the ladders was tricky. I didn't want Kisa to look away from the screen or otherwise change orientation when climbing, so Elena worked on creating a sideview of a ladder. I then worked out the skeletal animation for Kisa climbing, and it came out looking like this:


    Early view of Kisa climbing a ladder.


    This animation was difficult to get right. Have you ever seen a person climb a ladder? They raise their left limbs up in sync, then their right limbs, then their left limbs again, and so on. To ensure that both limbs stayed on their respective rungs, I had to keep each hand and foot pair a precise y-distance apart at all times. My implementation of skeletal animation, the Puppeteer engine, works by linearly tweening between limb angles. The sine of these angles changed non-linearly, meaning that the y-positions of the hands and legs were changing at different speeds and I couldn't easily coordinate them in a pre-canned animation.

    I ended up fudging it as best as I could, and then doing in-game calculations to measure the distance between the hands and feet each frame. My fudging was close enough that I could then rotate each foot so that the sine of its angle was enough to make up the difference between the measurement and the distance between 5 rungs.

    Aren't ladders fun?
    Last edited by Oracizan; 04-06-2013 at 05:42 PM.

  3. #3

    Lighting in K.I.S.A

    Lighting in K.I.S.A
    From the K.I.S.A DevLog



    Kisa in moonlight and torchlight.

    I had it relatively easy when it came time to create the lighting engine for K.I.S.A. Because the game world is purely 2D, I didn't have to worry about normal mapping, ray tracing, or anything that ends in -ometry. Still, there are a few things about K.I.S.A's lighting engine that I find interesting enough to share.

    I'm not going to get too deep into the base workings of the lighting engine, because what the engine does is very boring and common. In a nutshell: I draw gradients onto a surface (canvas for you non GameMaker folks), then render that surface over the top of the game area with blend modes.

    Below are 3 lighting practices used in K.I.S.A that are not, to my knowledge, common and boring:

    The lighting surface is not the size of the level. In K.I.S.A, levels sizes measure in the tens of thousands of pixels - surfaces of this size would not be feasible. Surfaces take time to draw on and take up memory just by existing, so they should be as small as possible. In this case, I made the surface equal to the size of the game window and always draw the surface at the (0,0) position on screen. When I render the lights, I offset their coordinates so that they are correctly positioned relative to the position of the game window.

    Coders reading this are probably thinking "This is obvious! There's nothing special here!", but I see too many games and tutorials that make use of massive surfaces. I desperately wish that this was common and boring, because it should be.

    The lighting surface is scaled. I lied earlier. The lighting surface is not the size of the game window: it's smaller.

    I think that very few games require pixel perfect lighting, and K.I.S.A is not one of them. It's just not necessary. The beautiful thing about scaling is that it's not a tradeoff between quality and speed, because there is next to no sacrifice of quality. The nature of lighting usually means that scaling does not significantly affect the quality of lighting. Lighting in K.I.S.A is all about gradients, and gradients are one of the few things that interpolated scaling handles very, very well.


    The left image is 50% quality, the right is 100%.
    Can you tell the difference?

    In K.I.S.A, the highest quality lighting sets the scaling at 50% and the lowest at 25%. This means that the lighting surface is drawn at 25-50% size, and then stretched to fill the game window. 50% scaling is nearly indistinguishable from 100% quality, and if I did not have to worry about straight edges, which interpolated scaling does not handle well, I could afford to go much lower.

    Scaling is a really simple way to speed up a 2D lighting engine, with almost no loss in graphics quality.

    The lighting is not static. Light floods into doorways, torches flicker, etc. This is pretty common in 3D games, but I do not see it very much when I play 2D games. I'll let this final image speak for itself.


    Kisa intimidates doors into opening by punching them.
    Last edited by Oracizan; 28-06-2013 at 06:06 AM.

  4. #4
    The following post is from Elena, the artist behind K.I.S.A.


    Hello, Elena here, the artist behind K.I.S.A!

    I'll be explaining how the characters are designed and then developed so that they work with the skeleton animation needed for the game. It is different from drawing a character normally, but still simple in its own way.

    Like any other drawing, each character (I'll be using the Guard in this example) starts off with a sketch to get a basic feel for the character. Even though the characters are only seen from the side in-game, I still like to do a front sketch as well to get a better feel for the character. Once a design is approved, I move on to the line art and colour stage.


    Here is where it starts to differ from a regular flat, static image. Rather than just drawing what you see (like in the sketches), I have to draw what you don't see as well. The back limbs can't be forgotten! Each body part also has to be divided so that limbs and torso can bend. So instead of drawing one segment for an arm or leg, it generally has to be broken into a different section at each joint (foot, calf, thigh, etc). Also, rather than just giving it a straight cut at a limb, I make sure to extend it into a nice circular end, so that when the limb bends, you don't see a break in the artwork and instead see a normal-looking limb. (You can see how I generally split the body and limbs in the image.)


    This is generally all that is needed for the characters. Once each part is lined, coloured, and shaded, it is done. I also keep the shading to a minimum, so that when body parts move, hopefully there's not an awkward shadow in a place where it doesn't belong! The Guard, however, was a special case and so I wanted to talk about him some more.

    While most characters would just have one part for the head (two parts, head and hair, at most), the Guard needed multiple sections as his design had multiple variations and options to create many different Guards rather than one single model, to add a bit of spice to the game.


    Each variation had to work with the next (like each beard or hair style had to work with the different faces), so I kept them relatively simple, but different enough so that they could look like different characters. Even a couple different body types and heights were designed for more variation. This is where the separate parts came in handy, as I only had to draw certain sections (like the face or torso) over again rather than an entire new character to get all the possible variations, which would be a lot once all the different hair, eye, and skin colours are added into the mix.


    So that's how it's done! See? Fairly simple. The only "difficult" thing is to make sure each part is split properly so that it works with the skeletal animation, and following basic human anatomy then makes that a breeze rather than a hardship.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •