Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411275 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 10:00:10 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsKradens Crypt
Pages: [1] 2
Print
Author Topic: Kradens Crypt  (Read 5093 times)
poohshoes
Level 0
**



View Profile WWW
« on: June 22, 2014, 04:30:44 PM »


Kradens Crypt is a Multiplayer 2D Dungeon Crawler with a skill based combat system and big boss battles.

We are aiming to make a unique physics orientated game where you refine your skills in swinging weapons with mouse controlled combat. We are tired of playing games that require a repetitive array of button bashing with only a few character attack variations. We want you to feel the swing of your weapon, we want to make a game that gives the players the ability to carefully time, aim and control their attacks. We want to feel the impact of an orc’s charging attack, and see the consequence of mistakes, thus making Kraden’s Crypt all the more rewarding when you prevail!

Here's the current spawn room where you can get some starter equipment.  Note that you have no additional inventory and can only hold two weapons (or one if it's a hammer).


www.KradensCrypt.com
The Team
Artists: Peter Foster, Sam Foster
Programmers: Ian Hern, Claudio Fernandes
Composer and Sound Engineer: Brett Coop
« Last Edit: December 05, 2016, 10:40:26 AM by poohshoes » Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #1 on: June 22, 2014, 04:44:17 PM »

We are currently working on the first boss battle.  We are spending longer on him then we could as we want to be able to reuse some of the code to help make other bosses.  Here is a quick gif where his hit points where set to 1 so that we could see his animations looping correctly.

Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #2 on: June 22, 2014, 04:44:51 PM »

Here's an image of the prototype for the mini map.  I think it will look great once Sam or Peter (artists) takes a pass at it and we add icons to differentiate the rooms.

Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #3 on: June 23, 2014, 04:50:46 AM »

Not even finished the first pass on the item stats, but unlike the mini map the art assets for this were made before hand so at least it looks nice.

Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #4 on: June 24, 2014, 11:18:24 PM »

I was so busy developing I hadn't noticed Sam and Peter had put some different spells in.  I think we need to work on the earth spells behaviour and maybe add some particles but I am very excited about how good they look.








Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #5 on: June 27, 2014, 04:51:56 AM »

Today I altered the level generator so that we can spawn a pre-boss room connected to the boss room.  These will generally have health items and try to convey some story to you.  This was interesting because I ended up with code that can take two separate levels, find all the ways they can be put together, and then put them together.  In the future this could allow us to have other groupings of rooms that are part of a larger level.

One of the little bits I like the most about this update is now we have the boss room tagged so we can have a mini map icon to let you know where it is.

Logged

wisewonky
Level 0
*



View Profile WWW
« Reply #6 on: June 29, 2014, 07:51:03 AM »

Pete here. In the past few days our team has been working really hard to prepare for London Anime Con. There have been a lot of changes happening to the game in such a small amount of time.

 A notably significant change is the AI state machine, which allows us simple designers to tweak and customize the enemy behaviors and triggers.

Sam also noticed that playing with our polygon collision system meant that we could make chains. One of the results from these mechanics was this:



The "Guard Dog" as it is currently labeled is able to ward off any adventurers looking to steal his treasure. He is not so easy to take on with brute force, so the aim was to out smart him and steal his treasure. The risk of damage  would significantly decrease with more players, as one could serve as a distraction.

Also you don't want to make him angry when close to him.


Here he is showing me the door.

Claudio has also been working on the bull's throw behavior lately. Here is a  glimpse  of  that.


Logged
poohshoes
Level 0
**



View Profile WWW
« Reply #7 on: July 04, 2014, 07:23:35 AM »

As I write this Sam, Peter, and Brett are setting up a stand at the London Anime and Gaming Convention (our first con). The team operate from different parts of the world so I am staying up late to be available in case anything goes wrong. Claudio and I are both jealous as we sit at home and wait for any news or pictures. At first I saw the convention as a great way to show off our game and get some feed back. Soon we will know how that goes but I want to talk about a second unexpected benefit we discovered.

Over the last 8 months we had been grinding away at the core of Kraden Crypt, which consists mainly of spine animations, physics integration, a relatively unique control scheme, and a level editor. We sat down occasionally to talk about what features should come next but mostly I could pick and choose the work to satisfy my whims.



The problem with this is that after 8 months of work we hardly had a game. We had lots of parts that could be used to make a game, but it was not a game. It felt more like a proof of concept.

Then we were offered a free table at a convention and suddenly we needed a demo, something that would do it's best to represent what the finished game will be like. Sam and Peter originally attracted me to their team with an animated video of what they wanted the game to look like, and this became a goal state for the demo. We separated our todo list in to pre-con and post-con features. This gave us a great way to know what to work on, if it's not important for the demo then it was cut. We updated this list quite a few times cutting and adding as our needs changed but it was a great compass to steer our work by.



Today we have a demo that I am proud of, and it's fun to play! My post-con todo list is a couple pages long, and there are pre-con tasks that require a little clean up, but it feels great to be iterating on what feels like a real game. I'm hoping that we can take what we learned here and use it to push Kradens Crypt through various milestones and end up with a completed game. Thank you London Anime and Gaming Convention for giving us a leg up!

Bonus: Sam and Peter had these pins made to give away!


Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #8 on: July 22, 2014, 11:18:02 PM »

I am starting to get more comfortable with Farseer Physics Engine and today I found a solution for one of my major gripes with it.

To react to a collision you need to attach a callback to the OnCollision event of your physics body.  This works very well for the majority of situations, but where it doesn't work well is AreaOfEffect attacks, because you only need to check for collision once and then never again.  In Kradens Crypt the fireball spell damages all enemies within a certain range.  To do this the Farseer way you would make a sensor object the size of the AOE attack, put it into the world, wait until the next update for it to call OnCollision and process the spell effects, and then remove it from the world.  We end up with code all over the place instead of one nice linear function.

A cleaner way would be able to just do collision checking on the fly whenever you feel like it.  And so I dug into the sensor code and found this lovely nugget:

Code:
touching = Collision.Collision.TestOverlap(shapeA, ChildIndexA, shapeB, ChildIndexB, ref bodyA._xf, ref bodyB._xf);

While I don't understand all of what's going on here sensors in farseer don't have any effect on the physics so I feel pretty comfortable that calling this code won't have any sort of effect on the rest of the engine.  Also it's public and static, lovely.

The shapeA and shapeB properties are easy enough to figure out, childIndex is the index of the "part" of the shape that you want to look at.  CircleShape, PolygonShape, and EdgeShape all have exactly 1 child which means the index is always 0.  ChainShape can have more "parts so we iterate through them in a for loop when checking each child index.  _xf is private and unavailable externally but it's just the transform (position and rotation) of your object which you can get using GetTransform().

Here's the final code, notice that it starts with broad phase collision which gives us a list of the fixtures that may be colliding.  This also runs without actually adding the shape we are testing against to the physics world.

Code:
internal static List<Fixture> GetFixturesCollidingWithCircle(Vector2 position, float radius)
{
    // Use broad phase collision to get a list of fixtures that might collide.
    var vectorRadius = new Vector2(radius, radius);
    FarseerPhysics.Collision.AABB queryRegion = new FarseerPhysics.Collision.AABB(position - vectorRadius, position + vectorRadius);
    List<Fixture> broadPhaseHits = Factories.PhysicsComponents.World.QueryAABB(ref queryRegion);

    // Build our test shape and properties that we need for collision checking.
    FarseerPhysics.Collision.Shapes.Shape testShape = new FarseerPhysics.Collision.Shapes.CircleShape(radius, 1f);
    var testRotation = new FarseerPhysics.Common.Rot(0f);
    var testTransform = new FarseerPhysics.Common.Transform(ref position, ref testRotation);
    // since our test shape is a circle there will always be exactly 1 Child
    int testChildIndex = 0;

    var hitFixtures = new List<Fixture>();
    foreach (var broadPhaseFixture in broadPhaseHits)
    {
        for (int childIndex = 0; childIndex < broadPhaseFixture.Shape.ChildCount; childIndex++)
        {
            FarseerPhysics.Common.Transform transform;
            broadPhaseFixture.Body.GetTransform(out transform);
            if (FarseerPhysics.Collision.Collision.TestOverlap(testShape, testChildIndex, broadPhaseFixture.Shape, childIndex, ref testTransform, ref transform))
            {
                hitFixtures.Add(broadPhaseFixture);
                break;
            }
        }
    }
    return hitFixtures;
}

Obviously there is room for improvement here by adding the ability to test other shapes but I'm a strong believer of only writing code as you need it.
Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #9 on: November 01, 2014, 10:23:21 PM »

There's a reoccurring issue we've been having where, when you enter certain rooms, the game starts to lag (but only in debug mode).  What's happening is that we are asking spine to change to animations that don't exist, this throws an exception in spine but for some reason doesn't crash the game.  So I "solved" this by just crashing the game if the animation we are about to request doesn't exist.  This of course means that a bunch of the game objects are now broken and crash the game, but in a way they were always broken and now we just are forced to deal with it.

One complication is that by default objects request animations based on their direction and speed (eg. walk_left, run_downRight).  Objects that don't want this must always have an animation requested to override the default.  Before starting a new animation we had to end the old animation, this meant that in between ending the animation and requesting the next one it would set the default (which may not exist).  This was easily fixed by allowing a call to a new animation to just automatically end the old one.

Another complication is that in the editor it would be easy enough to get an object into a "crash" state so instead of throwing the exception we display a note in our error log.  We started adding animation to the game by animating the player, which mainly uses the defaults, and we tacked on pieces here and there to get other parts working.  It's nice to come back to it and clean it up a little after letting it grow haphazardly.
Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #10 on: November 13, 2014, 12:00:07 AM »

Months of development and hours of play testing and nobody on the team had noticed one glaring issue, the collision for hammer (and sword) was wrong.  The easiest way to make sure that all of the monsters and players and walls collide at the right points is to project the collision shape onto the floor.  Well apparently I forgot then when I went to implement the hammer and sword, I just mapped the physics to the visuals.  The red circle below shows where the hammer will collide.



This mistake gives you more range above your character and less below.  The easy way to think about this is that all collision shapes are projected down to the floor, so the area the hammer will collide with should also be projected to the floor like this:



Here's what the debug mode looks like with the fixed hammer, instead of following the hammer the collision shape is projected to the floor.  Also note the player’s collision circle is at their feet.



This was easy to fix but I thought it was interesting how easy it is to miss stuff like this and how much of a large effect it had on the game play.


As an aside, some of you might notice that using a perfect circle does not match the perspective, as to use circles the camera would have to be directly above.  Instead we should have used ovals that are compressed vertically.  We decided to do this because we didn't want things to clump together too much vertically, also it made animating the attacks much easier.  With this and screen resolutions in mind we should remember to build many of the levels left to right to take advantage of the extra space.
Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #11 on: February 25, 2015, 02:29:53 AM »

Over Christmas Kraden's Crypt was successfully GreenLit!  Thank you everyone who took the time to vote for us.

I spent today cleaning up Input code and I managed to trim off 140 lines of what is now a 409 line class.  While it doesn't feel as productive as adding new features there is definitely something zen about it.  One thing that I always struggle with is what to name button check functions.  On the surface this seems like a silly problem to waste time on but I find that many bugs in my code are caused by poorly named functions and I have become a sort of naming fanatic.  The standard function name for checking buttons is always IsButtonDown.  This is fine until you need to need a function that returns true only when the button was up, and is now down (ie. it has been pressed).  At first I usually try something like IsButtonPushed but it's synonymous with IsButtonDown and does not show a clear intent when reading the code that uses it.  My next attempt was something like IsButtonPushedThisUpdate, but I found that a bit verbose.  After much delegation and some discussion with my non-programmer better half I managed to come up with ButtonToggledDown.  This veers away from my the old rule I have gone by for years of using prefixes like Is, Has, and Should for boolean returning functions, but I think it reads better without.  Perhaps someone here has a better name for these functions?
« Last Edit: December 05, 2016, 10:40:45 AM by poohshoes » Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #12 on: October 11, 2018, 08:09:34 AM »

The Scalers List is a part of the pause menu that we are using during development to tweak some fundamental constants that multiply into all sorts of game formulas.  Everything from average screen shake time to monster mass can be scaled up or down and I’m hoping the quick turnaround time will result in more tweaking and a more balanced game.

Logged

Devilkay
Level 2
**

Hi! First game-dev experience!


View Profile
« Reply #13 on: October 11, 2018, 11:36:00 PM »

nice design!
Logged
poohshoes
Level 0
**



View Profile WWW
« Reply #14 on: October 18, 2018, 09:35:52 PM »

We use a very crude entity editor to add and edit components which lets us make everything from background art tiles to monsters.  Unfortunately unlike the Scalars system posted above you have cancel your game to get into the editor to make changes which adds a bit more friction.

Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #15 on: October 23, 2018, 04:24:19 PM »

Our in game polygon editor let's us edit hit boxes for weapons, monsters, walls, environment items.

Logged

Kato
Level 0
**



View Profile WWW
« Reply #16 on: October 24, 2018, 10:54:42 AM »

Looks nice! What framework are you using? MonoGame?
Logged

Owner/Developer, Authentic Experiences, Inc.
Games: Attaxor
poohshoes
Level 0
**



View Profile WWW
« Reply #17 on: October 24, 2018, 12:10:08 PM »

Looks nice! What framework are you using? MonoGame?

Thanks! Yeah it's monogame, the editor and UI are custom.
Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #18 on: November 06, 2018, 04:05:02 PM »

Finished replacing Monogames music playing with DirectX's XAudios so that we can overlap songs and also play ogg files.

To post something visual here's our in game drag and drop editor in action.  This is how all parts of the level are put together.

Logged

poohshoes
Level 0
**



View Profile WWW
« Reply #19 on: November 08, 2018, 11:44:26 AM »

Today we added one way gates to the game, the main reason is during boss battles to have areas to spawn monsters so they can come in without adding a ton of extra area.  Maybe we can find some other fun uses for them?

Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic