Bisse here again, dropping in to give a little progress report on the gameplay and combat side of the game.
We just quietly hit a pretty big milestone. Here at ToG, we work in 2-week sprints, and this is our first sprint since - well, since I joined two years ago - that we have no ‘systems’ implementation work planned. What that means is this: all of our planned gameplay features and systems are implemented and working, without any major bugs/missing features.
What kind of systems are we talking about? Basically, the entire back-end of the game, and all of the planned gameplay features. The list includes:
Gun's Breeding (Fusion)
In-game dev tools for creating enemy encounters
Status effects and disables
XP and Levelling
In-game dev tools for working with all of the above
...and much more.
There are still many smaller things left, such as more in-depth combat encounter scripting. But overall, this is a very important milestone, and this week marks the first time in forever that we are able to focus 100% on building content on top of the engine we've put together. Currently we are working on the Junk-bot’s, who pick up loose junk and parts to upgrade themselves during combat. To be honest, it’s quite liberating to be actively working on actual enemies and attacks rather than the systems behind them. Personally I consider this the most ‘fun’ part of game development!
So we've finally reached this point, but much of this work we are not yet ready to blow the lid on. Zaubers, for example, need more art assets, polish, and most of all more cast-able zaubers, before we are ready to show it off. So, there is a lot of work done that is not possible to show to you, our backers, yet. We know many of you have waited a long time to see how this game looks and plays, but we hope that you can wait a bit longer too see what we have, until we have created and polished the unique gameplay experience we have been working towards from the very start.
Bhroom here, coming at you in full effect with a post on Barkley Balancing! While we still haven’t shown all that much in regards to the later parts of the game, and we’re getting there, I thought I’d share some light on some techniques about how we are balancing the game. Also this will allow me to proclaim my affections for that sultry beauty we all know as Microsoft Excel.
RPGs are essentially all about numbers, those “numbz”, digits, and getting them arranged and represented in a way that not only shows you what is going on presently but more importantly, what’s gonna happen later is a huge help in the macro view of the game.
Here is what we’ve been doing.
Step One: Ask some Questions
How we’re doing this is starting very generally, and making assumptions about where you START and where you END our game. We asked ourselves these questions:
How strong are you at the end of the game compared to the beginning? Double? Quintuple?
Define “strong.” Is it just stats? Damage Per Second?
How much credence are we giving to less tangible combat abilities like dodge distance, overall run speed, random changes to hit or miss?
When do we think the average player can beat the game? (or game is Open World as well …)
Finally and most importantly, when will the player feel confident that he or she actually can beat the game?
Step Two: Make Wild Assumptions!
A good way to start is to assume that the game WILL be balanced (as in eventually). It seems scary, but by assuming this, you can be comfortable with any temporary scale you place on the numbers you’re working with. If I say the weakest I can be is level 1 and the strongest I can be is level 30, then I’ve already developed a system of progression in the game: every level (or step or battle or item, or whatever that signifies) gets you 1/30th of the way to MAXING out the character.
With this, we also have our Halfway Point: Level 15. It doesn’t matter how numerically strong level 15 is at this point because we are assuming we’re already making a balanced game, remember?
Okay, so level 15 is the halfway point in the game, but do we want level 30 to be the end? Well that would go back and automatically answer questions 4 and 5 above: The player is only able to beat the game at max level, so in turn we are taking the choice away from him or her. That’s no fun, especially if this was an open world game; we want to accommodate those players who rush to the end, driven by the narrative, and also the min-maxxers who are meticulously pruning their stats as they grind straight past the point of End Game and into the nooks and crannies of the game world.
So let’s throttle our End Game back and assume our balance is putting End Game at level 22, which in turn puts our Halfway Point now at level 11. That seems like it could be interesting… you can beat the game at level 33 but you also have another 8 levels AFTER you’re able to beat the game to find all the optional stuff, kill unkillable bosses, find unfindable treasures.
Looks something like this:
Step Three: Start Up Excel!
This is where the fun starts. Pull up Excel or OpenOffice or GoogleDocs (but know that real Excel is just the dopest thing ever.) And make a nice little table like this:
Pro Tip: If you have a sequence of 3 or more cells selected, click the little green square at the bottom right of your selection and you can drag it down to automatically add in all your numbers following the sequence above it. Swack!
Now, let’s add in some notes about what is going on at each level.
I arranged the table to not only show where the player is going to be, but also a rough guess as to the “best” enemy they are encountering at that point. Normally ,this would be the NEXT enemy you are encountering since as you gain levels you want a consistent, interesting challenge without, of course, committing the Ultimate Sin of Vidcons: Level Scaling (not actually a sin).
Also in there is a little narrative note about when certain things should be playing out. Even in an open world game, you have to start somewhere … might as well be the “LCP” (or terrible acronym I just made up), the Lowest Common Playthrough.
I call the LCP the basic game, the game that anyone would play without trying to bend or break the rules. Without breaking every pot for every rupee or following every side quest to its end. It’s the standard game, starting at exactly the right level, and playing it while always taking the most logical, most probable, most popular decision at each moment. The safe game. I use this term a lot!
Now, I’m feeling pretty good about this make-believe game. (Especially since I still maintain it is eventually going to be balanced anyways.) And now I know where my enemies are being dropped in and how strong they are compared to the other enemies before and after them. I can continue to tweak this very simple table over and over through development to continue to refine the progression of the game.
Step Four: Decide what to Balance
So if you’re making an RPG, there are plenty of places to start your balance. Do you figure out how much HP everything has? Or how about the strength of your weapons?
The answer is wherever you want. The amount of HP an enemy has is meaningless without the relative notion of how much damage you can hit it with. HP=1000000 means little when you deal 200000 points of damage on a single hit. That’s only 5 hits!
Aha! We’ve found what actually needs to be balance though! Damage Per Hit! The better question would be “How many times does the player need to hit the Weredog to defeat it?” rather than “Wouldn’t it be so cool if Weredogs had like … 10 million hit points?! That’ll really mindfreak the pundits!”
And that’s not the only number that means something! If it takes 10 hits to beat the Weredog, but the battle system only allows you one hit every 1 ½ minutes, then you’re looking at a 15 minute battle. Is that long? Is that short? Regardless, the balance is now a question regarding TIME and we’re suddenly talking about Damage Per Second.
While DPS is so often obsessed over with MOBAs and everything else that I’ve never actually played, it does do something very beneficial in boiling down the game experience to uses time as an equal (NOT relative) standard throughout all playthroughs of the game. The LCP of your game will show that all of the same enemy at the same time-frame of the game takes the same amount of time to defeat. That sounds boring but on the contrary, that’s very good! You now have a stake in the actual feel of the world. You now have the power to know that when you pit a player against a certain challenge, you can predict what’s gonna happen and in how long.
Step 5: Realize that you should really be balancing your game against Play Time
Hopefully you’ve already done that! Now it’s time to make some lines. And the best way to make lines is with Wolfram|Alpha.
Step 6: Play with Wolfram|Alpha
If you don’t know what this thing is, just go here and start typing in things … anything you want really. The idea is that is uses the power of an incredibly complex computing program called Mathematica to attempt to interpret anything and everything as computable data.
But it does even a more baller job at showing you how formulas will work on a graph. If you can think back to sophomore math, you can start to apply lines and graphs that project where you want your numbers to go. Take this formula for example:
Pretty simple: you get 15 HP to start and 8HP per level. It’s always wise to start yourself with a base (15) to buffer the bottom end of a weaker character. Also we have a variable for the level, and how much it gains. Wolfram|Alpha shows us this.(Oh there is a Pro Trial that gives you Interactive graphs … it’s worth it for $0 for the trial month or even $5.49 each one after!)
This formula makes a solid little line.
Step 7: Party with Excel
Let’s just run with it and plop it into Excel. Next thing I do is make every constant a variable. So it looks more like this:
Okay now let’s make a new sheet in our Excel form here (in case you didn’t know):
And now I’m going to add my constants. These are actually variables in our formula which means we’ll be able to change these numbers throughout the balance (and game) easily.
ProTip: I use the Cell Style->Input to mark the constants I can change in orange. That way if anyone else looks at my balancer they can easily see what numbers to change.
So now we plot out the 1-30 level and our first formula (which I am calling “Flat8”). Now what I’ll end up doing is writing a formula that pulls in both the constants that I used above and the level variable that will adjust the HP.
So I typed in “=$G$2+A2*$G$3” and you can follow the color coded arrows to what they reference. Excel uses order of operations so I didn’t need parentheses but it probably would be a good idea to have them in.
I also use absolute references (“$”) when I refer to the coordinates of cells that I don’t want to move if I copy that formula to a new cell. The $ locks the Alpha or Numeric coordinate, or both. So that means regardless of where I paste this formula, $G$3 alllways points to my hp_lvl constant. You can also use only 1 absolute reference if you are trying to use a column or row of different values along with the cells you are trying to compute (such as “A$1” would start with A1, but then also copy over to B$1 and C$1 and so on).
One more thing I do that I think everyone working with Excel should do: MAKE THIS A TABLE! Select those two columns, Level and Flat8, and then click Format as Table, select a style and include your headers. Now you’ll have a fancy sortable table here:
ProTip: Be sure to name it in the Design Tab. This will let you reference your columns muuuchhhh easier (instead of continuing to update something like “=B2:B31”, you can just write “=HRplot[Flat8]” and it will always stay current, which is incredibly helpful in large workbooks.)
Now let’s go back to question #1: How strong are you at the end of the game compared to the beginning? Double? Quintuple? … much more?
I’d approach the answer like this: For each factor the end stats grow above the beginning stats, the less player control over those stats becomes apparent, since any one decision does not affect your character performance as much. Some would also say that you get a greater sense of growth if you have something like 100 HP in the beginning of the game and 10000 at the end (think Disgaea), but I would argue that the players acknowledgement of growth can come from even a single digit change as long as it is powerful enough to change the way they play.
By stretching the range stats grow you’ll also have a broader field of numbers to use for each of your enemies as they progress in the balance (this could make the balance EASIER or HARDER however … be wary!)
So there’s a lot of ways this decision can affect your game, and these formulas are going to really show their true capabilities as you start graphing them out. (Since Barkley is an open world game, we are keeping the stats relatively tight, with HP numbers in particular about 4 times larger from beginning to end.) In this example we start with 23 and end with 255 (a holy vidcon number) so around 10 times larger.
Alright this update/tutorial is getting ridiculous, so I might start wrapping this up as “Part 1.” Let’s do one more step!
Step 8: Exponents
These really make your game much more dynamic! We use them a lot in B2 stats and you’ll soon visually see why. If I add in exponents, the returns on something like HP have greater yield the higher the numbers are. I added in this formula:
Or with constants:
Now you'll see that the HP numbers start much lower but begin to grow more and more:
I also added in a “Diff” table that just checks the difference between the values at each level. You can see that at level 11 (Our Halfway Point from before) we are short a whopping 40HP (C13 to D13), but we’re getting 8 per level (E13). Then the second half of the game we are getting a lot more HP per level and by level 22 (End Game) we’ve made it to 193HP, a touch over the 191HP from getting the Flat8. After that, things get wacky and we’re at 336 before you know it!
Step 9: Make a Chart to Impress your Dad
This is as easy as selecting the table, clicking Insert and then perusing the Charts and Recommended Charts areas. Since you’ve named the table, all your labels should be made automatically. You’ll get something like this:
That’s a beeeeauuuuttt!
I think this covers a pretty hefty and possibly completely rudimentary and unnecessary how-to about using one of the world’s most popular programs. But maybe it can help people?!
Does anyone want more? No?! More Barkley you say?!
Did you know?
I used =FLOOR() AND =CEILING() functions (which round numbers down and up) to clean up my data in the table above. You can also use functions to look up and compare and choose data in cells. Much like you’d use in any coding language! This ends up making Excel incredibly powerful and able to crunch and visually represent thousands of numbers and charts instantly.
I could go in and share some of my favorite Excel functions and how to use them, but this update might have killed all interest in my talking anymore. I guess let me know below if you want to see! The next one will be much more concise.
Also I’ll share this excel file here. You should be able to download it as you please.
Hi again, stalwart ballers! @SveTob here again, this time to show off a vile beast of the swamps of Necron 7. (How did a swamp end up in a space ziggurat again?) We’ve showed off the swamps before, but this guy is a new resident.
Say hello to Mr. Were-snail!
The Weresnail is a ‘tank’ style enemy. He moves slow in water and even slower on land, but can take a heavy beating before going down. His shell also repels your shots if you fail to hit his body.
He doesn’t look like much of a threat, and he isn’t, if you can keep your distance. But the thing with that shotgun he’s holding is, in Barkley 2, heavy weapons mean heavy weight, so to wield the strongest weapons you’ll need the raw muscle mass (M.IGHT) to back it up, or you won’t be able to hold the weapon. These Were-snail guys, they’ve got some muscle mass. So, if you get in range for that shotgun, you’re done for.
Another reason to avoid him is his shell. Bullets are in short supply, so you can’t affort to spray-n-pray and waste bullets by having them bounce off like that without doing any damage. It also means you can’t hit him from behind. Either make sure you can kill the Weresnail calmly and safely... or run away.
The swamps are filled with dangers that you will need to think quick to avoid, this is not one of those, but you always need to mind your surroundings because you do not want to end up cornered by a Were-snail.
That’s it for today! Happy Holidays!
(hey it's me Bhroom, this is my solemn oath to post a "Balancing Barkley/MS Excel Love Tribute" by the end of the year! there, I've said it now I have to do it!)
Bisse, or @SveTob here, one of the developers on Barkley 2 and lead programmer. I thought I’d drop in to deliver a small little window of insight into the inner workings of programming on a project as large as Barkley 2. In this update I’m going to dive into some very technical details, hopefully some of you will find this interesting!
One of the issues plaguing the devs for some time in the beginning, was collisions. We wanted smooth movement and enemies that come in many shapes and sizes, plus it had to have good performance.
The first naïve implementation was to use standard bounding box collisions. This works fine in most cases but the more we expanded the game we started to notice it creating odd situations. Let’s look at the Booty Bass scene:
Here, navigating between dancing dwarves (the red-dashed box turned out to be rough and feel ‘sticky’). Notice the collision shape of X114JAM9 and the dancers - if the distance between the dancers was not large enough in both the X and Y axis to fit his collision box, X114JAM9 could not fit through! You can see in the screenshot that the collision box for the player is just too big to fit between the dancers in the middle. There were similiar problems when designing narrow pathways at a 45 degree angle. Now look here:
To fit between these generic FPS cliché crates, you had to align X114JAM9 perfectly so that he would fit through. Not only did this feel wrong and “sharp”, but the game adjusts speeds based on framerate, so on too low framerates, X114JAM9 moved too many pixels per ‘frame’, meaning positioning yourself to fit through could actually be impossible!
So we knew we wanted a collision system that did these things:
Allow for many types of collision shapes
Help ‘smooth’ the player and other objects around corners, NPCs and other obstacles.
High performance was especially important because the game has gigantic maps containing hundreds of intelligent enemies and upwards of thousands of various particles like bullet shells and blood spatters. They are all moving, collision-checking, and sometimes pathfinding through the maze.
After doing some research I decided to overhaul the collisions into a new system based on SAT (Separating Axis Theorem). You can read more about SAT over at this awesome tutorial, but in short, it tries to find gaps between two objects. If it cannot find any gap, then it is guaranteed that you have a collision. And as an added bonus, the calculation gives you a ‘projection vector’ which is an arrow showing how to move the object to escape from the collision.
All collision systems have advantages and disadvantages, for SAT they are:
Supports: AABB (Axis-Aligned bounding boxes), Circles and Polygons (triangles) of any shape
If two objects are not colliding, it is very fast to rule out a collision, because gaps can be found quickly.
If two objects are colliding, the computation is precise but very slow, since it must perform many checks to rule out there being any gaps, and the more complex the objects being checked are, the longer this takes
Requires extra computation to ‘eject’ an object from the wall it is colliding with.
The major drawback is it’s slow when you do have a collision, but fast otherwise. It’s also worth noting that this collision system is only used for collision between moving objects (like the player or enemies) and static objects or ‘rigids’. (like walls, pillars, crates, or NPCs that do not move) For collisions between moving objects we use a different, faster and much simpler, sprite-based collision, that only needs to return collision-or-no-collision and does not need to worry about ejecting objects from each other.
Now let’s look at a standard Barkley 2 action scene:
So as you can see there is some stuff going on, bullets and particles flying around, about ten enemies and the player, lots of stuff going on… but how many collisions are there actually? As in, collisions between an object and a ‘rigid’ like a wall, a rock or a pillar?
That’s right - none!
Object-to-wall collisions actually occur rarely in a top-down game. Which means that SAT is a perfect fit for a game like Barkley 2. Now remember the ‘smoothing’ the players around corners thing? We use a special implementation of SAT to accomplish this, here is what it does:
In this diagram, the circle has moved such that it is colliding with the triangle. The red arrow or ‘vector’ is the distance and direction the circle must move to completely escape the triangle, and what we do in Barkley 2 is we simply move the circle according to this vector. The dashed circle shows the final position of the circle after the collision check. There are some complications and corner cases when doing it this way, (e.g. what do you do if you’re colliding with several objects at once and thus have several vectors?) but that’s the gist of it.
Now let’s look at what happens when the player, represented as a circle, moves towards the corner of a square wall:
In this diagram, the player continuously moves towards the right.
Each ‘step’, or ‘frame’, the player intersects the wall and is moved outwards from the corner. Each time this happens, the circle moves not only back towards where it came from but also a bit upwards. Eventually, it has, smoothly, rounded the corner and can proceed the way it was moving. That means, if a player attempts to move around a corner or inbetween two objects, he will be automatically smoothed around the obstacles.
Finally, we use a modified Quad-tree (read about it here) to ensure things are only looking for collisions with walls that are just next to it. We pre-compute our quad-tree to the point that a lookup in it is a direct lookup in a data structure, meaning it has O(1) lookup time. This means we need to do some extra computation when opening up a new map, but in return, the map size does not affect collision performance at all. This was the final puzzle piece to make us able to create huge maps.
So that’s a fairly in-depth look into the Barkley 2 code! Hope you enjoyed it. Next time maybe i’ll write some stupid paragraphs about a bunch of dumb enemies, until then: stay round, rubbery and orange!
Hey ToGsters, this is Chef. Things have been going well at ToG HQ and work continues steadily on the game. We're wrapping up work on the endgame content and will hopefully get back to sidequest stuff in Brain City, Al-Akihabara and the Industrial Park pretty soon. We showed Barkley 2 and the working prototype of our turn-based b-ball strategy RPG minigame (tentatively titled "Tactics Ballre") at Florida Supercon early last month to boisterous fanfare and we'll be showing them again a little closer to home next weekend (8th to 10th!) at Otakon (the official convention of the Otaku Generation). Be there or die in obscurity.
But that's not why I'm here. Many a moon ago, I posted a video of some Barkley tunes I was working on. I thought it would be pretty cool to do a followup on some of the tunes that were in it. Although a few have fallen by the wayside and probably won't make it into the game, most have received some love and are sounding a lot better now. These aren't the only songs I've worked on, there are a lot that I've written since then, but here are a few of my favorites so far -
The first minute is what the song, pzone, originally sounded like and the second is what it sounds like now. It's a pretty drastic difference, hopefully for the better.
mauretania 2 is still a work-in-progress, but it's coming along pretty well. I've completely redone the intro, changed many of the instruments and added a rhythm guitar (it's actually a kanon. . . . . . .) Like I said, the song is still being worked on, especially everything after about 2:10. 2:30 on is still pretty bare bones!
punkboss started out as a piano tune; a lot of the time what I'll do is write down a song in piano so I remember the melody and come back to it later. I might work on it a little bit more, but it seems okay for now.
ass of the minotaur is a song that could have been in the original work-in-progress video but I left it out because at the time, it was a pretty boring 6 second piano loop. I thought people probably wouldn't care or understand that it was basically a sketch. I also didn't really expect to return to it. After sitting on it for 10 or however many months, I decided to mess around with it and ended up liking what I had.
carpfrug is a more recent track and one that's still a work-in-progress. I want to make it a bit longer and tighten up some of the melodies.
These aren't all the songs I've worked on since the video, but they're some of my favorites. Thanks for listening!!!!!!!!!!!!!!!!!!!
Oh, and one last thing.............................................................................. game on.