The VG Resource

Full Version: Kyrodian Legends
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
[Image: iwZzgC5.png?1]

Forum restarted, so gotta make a new thread for this.

Kyrodian Legends is a series I have planned that takes place in a world called Kyroda, which has an economic system that revolves heavily around mercenaries. There are many large guilds, clans, and factions that employ them, and one can also make a living in a small team or as a single freelancer. The main characters, as you might expect, are mercenaries.

The gameplay is a lot like Zelda 2 and Gargoyle's Quest, but with some Metroid aspects mixed in. Character upgrades are found by defeating new enemies and exploring, rather than through grinding. Some upgrades can be bought, but money can be earned both through contracts and through grinding; I'm trying to downplay grinding as much as possible.

Each game features a different protagonist's POV, and each has their own play style. Midi's game is more combat-oriented, Shacklebolt's uses physics puzzles, and Trey uses stealth. The fourth game, which I don't yet have a concrete story for, allows all three to be played as. If I can work out good AI, I might have CPU partners for this game as well.

I've already got three games of storyline planned, and you've already seen the sprites I'm making for the game in my sprite thread. I'm working on my own SDK for the game, so programming hasn't begun yet. If Game Maker supported Linux ARM, I'd be willing to shell out the 800$ for it, but since it doesn't, I'll be programming it in SDL/Squirrel. A bunch of songs have already been made as well, almost enough for the first game.

I'll post some more info on each character later as I get more art of them.
OK, here's the main characters I currently have designed for the game. Click on the square thumbnails to view their concept art.

[Image: DgLFRjls.jpg][Image: UMG1O3Q.gif]
Protagonist for the first game. Uses elemental acorn bombs for fighting and overcoming environmental obstacles, such as fire for burning things, ice for making bridges over water and freezing enemies, and thunder bombs for triggering electrical conductors. He can also use his bombs for mobility enhancement by standing on a mine and detonating it to jump high, or spin them like tops to hit things on the ground that are too difficult to hit by throwing. He can also use a wall jump to climb narrow shafts and backslide to dodge enemies.

[Image: sl6G2k6s.jpg][Image: V3qcTLG.gif]
Protagonist for the second game and supporting character in the first. His game is more stealth-oriented, and as such, he uses ninja techniques, such as advanced parkour and ninja weapons conjured from dark matter. Since his game depends on stealth, you get rewarded more by accomplishing contracts with a little enemy interaction as possible, and are penalized for needlessly taking out enemies. Trey can even use his shadow bending to become completely invisible and pass through transparent objects when not lit by a direct light source. His powers are also enhanced at night. In Midi's game, he teaches the player how to backslide and wall jump.

[Image: jiTIBKXs.jpg]
Supporting character for Midi's game. She provides transportation by piloting the airship and healing Midi when he is injured and doesn't have a clinic nearby to visit. She also provides Midi with updates on contract opportunities and new information from Trey.

[Image: 0pVWHlAs.png][Image: 08IJfKR.gif]
Protagonist for the third game, Shacklebolt uses telekinetic moves for solving physics-based puzzles and catch-and-throw combat, although he is still able to attack using claws and fangs. Since his ranged attacks depend on things being nearby to throw, his energy bar instead dictates how long he can fly, which works like Tail's flight in Sonic 3. He can also learn to bend air around himself to function as a speed booster, similar to Samus's, and can create a shockwave when falling a great distance, which also causes him to divert his momentum and roll forward upon landing.

[Image: nX108ZFs.jpg][Image: VpPUy9R.png]
Recurring antagonist for the first several games. Rift can fly to a limited degree like Shacklebolt, but with a different method of control. He can fire laser bolts from his wrists and enhance his melee attacks by activating his plasma katara, which extend from the same spots his lasers are fired from. Activating the katara will steadily drain his energy, however. His finishing move is to open his torso and fire an enormous beam, similar to Lucario's final smash attack.

[Image: PMvhpocs.jpg][Image: foAHrau.gif]
A supporting character in Shacklebolt's game, and possible playable addon. Apart from having the same flight and melee mechanics as Shacklebolt, I haven't planned much for this guy in terms of playability. My idea for him is that he uses weapons instead of magic, but I'm not sure yet.

Justin is Shacklebolt's adoptive human brother, and acts as a guide for him throughout the world. He provides Shacklebolt with support in a way similar to Sophie for Midi.
Well, I know it's been a while since I posted anything on this, but you know how it is, real life and all. Anywhoodles, I've decided not to wait until I have XYG running before I start coding this game. Instead, I'm gonna code the game in C++, and then port the functionality I've made for it into XYG. After all, what better way to design a GDK than by making a game as I go?

So, so far, I've got a sprite class that uses an entire sheet at once instead of each animation on its own strip, which saves me a lot of setup. I've also upgraded the code for SDL2, so now I don't need to port SPrig or NFont to other platforms. I also have a number of rotatable shape classes for collision. My game most likely won't actually need rotation, just standard circles, rectangles, and triangles, but you never know.

As for the game's music, my friend Kevin Pandaheart told me I could use any of his original songs I want. I figure since I'm not actually selling the game, then that's just fine, since I won't have to worry about setting up some kind of payment control thing to make sure he gets a cut (he actually said he didn't need any money, but I feel bad about selling the game and not sharing with him).

I have been considering the inclusion of some items that make references to other games, like slime pouches found in giant hornet hives that you can throw and cover the ground in bouncy slime, sort of like Portal's repulsion gel, and an item called the Pillbug Armor that works like Samus's morph ball, even makes bombs work the same way, mainly because I enjoy how Metroid's bomb jump works. The Pillbug Armor won't be canon if I use it, though; it's just an Easter egg.

That's all I can think of right now. Any feedback on these ideas would be greatly appreciated.
[Image: nBowepl.gif]

Just letting you guys know that this project is still alive. The background there is a placeholder from Metroid ZM; I'm just using it to show I have scrolling backgrounds and animated sprites working. I also have various types of input events and collision. I still need to finish triangular hit tests before I can move on to rectangle, since my rectangles will be able to rotate, and to do that, I'm using triangles. If I were to use lines, it would only work to make a hollow rectangle, so I'm using triangles to make it solid. At the same time, sticking two triangles together also allows me to make diamonds, so they'll be added to my shape library as well.

I'm going to make the shape library open-source to anyone who wants to use them. Since they can be resized and rotated on the fly, they'll be useful for physics engines, even a Box2D clone.

Once the shape library is finished, I'll be able to implement the map format, which uses built-in geometry for level solids, rather than placing a bunch of block class instances like in Game Maker. This should speed up performance, and even allow for very large solids without the need to create new sprites/classes for them. The map will also communicate with the camera to know where the view is, and render only chunks of the map at a time instead of every single tile. This works by drawing several cells that each map is divided into, and storing them. When the view moves beyond the range of the cached cells, it recalculates the position and decides which ones to redraw and which ones to simply scoot over. This should allow for fast map rendering.

As for Midi's hit box, I'm thinking that since he's a biped, I'm going to have two circles stacked with a square in the middle, so he won't hover off edges when standing on them and can go up slopes/stairs more smoothly, though I may just make stairs behave like a slope, the way the newer Castlevania games do.

I've also enlisted the help of a friend to help out with writing contract scenarios, so that'll free up a lot of my time for programming. Next update, I should have a basic physics engine made to record. The GIF above is a recording of an actor running to the right; no physics yet involved. I'll also include a link to the shape library for anyone to use.

As always, feedback is appreciated. Or a comment. Or, well, anything, for that matter.
Have you ever thought about using the Separating axis theorem (SAT) for collision detection? It works for any convex polygon. By composing multiple polygons together, you should be able to create any shape you want. Along with the SAT, there's the Sweep and Prune (SAP) algorithm to improve collision detection speed.

Some links
Much appreciated, Shy. I was planning on making a compound shape class, so that SAT technique looks like it'd really speed things up, letting me check one line against both shapes instead of each point and line against each area and line. Thanks so much for the info. ^^
Well, I finally decided, screw it, I don't know enough to make a game engine on my own from scratch using C++, so I'm using Game Maker Studio. Here's proof that the game is running:

[Image: HXd7wKz.gif]

I've got slopes working, too, which I'll show with the next update along with some other stuff. This is just basic movement, and shows that you somersault when jumping at high speed and how high you can jump and such.
Whoa, very nice, man! I'm still working out the basics of acceleration-based movement in pygame, so the fluidity of your movement here looks simply astonishing. Big Grin
(10-23-2014, 01:58 PM)DragonDePlatino Wrote: [ -> ]Whoa, very nice, man! I'm still working out the basics of acceleration-based movement in pygame, so the fluidity of your movement here looks simply astonishing. Big Grin

Oh, it's actually pretty simple. Here's what you'd put in your events. The logic can be easily ported into any language.

Create event/constructor:
xSpeed = 0;
ySpeed = 0;
maxSpeed = 4;

if(!place_free(x, y + 1)){
 if(xSpeed > 0) xSpeed -= 0.5;
 if(xSpeed < 0) xSpeed += 0.5;

if(place_free(x, y + 1)) ySpeed += 1;
else ySpeed = 0;

if(keyboard_check(vk_left) && xSpeed > -maxSpeed) xSpeed -= 1;
if(keyboard_check(vk_right) && xSpeed < maxSpeed) xSpeed += 1;
if(keyboard_check_pressed(vk_space) && !place_free(x, y + 1)) ySpeed = -10;


move(xSpeed, ySpeed);

Move script:
/*First we get a couple variables.
h is horizontal movement.
v is vertical movement.*/

/*Now what we do is instead of checking if a point is free a certain distance away,
we check every pixel ahead and then move a pixel until the loop runs out or we hit
a solid object.

i has to be absolute because if the speed is negative, it will cause the loop to
break, and we don't want that.*/
for(i=abs(h); i>0; i-=1){
   if(!place_free(x, y+1) && place_free(x+(h/abs(h)),y+1) && x+(h/abs(h)) > 0 && x+(h/abs(h)) < room_width){
   x += h/abs(h);
   y += 1;
   if(!place_free(x, y+1) && place_free(x+(h/abs(h)),y-1) && !place_free(x+(h/abs(h)),y) && x+(h/abs(h)) > 0 && x+(h/abs(h)) < room_width){
   y -= 1;
   if(place_free(x+(h/abs(h)),y) && x+(h/abs(h)) > 0 && x+(h/abs(h)) < room_width) x+=h/abs(h)
   else break;

for(i=abs(v); i>0; i-=1){
   if(place_free(x,y+(v/abs(v)))) y+=v/abs(v)
   else break;
[Image: MJbOyQq.gif]
<picardo>And now, something prettier to look at. You may notice the trees are parallaxed, but don't go beyond their set borders. That's because each cluster of trees draws a portion of two separate textures behind the foremost layer, ingeniously hidden behind two tallest trees for seamless movement, I might add.

The ground tiles have a bright contrast between the green and brown, colors I carefully selected in contrast with the blue sky to let players know where the empty space ends and the solid space begins. The characters also have very bright colors, in contrast to the environment's somewhat dull colors, allowing them to easily spot what they can and cannot interact with.

You'll also notice the slopes I mentioned before are working perfectly, just like I said.</picardo>

So, yeah, hope you guys like it.
Looks good overall, but I feel like I need to make this suggestion: Either the pattern for the dirt needs to be changed, or it needs to fade to black or a darker, solid color the further inland it gets. As it stands, whenever the screen moves, it just looks like a bunch of waving lines and it messes you all up.

Also, I feel like the character should start changing to his falling animation at the peak of his jump, rather than when the velocity downward is high enough.
[Image: CpSaVme.gif]
I fixed the jump animation and tried fading the areas to black, but honestly, I don't think the filled black works well for me, unless I can make it look better, but more likely, I'll just switch it back to my old dirt texture. As you can see, I also got melee combos and wall kicking working. I also changed the trees to add a bit more contrast.

[Image: HTqspwF.png]
Here's a screenshot of the other dirt texture.

[Image: EhZNo.jpg]
Here's a new attempt, this time using a different fade style that I think looks nicer. And I notice the little glitchy tile; I still need to make transition graphics for changing terrain types.
Not bad....this game is flaws i deserve the internet midi
I've just built a playable demo! You may notice some... familiar level design, but I assure you, that's just for testing. Please make sure to read the readme first.

Nice demo. The wall jumping is a lot easier than it is in most games and you got the slopes working really well. The player's a bit slip-n-slidey, though, especially when landing from a jump, It made platforming quite difficult.
Pages: 1 2