Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1395937 Posts in 67320 Topics- by 60448 Members - Latest Member: Arc

October 17, 2021, 02:03:48 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsK.I.S.A Alpha v6.4 [Download]
Pages: [1] 2
Print
Author Topic: K.I.S.A Alpha v6.4 [Download]  (Read 9509 times)
Oracizan
Level 0
**



View Profile WWW
« on: May 10, 2013, 03:09:28 PM »



K.I.S.A is an interactive fairytale about knights, kings, witches, princesses, and a girl who hears a voice.

A lowly girl named Kisa is accused of witchcraft and sentenced to burn at the stake. The night before her execution, a disembodied voice speaks to her and charges her with a quest: escape from her dungeon cell and traverse a treacherous fantasy land, to rescue a princess in terrible danger.

Many perilous obstacles stand between Kisa and The Princess. She will need to be equal parts swift, stealthy, steadfast, and shrewd to complete her quest. She'll have help in the form of The Voice, an enigmatic guide with plenty of advice - and it's always a good idea to listen to a disembodied voice that only you can hear, right?

K.I.S.A is currently in closed development. Releases for K.I.S.A are planned for Windows, Mac, and Linux. You can follow development on the Devlog, Twitter, IndieDB.

Download K.I.S.A

Alpha v6.4: [Windows 7/8] [Windows XP]

Technical Details

K.I.S.A is built in GameMaker: Studio on the custom Puppeteer engine, which combines skeletal animation and physics to create a dynamic and responsive world. Because animations are based on models and angles instead of sprites, every action is fluid and the characters are as beautiful as the painted world that they inhabit.

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 GameMaker: Studio and myself. Your feedback is welcome; please let us know how we're doing.
« Last Edit: December 12, 2014, 10:51:10 PM by Oracizan » Logged

s_l_m
Level 8
***


Open to collabs


View Profile
« Reply #1 on: May 19, 2013, 07:49:44 PM »

I actually really enjoyed that demo, if this became a full game I think it could really be interesting. Good luck
Logged

Think happy thoughts.
Oracizan
Level 0
**



View Profile WWW
« Reply #2 on: May 23, 2013, 10:59:35 PM »

Thanks, s_l_m. The aim is for a full game, with 10 chapters (levels) planned.
Logged

Oracizan
Level 0
**



View Profile WWW
« Reply #3 on: June 04, 2013, 12:25:52 AM »

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.Aand you can read it there or below.
 
Quote
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?
Logged

Oracizan
Level 0
**



View Profile WWW
« Reply #4 on: June 27, 2013, 08:46:43 PM »

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? (Click to enlarge)

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 Edit: June 27, 2013, 09:04:38 PM by Oracizan » Logged

Oracizan
Level 0
**



View Profile WWW
« Reply #5 on: July 16, 2013, 07:39:16 PM »

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.
Logged

BomberTREE
Level 9
****



View Profile
« Reply #6 on: July 16, 2013, 07:56:35 PM »

I think the biggest challenge art wise will be to create a world to match the characters, also I enjoy the lighting.
Watching you  Blink  Smiley
Logged
Jutaris
Level 0
**


View Profile WWW
« Reply #7 on: July 16, 2013, 09:08:30 PM »

Had a go of the demo, It's a neat little project you have here and I'll be curious to see where it goes.

Keep it up!
Logged

Conker534
Guest
« Reply #8 on: July 16, 2013, 09:23:38 PM »

Once I learned I could roll forever, that is just what I did.

Feels good though.
Logged
Oracizan
Level 0
**



View Profile WWW
« Reply #9 on: July 17, 2013, 01:09:32 AM »

Whee. Oracizan here. Perhaps we should have Elena blog more often, since people respond to her posts. Grin

Thanks Conker & Jutaris. Rolling is pretty nice, but midair flips are where it's at. A new alpha demo is coming very soon, so keep your eyes peeled.

Care to elaborate on what you meant, kitheif? I might be misinterpreting your question, but you can check out examples of the backgrounds and tiles we used by looking at the screenshots in the first post and the Lighting post. Anyway, thanks for the eyeball. Blink
Logged

moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #10 on: July 17, 2013, 06:24:03 AM »

this is interesting for an oldfag like me with memories of games with huge sprites such as sword of sodan and altered beast.
I like this artistic concept, even though it will probably attract you a lot of critiques from more mundane players who won't 'get it'.
It will be interesting to see where you take this.
Logged

subsystems   subsystems   subsystems
BomberTREE
Level 9
****



View Profile
« Reply #11 on: July 17, 2013, 02:11:38 PM »

What I was trying to say was that In the lighting gif I saw how much potential the character had, the way the hair and cloth moves is great and works wonders with the dynamic lighting!

But I feel that the scenery should show as much history and work as the character does.
The current infinite tiling background with few assets was a bit of a turnoff for me, you could avoid that by adding borders of wood around the edges of in door areas like The Archer did (Check the devlog) and assets comes in time of course. And then maybe use the lighting to add a fog of war where you can't see on the other sides of doors until you open them.

I'm excited to see future updates
Logged
Oracizan
Level 0
**



View Profile WWW
« Reply #12 on: July 18, 2013, 01:19:44 PM »

Thanks, moi! Everyone keeps comparing this game to ones that measure their age in decades...I don't know what that means. Shrug

kithief: I checked out The Archer devlog, but I couldn't find the wood borders that you were talking about. Example? Overall, I'm pretty happy with how the indoor scenes turned out. To me, it looks decorated without looking cluttered. One change that I made in the next version, however, was making the windows transparent and adding a sky background outside. I hope that you'll be much happier with Chapter 2+, most of which take place outdoors.

You can see a bit of a fog of war going on in The Tutorial: it was completely black at first, but then I opted to just hide characters + objects and make it about 75% alpha.
« Last Edit: July 18, 2013, 05:01:42 PM by Oracizan » Logged

BomberTREE
Level 9
****



View Profile
« Reply #13 on: July 18, 2013, 07:33:48 PM »



That's what I meant by adding borders to the indoor areas.

And yeah that was actually exactly what I meant by fog of war (earlier messages typed in class, my apologies)
I enjoy the look and feel very much, the physics remind me of an upgraded happy wheels physics sort of game! The characters scare me with their never moving eyes but that would probably be a lot of work to add. I suggest showing your environments in gifs for now on because those screenshots did not capture the glory of how it actually is haha!
I'm really hoping you take advantage of the physics engine too Oracizan Smiley
Logged
Oracizan
Level 0
**



View Profile WWW
« Reply #14 on: July 18, 2013, 09:28:38 PM »

I'm going to say 'nah' to the wood borders, but blinking can definitely happen. I always try to add in things like that, because I find tiny details beautiful. Thanks for the suggestions!
Logged

BomberTREE
Level 9
****



View Profile
« Reply #15 on: July 18, 2013, 09:40:19 PM »

I feel like borders of any time would only work if say.. the borders were stone and then the tiling brick was still behind it. And of course, if I think of anything else I'll bring it up!
Logged
Oracizan
Level 0
**



View Profile WWW
« Reply #16 on: August 19, 2013, 02:44:52 AM »

K.I.S.A Alpha 3.2 is now available! Download it here. Chapters 1 and 2 are included in this build. Other changes are too numerous to count, but somehow I feel compelled to try anyway:

- Chapter 1: 'The Dungeon' added! Skip to it by pressing the 'Chapters' menu option.

- Chapter 2: 'The Village' added! Skip to it by pressing the 'Bookmarks' menu option.

- The Tutorial was updated to include a section about how to use health salves. Kisa and The Fool transition into their bow properly, and the end scene was modified.

- An opening story was added between The Tutorial and Chapter 1.

- A graphics quality glitch that prevented some users from switching to high quality in fullscreen was fixed.

- The main menu placeholder graphic of Kisa was updated to the final version. I'm putting it on all of the promotional images and hanging it on my wall. I'm just kidding about that second part, probably.

- Chapter titles and graphics were added. They look really fantastic, everyone. Elena's the best; I'm not afraid to use superlatives.

- A pause menu was added.

- A Bookmark Save/Load system was added.

- The options menu was updated to include the ability to rebind the quick-save, quick-load, and pause keys. Go crazy.

- Skirt physics optimized. All of the cloth was starting to take its toll on the engine.

- The Fool has his own footstep noises, instead of using Kisa's. He is also much better at following behind Kisa.

- Fighting noises are now appropriate to material of weapon & target. Fists make a fleshy sound when hitting a head, instead of a wooden noise.

- Static removed from narration. I was very close to trying to do batch noise removal on all of my audio before I realized that GM:Studio was at fault.

- Weapons now have blur trails. Violence looks fancier.

- Head injuries now result in a staticy screen and blurry border. Do not jump off of roofs, attempt a midair roll, and land on your head. I repeat, do not do this.

- Made jumping off of roofs and landing on your head less punishing. You can now fall over 25 feet and limp away because I'm a nice person and I don't want you to die all the time. The laws of physics and biology have no jurisdiction here.

- Lighting system was updated to allow for two different ambient light colors in the same level.
Logged

Oracizan
Level 0
**



View Profile WWW
« Reply #17 on: September 17, 2013, 09:02:29 PM »

From the K.I.S.A Devlog
 
Last month, I received an e-mail from a game developer who played the alpha demo of K.I.S.A. They enjoyed the demo, and became interested in the physics engine behind K.I.S.A - more specifically, the cloth physics. I provided them with a brief overview and a promise to write a more in-depth blog entry on the subject.

I now have time to make good on that promise...so let’s talk about cloth physics.
 

Cloth physics in K.I.S.A is 75% math and 25% hack - my favorite combination of programming.

PART I: THE MATH

Kisa herself is the best example of cloth physics in the game. She makes use of it not only for a wide variety of skirts, but also to animate her hair. In the above image, you can see an animation of her walking overlaid with a representation of the hair and skirt meshes.

The two major components of the cloth system are points (yellow dots) and constraints (green lines). Anyone who has done any sort of physics body modeling before will be very familiar with these terms, but for the uninitiated I will plow on.

Points are infinitely small physical bodies. In this simulation they have a position (x,y), velocity (xspeed, yspeed), and mass. Mass is very important in the next section.

Constraints define a relationship between two points. I only use distance constraints, which is a relationship that means ‘these two points are not allowed to be more X distance apart’. Some of the physics that I’ll describe later could also be considered constraints, but for now let’s just stick with distance constraints.

Every step of game logic, points update their x and y position based on their velocity, and then seek to satisfy their constraints. When the points and constraints are arranged in a grid, they resemble a net or rope webbing. The more points that we have, the more closely our mesh approximates a piece of cloth. Almost simple, right?

If only. Satisfying distance constraints is a tricky business. Typically, when points are too far apart, we move each of the offending points half the excess distance closer. So, if point A is at (0, 0), point B is at (10, 0), and they have a distance constraint of 6, we would move A to (2,0) and B to (8,0) to satisfy the constraint.

When there’s more than one constraint, it can be difficult to satisfy all of them at once. If the program satisfies a distance constraint for A and B and then satisfies a distance constraint for B and C, the latter constraint may move B in such a way that the first constraint is no longer satisfied. The result is like a really bouncy tug-of-war that makes for jello-like skirts.

The good news is that it’s not impossible to satisfy all of the distance constraints, just computationally expensive. If you loop through the constraints list multiple times in a single step, the system begins to converge on the optimal state. Oftentimes close is good enough, so 5-10 repetitions of satisfying constraints will do.

Note: I did not figure all of this out myself. I am indebted to the works of Andrew Hoyer and Thomas Jakobsen. Check them out for a much more mathematical analysis of the math of cloth physics.

Unfortunately, I found that no mattered how I optimized my code, I could not afford to loop through the constraints list more than a single time while having skirt meshes of acceptable quality and complexity. Clearly it was time for...

PART II: THE HACKS

For the record, when I say ‘hacks’, I am referring only roughly 15% to the definition that means ‘clever and cool programmer trick’ and 85% to the definition that means ‘hacked together code held together by spit, hope, and rubber bands’. Now that we’re clear on that:

When satisfying a distance constraint, most algorithms I’ve seen treat all points as if they have equal mass. You can do some nifty optimizations and simplifications if you do that, and it’s truer to how the mass of a cloth is actually distributed. If you assign the points mass, however, distance constraints satisfy themselves in new and exciting ways! (Wow. That sentence is 5.3 times dirtier than I intended.)

MA = mass of A = 2
MB = mass of B = 1
D = displacement = 3

DA = displacement of A = D * MB / (MA+MB) = 3 * 1 / (2+1) = 1
DB = displacement of B = D * MA / (MA+MB) = 3 * 2 / (2+1) = 2

So point B is displaced twice as much as point A. Imagine a baseball attached to a bowling ball by a piece of string, and you’ll have a good idea of what’s happening.

I can take advantage of this by predicting how the constraint system should converge, and then assigning masses to the points to encourage this same state to come about in pretty much a single step.

Examining a skirt for a few moments tells me the top of the skirt is fixed in placed around the waist, immovable in terms of the rest of the skirt. This means that I should weight the points in such a way that they tend to move towards the top of the skirt.

I assign the points at the very top of the skirt a mass of infinity (actually negative pi, but my program thinks that equals infinity. Shh, don't tell it!), and then assign mass exponentially from the bottom up.

All points on the hem of the skirt receive a mass of 2000^0 = 1.
All points a level higher receive a mass of 2000^1 = 2000.
All points a level higher than that receive a mass of 2000^2, etc.
 
This isn’t suitable for every case, of course, but for cloth that is suspended from a single point or a similar situation it works beautifully. Note that this mass-based hack was implemented after Alpha 3.2, so it can only be seen in .gif form right now.

While we’re on the topic, this is the same method I used to make the chains hang from the ceiling properly. When Kisa climbs chains, however, this upsets our assumptions about how the constraint system should converge (Kisa represents a large mass on the other side of the chain that points should be converging towards). I felt very clever when I temporarily swapped out the chain links for a single distance constraint between Kisa and the fixture point of the rope, but it turns out that Erin Catto did the exact same thing in Tomb Raider.

Anyway, final two hacks. 
 

One constraint that I did not mention but should be fairly obvious is the one that forces the points on the edge of the skirt to stay out from between Kisa’s legs. After all of the other constraints are satisfied, I find the lines formed between Kisa’s hips-knees-ankles and make sure the skirt's edge points are a certain distance away from these lines. If I make the lines curve slightly based on distance from hip/knee, a realistic leg shape is formed.

When Kisa rolls, there’s a problem: Kisa’s skirt should really - and would, if I let the simulation have its way - fall over her head. But this isn’t that sort of game, so I need to fix it in place. This is as simple as feeding the script that checks whether the cloth is between Kisa’s legs a false positive, so that the edges of the skirts are ‘locked’ onto her legs. It still doesn’t look quite right, so in the future I am going to have to give the skirt a fake shape to contour to that better approximates what the skirt would look like during a roll.
 

The final hack is one that helps take the load off of the cloth engine. As I said earlier, the more points that we have, the more our skirt resembles a real piece of cloth. But more points = more constraints = more processing per step, so it’s important to keep the number of points as low as possible.

In the above, you can see that the skirt has 12 vertical levels to provide a good contour, but only 3 horizontal levels. If I only rendered the mesh the skirt bottom would look horrible and angular, but there's an easy way to make the skirt bottom look curved with only 3 points.

At the bottom of the skirt I've added a polygon - a trianglefan - drawn from the center bottom point and then to each point of a spline (curve) drawn between the three bottom points of the skirt. It’s a simple but effective way to reduce the strain placed on the cloth simulation engine.

A similar effect can be seen on the top-back of Kisa's skirt when she rolls. This is partially for aesthetics and partially to stop the top of her legs from poking through the skirt mesh.

That’s it. You now know basically everything there is to know about cloth physics in K.I.S.A, and literally everything that I know about cloth physics. If you’re a game developer, go forth and simulate boldly.
Logged

Superb Joe
Level 10
*****



View Profile
« Reply #18 on: September 18, 2013, 05:02:57 AM »

Knights In Satan's Anus
Logged
Oracizan
Level 0
**



View Profile WWW
« Reply #19 on: September 18, 2013, 11:31:47 PM »

Knights In Satan's Anus

That's exactly what it stands for. How did you know? Shocked
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic