Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411469 Posts in 69368 Topics- by 58422 Members - Latest Member: daffodil_dev

April 23, 2024, 06:43:16 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsLegend of Purgation (Roguelike/Arena Fighter Hybrid)
Pages: [1]
Print
Author Topic: Legend of Purgation (Roguelike/Arena Fighter Hybrid)  (Read 2008 times)
zez
Level 0
***


View Profile
« on: October 13, 2011, 03:09:57 PM »

Currently this is in the planning/early development phase... I also dont really have a name, and basicly everything in this is subject to extreme change.

The jist of my idea is to combine a Dungeon crawling procedurally developed RPG with a fighting game. This is by no means my first iteration of this idea, but previous versions never panned out due to a number of factors. First and foremost was the fact that previous attempts where structured more in the style of a JRPG, and got DESTROYED by the prospect of level building and party management. Both those factors have been stripped away, in favor of randomly generated dungeons and a single controllable character.

I decided to go with an art style that minimizes the need for cell animation. The reason for this, is that although I do enjoy the process of drawing and combining individual frames, and the degree of control it allows awesome, half the point of a good dungeon crawler is finding newer, more badass lewt, and it would be an outright shame not to represent that on the player.
My plan instead, is to create composite sprites and use code based rotation, and a few extra angle frames per part, then just replace whatever bit of equipment with the next one, and not have to re-animate.

Something like this, in practice.


I have a basic character template finished to make use of this, but have yet to get into the nitty gritty of coding this. I like the idea of using some sort of ragdoll system, but havent fully committed to an approach to handling the animation code just yet.

Here's a template.


Im also attempting to integrate a fairly free form, yet balanced system for character creation/growth. Its sort a hybrid between a class system and a classless one. The way Im thinking of it working, is that you have the option of spending your experience points in whatever class you choose, with 4 (in red) open from the start. As you gain levels in a given class, new classes become open.
Each of the four CORE classes directly affect a stat, well the secondary ones offer more powerful techniques that take advantage of the prerequisite class' stats.



Ultimately the way this will play out is, pumping points into say, Warrior, will raise your basic melee damage, in addition to unlocking some new attacks, and weapon proficiencies. If in addition to this, you start pumping Guardian, you will be better able to defend, gain better armor proficiencies and an increased Health pool. After X amount of levels in warrior and Guardian, you will gain access to the Templar class. Putting points into this wont net you any stat increases, but will instead give you combat techniques that better take advantage of your stats, by allowing you powerful follow up attacks against opponents who are off balance from attempting to harm you.

I haven't decided if new abilities will unlock via per class skill trees, or just based on the current class level yet. There are advantages to both. The strongest advantage to skill trees is the added level of customization, present in decisions about what SORT of class X to play, and if you want to have a lot of different moves, or a few really strong (with lots of points in them) ones. The strongest advantage of using the current class level is that its easy. I dont JUST mean for me, either. It is entirely possible with a skill tree based system to build a BAD character, and although I intend to make it fairly obvious what each ability does (including listing each class and ability's prereqs in the menu) I want to shy away from to much hand holding.

The final bit, is how all this stuff actually effects gameplay.
First of, the 'standard' exploration mode is going to be top down dungeon crawling in semi real time. I say semi because using skills or accessing the menu, as well as dialogue will pause it. Im planning on including some degree of environmental interaction (meaning the player can do things like dig tunnels or build bridges.) That mode ends when you encounter an enemy, and it goes into a separate battle screen ala most JRPG's.

The reason for this, is that once you enter combat, you are in a side scrolling fighter, with more similarity too street fighter then diablo.
The way your character fights is dependent on your stats, equipment, and skill mapping.
Skill Mapping consists of assigning the techniques you have learned to different button inputs. Lets say your playing a warlock and you learn fireball, you would then map it to forward quarter circle punch (or whatever other open input slot you have) and when you get into a fight, it would be a matter of  Hand Joystick Hand Any Key .

Different equipment setups would allow for use of different skills, and skills would have allowed input mapping based to some extent on directionality and power (meaning super powerful moves would require more complex input, and you cant map a fireball to back back punch.)

Alright, so that was a great deal about what Im PLANNING. Now for what I actually have.

1. Functional dungeon generating code, although I haven't committed to a language/platform just yet so there is a fair chance I will have to port it or re-write it.
2. Templates for the characters
3. basic dungeon tiles (walls and corners for all possible situations, and the floor. Some of the tiles can be seen poorly 'tiled' in the mockup.)
4. If I opt for C# as a language, I have a gamestate manager, extremely open ended physics engine, quick hittests, and input code that can check against arrays (for the quarter circles and such.) I also have some rendering/animation helpers that may or may not be remotely useful.
5. Adaptive AI for enemy's. (Meaning it learns to predict your actions, forcing you switch strategies)

So, in other words, not alot at the moment.
« Last Edit: October 18, 2011, 02:40:47 PM by zez » Logged
zez
Level 0
***


View Profile
« Reply #1 on: October 13, 2011, 03:31:41 PM »

Heh, good call. Fixed.
Logged
zez
Level 0
***


View Profile
« Reply #2 on: October 13, 2011, 04:14:38 PM »

Yeh, C# would be with XNA. I dont really want too cook up a blitter, and Im pretty fond of the gamepad class in it.
Im probably going to do that, but Im still toying with the idea of making it browser based for the sake of distribution.
Also, Thanks XD.
Logged
zez
Level 0
***


View Profile
« Reply #3 on: October 14, 2011, 09:42:44 AM »



Super simple mockup showing the exploration aspect of the game and the tiles used properly.

Im probably going to make some more varied tiles at some point or another, right now there are just three possible floor tiles, and then one version of each wall tile.

I have also decided to go with C# for the game, and am now going to get into the nitty gritty of coding the world generation and tile engine.
Im thinking Im going to START with a fairly basic algorithm that just makes rooms and hallways linking them, followed by some slightly more complex versions to make more organic structures as you get further down (Possibly figure out some sort of way to organic-ify a map through a variable so I can make the floors get less man-made and more natural as you get deeper into the dungeon.)
Logged
zez
Level 0
***


View Profile
« Reply #4 on: October 14, 2011, 11:15:30 PM »

Alright, I have EITHER a mostly finished function for map generation, and a finished Auto Tiling function, or a mostly finished Auto Tiling function, and a finished map generation function.
Its probably the former, seeing as the current situations where the auto tiler fails to tile are ones I didnt think to make tiles for in the first place (stuff like two corners touching, individual tiles, and single tile walls. As it stands, I have outside and inside corners, and it knows what side the wall is on, and on top of that I can run both functions way faster then really matters, in case someone manages to make it to the exit in less then a millisecond and doesnt want to look at a load screen.
I also mostly finished the tile engine, Ima retool the render code eventually once I figure out what Im doing for a camera. I can either just use a vector offset for everything, or do something way more complicated that allows for effects and such. I REALLY like the idea of a zoom function for combat purposes, and Im fairly sure I could work out something nifty with a matrix, so Ill probably get on that tomorrow.
Logged
zez
Level 0
***


View Profile
« Reply #5 on: October 15, 2011, 03:39:04 PM »



'Finished' the camera code. It zooms and rotates, and lets the game be 320 x 240 till it 'needs' to zoom out. It also auto sorts everything, as you can see in that there screenshot (the random box is a sprite)

The map generation/auto tiling is done too, next up is dealing with the sprite animation class followed by actual gameplay.
« Last Edit: October 15, 2011, 03:46:50 PM by zez » Logged
zez
Level 0
***


View Profile
« Reply #6 on: October 18, 2011, 02:40:25 PM »

Sprite animation code is GO!!!
There are three 'types' of animations supported; "simple" being standard sprite sheet animation, "vector" being vector based animation, and "complex" being a hybrid of the two.
The Upside to these methods, is I can can pull of a plethora of angles and animations, the downside is there is a little bit more dependence on sprite sheets then I would like. Not really a good way around it, as code based pixel manipulation looks pretty fuggly, and I do want the option of having parts face different directions (hands have 20 frames of animation, feet have 14, heads and torso's each have 8.)
This basically translates too each weapon and glove needing 20 frames of animation to integrate with the animation code, each shoe needing 14, and armor/helmets/hair needing 8.
This works out a hell of allot better then going for straight cell animation, where each bit of equipment would likely need hundreds of frames of animation, but could still get out of hand pretty quickly (10 different swords = 200 frames.)
To some extent this can be remedied through intelligent re-use of resources (a flaming bastard sword can just be a recolor of a bastard sword, for example) and a fair bit of equipment will basically just be paint overs, so it shouldnt be TOO daunting, just slightly daunting.
Logged
zez
Level 0
***


View Profile
« Reply #7 on: October 29, 2011, 05:36:32 PM »

That last post was a lie, sort of.
Sometime well implementing the code for the animation I realized that manually typing in (and thus manually calculating) each rotation was a pain in the neck. I Updated it a smidge, and now I can pass it a vector 2 for where I want the limb to move towards (I mean, well being locked to a joint) and it will not only rotate to that, but also generate tweens. My tween code has also cut the necessary amount of pixel animation in half, so thats exiting.

I now have the dungeon code finished, along with the top down movement and animations. Im beginning work on combat, and currently have like 2 animations and some basic physics stuff done, along with one weapon, for the testing of animations. Combat is likely going to take awhile, however, as nearly every action ties in to the skill system and thus I will have to build the two in parallel. The upside is, the way my control scheme and animation code works, I can just write one entity, store the animations per skill, and then magically have as many enemy variations as there are skill combinations possible.

That being said, it is a little counter intuitive to write code so that the player and enemys are the same class. (As apposed to different classes using the same framework, or extending the same class.)
Logged
zez
Level 0
***


View Profile
« Reply #8 on: November 12, 2011, 02:08:52 PM »

Jiggled my animation code a bit so it can support X coordinate flipping (Simple for the sheet animation stuff, but slightly more complicated for Vector animations)
I also now have a super Object Oriented skill system, and most of combat 'physics' finished.

Everything is playing nicely, and due to the setup of my input class, I can use the same skill sets (And of course, corresponding animations and hitboxs) for enemys as the player, so I have as many enemy types as there are possible skill/equipment setups available. At the moment that means one, but now that the framework is in place I can start plugging in more variables and expanding.

Im starting out with the Warrior class, just because its the simplest from a code & animation standpoint, but once that is "Done" Ill probably go -> rouge -> assassin - > mage -> warlock -> guardian -> cleric -> templar and release an Alpha.

I figure it will take people a minute to level up there character too a point where the next Tier is needed.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic