Overworld

There are 20 base jobs. Among these, each character will have one job excluded. They can never become this job. This is listed in no particular order. I might fill up most of the content of this Sunday’s blog with what each job particularly specializes in. Yes, I do already have that planned out.

1. Philosopher
2. Fighter
3. Archer
4. Guardian
5. Gambler
6. Sorcerer
7. Wizard
8. Cleric
9. Thermatologist
10. Traveler
11. Alchemist
12. Deckmaster
13. Thief
14. Monk
15. Electrician
16. Beastmaster
17. Berserker
18. Venomancer
19. Priest
20. Bard

There are also five exclusive jobs. For the five characters in the game, they each have one job only they can become.

1. Shadow Knight
2. Queen
3. Paladin
4. Assassin
5. Shaman

There ya go. Be excellent to each other. Party on, dudes.

I didn’t get nearly as much done as I wanted to this week, and not for lack time spent working, honestly. Just a lot of minor roadblocks, a couple big ones, and way too much time spent figuring out where the problem was. The plus side is these likely won’t trouble me again so much in the future. Plus, I think you’ll find a lot of these are issues that, once solved, permit me to make a more modular system, allowing me to develop faster in the future.

So first up, I’ll talk a bit about something I think more readers will care about: gameplay… at least in regards to what I was talking about this week and last week.

Overworld has a full scale job system. At the start of the game, you begin with one character on your team, Euclid, and he has two jobs available to him: fighter and philosopher (but not mathematician, go figure). In each town of the game, there is an object (as yet unnamed), that I currently just refer to as Build Orbs. These Build Orbs permit you to change jobs whenever you are near them. You can’t change them otherwise.

Each job that each character have levels that stand apart from their own. So Euclid’s character level might be 7, but his fighter level would be 15, and his philosopher level might be 12. Monsters grant you both regular experience and job experience, which is the value used to level jobs.

So what benefit do jobs grant? First and foremost, it alters stats. A philosopher tends to be a little smarter than people who are currently another job. Also, looking at the XML files I posted last week, you can probably see that as a job levels, it bestows special skills upon the character.

You can see that a level 100 fighter earns the powerful Juggernaut Blast. This is a powerful attack that drains a lot of a character’s health, all of their mana, and then deals damage based on the resources lost in addition to a multiplied amount of their usual damage. As the ultimate fighter ability, it is meant to hit like a truck. This is obviously an activated ability, but there are other types. A tad bit above Juggernaut Blast, you can see Muscle V, which just passively increases the character’s strength and constitution.

Here’s the catch with these skills you learn: you don’t benefit from them at all just by learning them. You have to equip them into your limited number of skill slots. The cool part is, however, nothing stops you from equipping them when you are currently another job. Learn Juggernaut Blast as a fighter, equip it, switch to being an archer, and then use it with your bow and arrow from afar, if you so desire. Or learn Muscle, then use the Constitution it grants to survive as a squishier job.

Somewhere around level 80-100, each job also gets a skill that, while capable of being turned on or off, does not occupy a skill slot to have. This is meant to be a major reward for getting so far in that job’s progression. The fighter gets Rapid Recovery at level 99, which heals the character for 1% of their max life per step they take while in a hostile area, greatly reducing the consumption of resources used for survivability.

You may find yourself asking what the point is to being a specific job then, if you can just take the skills you want and run away with them to become another job? Well, there’s a few perks to being loyal to a certain class, as well as few penalties for switching too much.

THE PERKS OF STAYING ONE JOB: At level 2, each job gets a scaling ability. This is there to ensure you are immediately benefiting from playing as this job, and are rewarded for leveling it, even if you don’t get a skill each level or if it’s a skill you don’t want. For instance, Fighter gets Brawn at level 2, which grants an extra point of physical damage per fighter level and one extra percentage of physical damage bonus per 7 fighter levels. However, these scaling abilities have their effects reduced by half if you are not currently their associated job. A philosopher equipped with brawn with get 1 extra physical damage per 2 levels in the fighter class and .5% extra physical damage per 7 levels. All other skills in the game take no penalty for not being equipped on a character of their associated class, but these scaling abilities are meant to be the prime perk of sticking to a core job.

THE DETRIMENTS TO SWITCHING A LOT: It sucks to see a game’s balance ruined by a bad grinding system. One of the first inherit flaws I noticed with Overworld’s was that when you get to later areas in the game, enemies will grant much higher Job Experience than in earlier areas, and so there’s no reason not to just jack up all the jobs you haven’t touched yet and unlock a whole new plethora of skills. To help counteract this, all jobs have the amount of experience required to level increased by 1% per job level the character has gained (with levels taken in philosopher not counted for reasons I’ll explain later). Maxing out one job (100 levels) means all other jobs now double up on their experience required to level. So while the player can switch to low-level jobs in high level areas and get, say, six jobs to level 30, they just upped the amount of experience their primary job will need to hit level 100 by 180%. Ouch. That being said, the player is warned of this penalty from the get-go and is given a full list of every skill offered by every job so they can know what path they want to go down.

So, question: how many skills can you equip? Well, a lot, actually. But the exact number is pending based on several factors. First, how many skills are there? I want characters to be able to equip a fair number of skills, as the whole fun of this system is the “create your own job by combining the pieces of other jobs” idea, but of course, they can’t just equip every one. There are roughly 20 jobs total planned, and I’m trying to scale it so you max out 3 and maybe specialize to a lesser degree in 3-4 others over the course of a single play through the game.

Also to be considered: you don’t start out with every skill slot unlocked. You will begin with somewhere between 5-8. You can unlock another 8-10 by leveling up your character, another 5-7 by upping your character’s Wisdom stat, and another 10 (this number I am sure of) by leveling up the Philosopher job. So depending on how many skills I wind up having and how I feel the game plays, it’ll be somewhere between 28 and 35, with the player potentially earning less depending on how they build themselves (and don’t worry, there are other methods of achieving power for a character besides having a crapload of skill slots).

You may have guessed already, but the Philosopher job is a bit special. Every job specializes in one aspect of gameplay (fighter being physical damage, for instance), and the philpsopher’s specialty is… jobs! The scaling ability they get is the only one in the game that stays the same even if you are not a philosopher and it grants a reduction in the aforementioned required job experience penalty, at a rate of .01% per 4 philosopher levels. Any character with a level 100 philosopher will thus increase the amount of job experience required to level up a job by .75% per job level obtained. A bit confusing, probably, but it’s hard to explain in this pure text format since I’m still just working on it all in .xml files and C# code right now. It’ll make a bit more sense with a GUI, I promise.

The Philosopher job also does not incur or give out the job experience penalty, and every 10 levels earned it in unlocks one new skill slot. It also has its own experience curve, that ends quite a bit higher than other jobs. This is for two reasons. First, to help offset the ease of leveling somewhat, since it doesn’t incur the experience penalty other jobs do. Second, to make it so philosopher, while incredibly useful for everyone to level at least a little bit, isn’t just some absolute required staple class that everyone should max out to beat the game. My goal is to have character’s who aren’t focused on it beat the game with it at about level 50 to 60, and characters who are beat the game with it around level 80-90. Players clearing extra content who grind a bit are the likely candidates for getting it to level 100.

And NOW it’s time for something fun. Here’s some of the classes I have designed so far, as well as some of the abilities they earn that I am most excited about. There are other types of effects based on aspects of the game I have yet to mention, but hopefully these perk some people’s interests.

ARCHER

• Piercing Arrows - 25% of all physical damage you deal to enemies is also dealt to any enemy in front of them.
• Nonretractable Blades - Critical strike damage increased to 225%.
• Focus Fire - Every party member deals 10% extra damage to the last enemy targeted by your physical attacks.

GUARDIAN

• Beckon - Forcefully begins a random encounter from the area you are currently in. This encounter will grant 3% bonus experience.
• Defensive Strike - Consumes mana to attack and defend at the same time.
• Pride - You cannot die to enemies above 75% life. For every other character in your party with this ability equipped, the amount is increased by 5% (95% if all five party members have it on).

CLERIC

• Afterlife - Chance upon dying to an instant death effect to return to life with the same amount of health and an extra 100 mana.
• Displacement - Enemies are harmed for 5% of any healing effects you perform.
• Ward - Reduces encounter rate for 50 steps

ELECTRICIAN

• Static Link - Consumes mana to create a link between you and the target, transferring some of the damage they take to you.
• Overload - Vastly damages all enemies for a percentage of their health plus a flat value, but leaves you unable to act for a short while.
• Flash - Teleport to any town you have previously visited.

THERMATOLOGIST

• Heat Sink - Increases the damage dealt by your fire spells and ice spells by 10%.
• Weather Mastery - You take no penalty for travelling on the world map in extremely hot or cold environments.
• Frostburn - You can create burn effects on enemies with ice damage now, instead of just fire damage.

GAMBLER

• When to Hold ‘Em - The Gambler’s scaling ability earned at level 2. Damage range for all effects is increased by 3 maximum and decreased by 2 minimum per Gambler level.  Any inapplicable minimum damage (i.e. trying to go below 1 damage) is instead taken from the maximum damage. If not currently a Gambler, this applies 3 minimum damage per level.
• When to Fold ‘Em - Minimum damage is increased relative to the health you are missing. If you are killed by an enemy instant death effect, you attack three times for your highest possible damage before you die.
• Coin Flip - Consumes mana to either hit for your maximum damage or minimum damage.

So hopefully this gives you a good idea of what the jobs do and gets you a bit excited about combining these abilities. I think you already can see some power to mixing some Gambler and Fighter abilities, for instance.

But the question now is… how do I intend to implement this job and ability system fully? There was a minor preview of it last week, and I spent a lot of time this week agonizing over something that works, and I think I’ve gotten somewhere a bit. Be warned that this is about to talk a whee bit more about coding and other crap. I will try to keep it simple still.

So I had to make a few requirements on how this would all work and design it from there. I’m still keeping the number of abilities and jobs actually existing in code low until I’m sure I won’t wind up adding somewhere later than requires me to change it all. However, I think I’m close. Here’s some of the requirements:

1. A job must be capable of giving a player more than 1 skill per job level.
2. A skill, upon being learned, must be capable of deleting/overwriting an older version of that skill upon being learned.
3. A skill must be capable of doing more than one thing, such as the Gambler’s When to Fold ‘Em skill.
4. There should be no limit to the variety of effects skills are capable of performing, with a system in place that even lets me add possible effects later without fucking up code too much.

Do I have something in place that can do this? I think so. Here’s a rough drawing of the structure for this, with each square basically representing either a .xml file or the object class type the .xml file can be converted into.

The red dots represent unique identifiers for an object, the blue dots represent that they are unique identifiers for another object, used to find exactly which one of those objects we’re talking about, and the purple dots indicate a list of objects.

So a character gains a job level, and the XML reader looks up the .xml file for the corresponding job, and looks for any objects of the SkillGain type in its SkillGains list that have a (you guessed it) JobLevelEarned matching the level the character just achieved. A character hits level 2 as a fighter, it looks up the SkillGains and says “Oh, what the shit! Level 2 is when this dumbass is supposed to get Brawn”.

So now it knows it is dealing with the Brawn skill. It looks up Brawn’s .xml file, and first looks for foreign identifiers of skills to overwrite. In Brawn’s case, there is none, but if this were, for instance, Muscle II, it would know to delete that character’s Muscle ability to replace it with this. Next it looks whether or not Brawn is an ability you need to equip (which it is) or one you simple can have active for free, like the aforementioned Rapid Recovery. This information it is going to just remember rather than do anything with since it’s really just building the skill the character is going to gain right now.

Finally it hits a list of foreign identifiers for skill effects. For each one of these it is going to look at its ID and its type. You see, the base object class of SkillEffect can’t really do anything. It is merely there to have a lot of subclasses of it so they can all cleanly go into one list of SkillEffects. The example in the picture is good enough, so I’ll go with that.

One type of subclass I can create is an AlterStatSkillEffect, which will have two values: which stat to alter and how much to alter it by. The previously mentioned skill called Muscle would have two objects of this type in its SkillEffect list (and yes, if you look on the chart, you can see it is a list!): one for its increase to strength, one for its increase to constitution. Know When to Hold ‘Em might have something similar: two effects, with one being for raising max damage and the other being for lowering minimum damage.

You can do more with it. Want to have a Poison Blade move that deals damage and applies a poison effect? Easy enough. Create a ApplyStatusSkillEffect with the fields of which status to apply and the base chance to applyt it. Then create a DealDamageSkillEffect which has a value of how much damage to deal. Create one .xml file for each instance of these that would go in the Poison Blade move, and then apply the reference to these skill effects in the actual skill’s .xml file. Pretty easy, actually. Obviously I’m totally ignoring the actual code logic that has to be applied for telling the system exactly how to handle these effects and the values they entail, but that’s really not so hard due to how structured it all is. I’m very exciting about the power of this system.

Sadly, it took me way too long to get going. I spent a lot of time fucking around with the connection strings to the file paths only to realize that it all depends on whether or not I’m in debug mode. I didn’t want to have to specify whether I was in debug mode every time, so I’m now making an XMLHandler object that should take care of all that for me every time I try to access a .xml file. It’s slowed me down a lot and is very demotivating, but I won’t give up. I’ll be coding my ass off next week too, and hopefully in my next entry, I’ll be able to post a video of me in debug mode simulating a level up that successfully teaches a skill and lists of its effects and crap.

I might also edit this post later to include some sprite art or concept art for the game which is coming along nicely… or to just clean up the types I’m sure have been left abundant. I’ve been writing this for nearly two hours though, now, and I think I’ve imparted enough information about this game for now. Until next week! I truly hope you’ve enjoyed this, at least a little bit.

I can’t really say I’m an experienced blogger by any measure. In fact, I can’t really say I’m much experienced at anything other than drinking, masturbating, and crying. I can even do all three at the same time! Certainly, though, if there’s one thing I do worse than blogging, it’s developing video games.

Using my two years of experience as a computer programmer in my nation’s fine military, I’ve dabbled about in the art of game creation here and there. As for blogging, I was an angst-filled teen at one point, like many of us, so I had some insincere efforts at it in the form of suicide notes and poetry about my soul being dark or something. Other than that, not much understanding of either field.

But what the hell? It’s time to dive in headfirst. Henceforth, I’m going to work my ass off on my game and work my ass off on this blog detailing my efforts. It’ll be fun, because chances are you don’t know much about programming either, so you can feel my pain as I struggle with each tiny little task. This way, it won’t be like one of those tech blogs where you have no clue what the hell the author is talking about.

So my game. I’ll discuss how it has developed in my head first. Like I said, I’ve dabbled around in game development here and there in the past, ultimately having an incredibly minor understanding of it. I have decent knowledge of the basics, especially since I have spent money on some books and studied them thoroughly. Using my limited knowledge, I have tried to make games in the past where inspiration has struck me, but the game I will be making for this blog is one I have dreamed since about two years before I even knew what the hell programming was.

A brief history here. In those days, I walked into the guidance counselor’s office of a community college, knowing full well I was some idiot high school dropout, and I told them I was interested in making games, but had no idea where to even begin. Laugh if you will, but I only had come into possession of my first computer three years prior, and catching up in the tech field was proving to be tricky. I got a general idea of classes to take to get into programming, and it seemed a fruitful career field, but all the while, my game idea was on my mind.

A few years later, my dreams sidetracked, I joined the Air Force as a programmer. They upped my skills a bit, but in my free time, I was always still thinking about how to use those skills to make my dream game. It wasn’t long before someone showed me the XNA Framework. It seemed useful. About as open-ended as you could hope to be in coding, but with a lot of the work taken out for sake of us indie developers. Toss in a few failed projects by me, and one idea to attach a blog to a serious one, and here we stand. Maybe I’ll discuss these paragraphs in greater detail in a future post. Hell if I know. We’ll see how this goes.

I’m sure you’re just itching to hear about what the game actually consists of. It is called Overworld, Episode VI and there is a pending subtitle. It is a 2D turn-based RPG, which is my favorite genre of game. While I truly hope there is a market for other people to play this game, it is really nothing more than my own dream project, the game I would love to play more than any other, and I will be making it as with that in mind. If I happen to interest anyone else in playing it along the way, well, that’d be just great!

Your first question may be: “Where did episodes 1-5 go?”

A valid query, and simply put, they didn’t go anywhere. One of the things I have focused on very hard in this game is a story. There is a full timeline I have created of major events in the world that have been divided into episodes, each with their own standalone plots. There are ten episodes in total to the Overworld saga, which isn’t much a saga at all, because there is no released material for it. I would not be so pompous as to put forth a belief that this game will be some mass success out of nowhere and strike me the funds I need to make an unheard of 9 more games.

But I will say, yes, I did write out this full story, it is ten episodes long, and this game’s plotline is the sixth installment in the overall story arch, so I feel it fitting to give it the title as such. If, through some ungodly miracle, I am given the chance to make another game in the story eventually, I’d relish the opportunity to display that level of consistency, showing that there were indeed at least two episodes to this Overworld series. Next, why did I choose episode 6 as the game to make? In truth, because it’s got the most simple, easy-to-digest-on-its-own story, which I also feel raises intrigue for the other segments of the story.

Onto actual development stuff.

I have worked on this game here and there in minor ways in the past, but with certain successes in the XNA field this weekend, I’ve been scraping old code, and I’m practically starting from scratch. Thus, it’s a perfect time to start this blog, I think.

My entire weekend (and some of the prior week) was spent struggling with data structure. To display my ignorance of the topic, I thought I could just take any old database program (Access, SQL Server) and use that to allow players to save game data and to allow the game to load content (such as monsters, default character stats, etc). As it turns out, I was wrong. I learned after too much hard work that the player would require the software for these programs as well, which is already ridiculous, but they would also need to have the game’s content re-created on the program’s initial launch, which would basically mean it would all just need to be in code anyways. Yikes. There’s no way to make the game look good doing that.

SQLite seemed like a decent option, but by now, I was digging around in other games made in XNA that I had on my computer to see how they were storing data. Surprisingly, I found all .xnb and .xml formats. Even GTA4 (not made in XNA, of course) has a data structure almost entirely made of .txt flatfiles and .xml files. I found this all to be pretty fascinating, because I was totally unaware of this, that there existed an entirely different format for client-side data structuring. I felt pretty fucking stupid.

After some more research, I realized that a data structure almost entirely in .xml was right up my alley. This ensured data in the game was actually pretty open and readable to the user, allowing them to make minor edits if they so desired, which is fun. On the other hand, if I want to make the data harder to access, XNA seems capable of converting .xml to .xmb with relative ease. Granted, I’m not familiar with the process, but it’s there apparently, which is nice. It doesn’t really matter, either way. I really can’t fully protect the game. Anything you store client-side (in this case, everything) can be accessed by the user, which is probably why so much crap is going open-source these days anyways. The plus side to it all though is that XML is easy and it makes organizing the data easy, and while it is a little more costly on processing power, my game as a whole should not be, rarely ever doing more than handling 30 sprites on screen at a time, which isn’t much at all by today’s standards.

The majority of my weekend was spent figuring out how to convert .xml files into in-game objects through the content pipeline of XNA, which proved to be an absolute bitch. You see, the .NET framework (or at least the XNA framework; I’m actually not sure which, but lemme know if you want and I’ll edit this) can easily convert any .xml file into an instance of one of your classes as long as the properties of the class coincide with the values in the .xml file.

But for some reason, XNA just wasn’t quite understanding what the hell I was trying to do, and boy howdy, was this damn thing poorly documented online. Most tutorials I found were for old versions of XNA that still tried to use TypeWriter objects and TypeReader objects to do all this, and the rest just wouldn’t explain the concept in its most simple form. One tutorial I found seemed to cover the basics well enough, but I’ll be damned if I’m going to read any code where the guy names his classes “Class1” and “Class2”.

Finally I stumbled across this.

The technical crap (all of it) of it may be lost on you, but there was an important lesson here. XNA creates two projects on creation of a new game: one for your game objects and logic and the other for game content. The part I didn’t know is that they both need to be able to reference the type of object the .xml file is trying to become, and you can’t do circular referencing, so a third project (a game library) must be created to house all instances of this dual-referencing. Good times.

It was hell, but it’s out of my way now, and I got that typical feeling a programmer gets as they go from grinding their nails into their face due to the frustration of code that won’t work and an internet that won’t help straight on over to dancing around in joy because it works and obviously with this nothing can ever go wrong with my code again.

I’ve now spent the better parts of my free time Sunday and today designing the data structure in .xml format. There’s still a lot to go, but I have the idea down decently, and notes to help me along the way. So I guess that’s my progress report, and sometime near the end of next weekend, I will hopefully prove true to my word of keeping up on this blog, and I will post a new update on the progress and nature of Overworld, Episode VI.

In the meantime, I’ll close with some screenshots of Visual Studio… how exciting.

This is the XML syntax for an in-game job. Kinda like in Dragon Warrior III or Final Fantasy V, I guess, where you didn’t so much have a character progressing, as you had their instantiation of the class that they currently were progressing. I may change this syntax a bit to help ease up on the processing power, though possibly lowering the readability slightly in the process. If I do, it shouldn’t take long, as I’m not adding any more than 2 or 3 jobs until I’m sure I have the data syntax, structure, and logic all good to go. Would hate to find an error that requires me to go back and change a few thousand skills.

Really, more of the same, but just to give you an idea of how this list completes. In case you had yet to figure it out, the majority of this list is made up of the skills a job can learn, bearing 3 pieces of data for them: the level at which the skill is obtained, the name of the skill, and the rank of the skill. My hope for the logic of it is that every time a character levels up in a certain job, the .xml file associated with that job’s base information is instantiated into memory for a short while, where the code looks to see if anywhere on that list you see above is a skill with the “JobLevelEarned” tag equal to the actual level achieved. If so, it uses the name and rank of the skill to find the skill’s .xml file, load the base information from that file, perform any logic if necessary, and add it to the character’s learned skill list.

The potential syntax change I mentioned earlier? I’m thinking of having it so there’s no skill rank listed here. Instead, each rank is its own skill, and each skill’s .xml file has a nullable “SkillToOverwrite” tag. Muscle II, for instance, would be its own skill without ranks, but it would have Muscle in its “SkillToOverwrite” tag. When you learn it, it finds that skill and, you guessed it, overwrites it. This adds a little more bulk to the size of the .xml files, but it should free up some processing power, which is the more important resource in my opinion. I dunno. As stated, I’m really not that great at coding or anything, but if you have any suggestions, comments, or questions, then fuck, I’m all ears. I hope you enjoyed this. See you in a week. I’ll proofread it later. Honest.

NOTE: This blog actually began yesterday on a different blogging site, but some people I trust on such matters told me to make it a Tumblr, so I obeyed. I have made some minor edits in the process, including for clarity and correct grammar. I also had to just link to the video as opposed to embedding. Tumblr decided to crap out on me there. Other than that, the content is the same as it was before, other than being posted a day late.

I also may have removed all proof that I am involved in human trafficking because I don’t want to go to jail.