Monthly Archives: November 2014

Dreamblazers Devlog: Week of November 24, 2014

Last week’s achievements

* Got functional collision detection!!!

Current focus

Touching up various features.

Weekly goals

* Integrate animations with ORK
* Make the camera follow the player
* Experiment with EarthBound-style HP drain
* Experiment with one-turn-delay priority attacks
* Make functional ally-summoning enemies
* Design layouts for Seaside Slime Cove, Den of Kobolds and the Unicorn, Spring Lake Valley
* Write bestiary flavor text for remaining enemies

Comments

I’m pretty sure I won’t accomplish all of those goals in one week, but that’s everything I have at my top priority level. (Lower things on the totem pole include figuring out how to make cutscenes, figuring out how to make branching dialogue, figuring out how to make enemies visible in dungeons and on the overworld, and finding a pixel artist (best saved until after holiday craziness is over).) Functional collision detection was a major breakthrough, as the past several updates testify, and I’m glad to be done with it. :D

In other news, it’s that time of year for a Pokémon release, which normally means I disappear into the ether for 1500 hours. Thankfully for my productivity, though, Hoenn is only my sixth favorite region and after 1500 hours of X/Y I only care about five or so Pokémon that I didn’t already have. =P

Which reminds me (and the above concludes the progress segment of today’s update):

On my Musings blog I’ll write mini-reviews of every game I’ve played this year, but here’s the short of it: this has been a very good year for me in gaming, but also a good year for reminding me why I’m crazy enough to make an RPG in the first place.

Let me first say this: I’m not doing it for money. =P I spend so little that if I partnered up with someone and bought a second house for all cash, I could collect rent for the rest of time and do nothing. And no doubt you’ve heard people say that’s their dream. “If I had [X] money then I’d never work again.”

But that’s not me. I’m making Dreamblazers partly because I can’t not and partly because nobody’s making the kinds of RPGs I want to play. Or in the case of 2014, even when they make something genius like Bravely Default and Pokémon, something else goes very wrong in the process.

Often when an indie game developer says nobody’s making games suited to them, I start running for the hills because they’re talking about a zany high concept game or random genre bending “just because we can” or something along those lines—things satirized by The Optimistic Indie.

“They said my game is imaginative, personal and meaningful, but unpolished. Well yeah. I’m trying to educate an audience, not attract one.” –April 25, 2014

“Making a roguelike where you are a fashion designer riding a motorcycle. It’s called voguebike. Seriously, where do I get my inspiration?!” – June 22, 2013

“Writing a game about a young woman’s decision to leave her husband for a soldier whose child is robbed of his talent. It’s a platformer.” –October 8, 2012

“I hope that one day I will make the ‘Citizen Kane‘ of games: Greyscale, old-fashioned, not really interactive, you collect lots of coins.” – April 14, 2012

Not what I’m talking about, though! There’s no grand overarching game element that I feel is missing from the industry. Not one. However, there are also no games that I feel do everything I want simultaneously. I’m talking about normal encounters with enemies who are threats but not insta-kills, a hybrid of open-world exploration and linear progression, an equipment system with real decision-making instead of rote upgrade, super frequent boss battles of multiple-weak-enemy and single-strong-enemy and one-one-one-duel variants, no consumable items, highly useful status effects, and other gameplay elements brought together in one place.

And now I can get back to tinkering with that instead of handling “basic” 2D movement, so that’s pretty exciting! :D

Dreamblazers Devlog: Week of November 17, 2014 (General Computer Edition)

Sometimes a week’s surprises come from completely outside the realm of game development: my computer suddenly decided to not connect to the Internet anymore until after it had been on anywhere from 60 to 120 minutes. I’m still not sure that I’ve actually resolved it, but at least as of Saturday I’ve gotten it down to only happening sometimes instead of always, so I can stop the endless computer reset cycle.

Pathfinding before this week’s end, though. I really want to get over the hump here and get back to regular updates of much more interesting things like battle mechanics and balance. =P

Dreamblazers Devlog: Week of November 10, 2014

I’m starting to understand, Kirb old buddy, why it took you nearly a year to get 2D physics under control.

Placeholder 2D Movement Area

This has been a baffling past week in a way that I can only call the Unity equivalent of the unexpected discovery of the accelerated expansion of the universe and the proceeding need to posit and model dark matter as an explanatory hypothesis.

Put more simply: game physics always seem to be just a couple steps shy of operating in the way that one predicts. All the placeholder rocks in this picture—the big ones—have colliders (essentially hitboxes, defined boundaries for collision detection). I’m sure of this: I followed various tutorials multiple times each to make sure I did everything right. The placeholder characters have colliders. I’m sure of this because they can’t move through each other.

But the controllable character can move through mountains. Now, at first I thought this was like the opposite of dark matter: instead of seeing an effect on the universe and inferring the existence of invisible matter with certain properties, I see the absence of an effect and infer the non-existence of my visible matter.* That’s also how a certain scene in the st—oh, wait, spoilers!

Then I discovered something interesting. The controllable character can move through mountains, but the stationary character can’t; I can push her around the map, but not through mountains (or over the water). This means that the colliders always have been working, but somehow I’m unintentionally overriding them with my character movement script.

All of which means that now I’m on the hunt for a pathfinding solution. I need a way to check where I’m about to walk before I walk into it so that I can stop before I move instead of starting to move and then detecting whether I should stop.

The most promising solution I’ve found so far is unfortunately geared toward polygonal games—its own creator says that it’ll slow a tile-based game down quite a bit—so the search continues.

* The above concludes today’s game developer content. Now for a philosophical tangent: You may have heard the saying that “absence of evidence isn’t evidence of absence,” but that’s not a universal truth applicable to all situations at all times. To illustrate: the fact that I’ve never seen a coyote on my way to Las Vegas isn’t evidence that no coyotes live anywhere in that desert area, but the fact that I’ve never seen a coyote in my house is powerful evidence that no coyotes live in my house. This is because of probabilities—there’s no guarantee and not even necessarily a likelihood that I’d see coyotes while driving if they were there, but there’s an extreme likelihood that I’d encounter a coyote in my house.

So it would be reasonable to assume that my visible colliders somehow don’t actually exist if they have no impact. (I was still half-joking, though—it’s more likely that my colliders were broken than non-existent. =P)

Essentially, whenever an unpredictable agent enters the picture, like animal behavior or especially a person’s inner thoughts, then “absence of evidence isn’t evidence of absence” applies at its best. The fact that someone has never expressed interest in skydiving, for example, doesn’t mean that she doesn’t want to try it; it only means that she’s never felt a need to express it at a specific point in spacetime when and where you were within earshot. And so you learn and build relationships on the basis of suboptimal, incomplete knowledge about one another.

Speaking of intense romance, did you know that diamonds are thermodynamically unstable matter that will, over millions of years, eventually transform into graphite? So next time you consider buying a diamond ring, try looking into a box of pencils instead—they’re a more ultimate form of matter, the super saiyan to diamonds’ base form, battle-hardened and time-tested by years of entropy.

Dreamblazers Devlog: Week of November 3, 2014 (Overview Edition)

It would be a little silly to give a regular update two days after my last one, so instead I’ll recap everything I’ve done and look forward toward what’s still to come.

What’s Done

* Stat growth balance – I based my stat growth and experience point scaling loosely on Pokémon as a familiar starting point, but altered to my own ends. Stats are slightly higher across the board to compensate for the absence of an EV system. (And no worries: there’s no IV equivalent! A character on her first playthrough will always grow to be exactly as strong as herself on her second.)

* Core battle mechanics – Damage formulas, status effects, passive abilities, elemental resistances, and pretty much anything in the foundation of the battle system does what I want from it!

* Move balance – Another thing I loosely based on Pokémon. As a marginally competitive Pokémon player, a decision between Icy Wind, Ice Beam, and Blizzard is one of the clearest examples of good game design, so I adapted their principles and it’s turned out great. I don’t feel like I have any filler moves, especially in conjunction with…

* Enemy AI and balance – Of the 42 enemies I’ve tossed in so far, I’m happy with at least 35 of them in terms of how they act and how weak or strong they are. Since most of the enemies recur across many continents at different levels—yet again, Pokémon inspiration—the important ones are all really solid. Most importantly, they feel distinct: ogres are vastly more threatening than kobold rogues, but kobold rogues are quite a bit more annoying. I’ve played entirely too many RPGs—even RPGs that are among my favorites of all time!—where enemies are interchangeable pretty models, which is right near the top of my list of things to avoid.

* Equipment system and fashion subsystem – Inspired by Dragon Quest IX, but a lot more visible, the way you wear your clothes can give you hundreds of possible fashion bonuses. What you can wear also depends on your body type; a character like Evelyn who has wings can wear wing accessories but not a cape or cloak.

* Equipment and status menu layouts – Granted that they’re only boxes and alignment right now since I haven’t paid for any art assets here, but I’m pretty satisfied with how cleanly they’re laid out.

* Controllable animated sprites – I just wrote about this, but yes, now the player can actually move a character sprite around and it’ll animate properly. <3 Like in Chrono Trigger or Final Fantasy VI, I’ll only do four directions of sprites, but diagonal movement is still possible. (FFVI had that on staircases in the Fanatics’ Tower and Zozo; I bring up the comparison because, for budget reasons, my sprites will look a lot more like that than huge CT sprites.)

* First continent layout – The first few (mini-)dungeons and one or two towns are still to come, but the main continent itself is all set up. I might increase or even double its size, but the layout’s not changing much if at all.

And, of course, I’ve written a myriad of flavor text and dialogue. But that’s not gameplay, so it doesn’t count. =P

Still Upcoming

* Battle timing – Although I’m making a turn-based RPG for several reasons beyond the scope of this post, action RPGs are technically my preferred genre, so I’ve been trying to figure out how to keep battles flowing. Multiple attacks per turn with a limited window for inputs like Valkyrie Profile? EarthBound style HP drain? Reduce the battle party size?

* The point of the fashion subsystem – Okay, so dressing great increases your Style stat, but what does that do? In DQIX it didn’t accomplish much pragmatically. Do I pull a Zelos from Tales of Symphonia and have NPCs throw goodies at you for looking fabulous? How about borrowing from Dragon’s Curse (AKA Wonder Boy III: Dragon’s Trap) and locking out some obtainable items until you look good enough to earn them? Should Style affect battles in a minor way like the Luck stat in Fire Emblem?

* Extra battle mechanics – Celty’s battle gameplay is… different from most of my other characters. Without giving away any spoilers past the first 10-15 minutes, she has a hero code and never uses overwhelming force against her enemies even if she significantly outlevels them, so her visible stats don’t reflect her real battle performance. I haven’t finalized figuring out how I’m going to accomplish that code-wise, but it’s vital—and not only from a story perspective! Everything I do goes to the good of gameplay somehow. Other than that, the one major aspect of battles that I didn’t get rolling yet is enemies who can summon allies or reinforcements, like greatwolves calling more of their pack or kobold chiefs calling underling warriors. I know it’s possible in ORK Framework since others say they’ve done it, so I only have to figure it out.

* Priority attacks – This, on the other hand, is impossible in ORK right now—at least as far as I can tell! Priority attacks are moves like Quick Attack in Pokémon or Mercurial Thrust in Dragon Quest that always attack first but are weak as well as moves like Dragon Tail that always attack last but have a notable effect. One option for me is to outright commission the development of that feature. Another is to try out a delayed priority effect; instead of an attack going first and dealing weak damage, it could deal weak damage and make the next turn’s attack go first. I can’t remember ever seeing that in an RPG, so I might give it a shot just to see how I like it. This sort of thing is a perfect example of limitations drawing out creativity. =)

* Animation integration – Just because I can animate sprites in a vacuum doesn’t mean I know yet how to integrate them with ORK. I think I do know! …but animation is the one and only thing so far that’s been more difficult than I anticipated, so I rule nothing out.

* Full-fledged environment movement – Player characters need to interact with the terrain and the camera needs to follow them, so for as much trouble as it was, simply getting a character moving is only a first step! …so to speak. =P

* Cutscenes – I haven’t even touched the idea of making cutscenes happen since they’re one of my lowest priorities, but they’re certainly coming up!

* Additional environments – Like I mentioned above, I’ll need a few dungeons and towns. (Don’t interpret that as tons of work; SNES classics often had one-room “dungeons” or “towns” like Guardia Forest and Gau’s father’s house to create scenery variety—and I’m certainly learning from that mold!)

And, of course, I’ll need art assets and music and so forth, but the bulk of those efforts will be on other people rather than me.

Final Words

I’m probably forgetting a few things that I’ve done and a few things that I still need to do, but overall this is a pretty good review of where I’ve been and where I’m going. Good to regain some perspective after a long challenge and a recent breakthrough. : D

Dreamblazers Devlog: Week of October 27, 2014 (Success Edition)

Positive reinforcement, I thought. As soon as I manage to create a functional overworld sprite, I’m going to In-N-Out Burger and I’m ordering a 4×4 and that mass of beef will be the only thing I eat all day, but it’ll be worth it.

That was around ten or twelve days ago.

Negative reinforcement, I thought—and that was four days ago on Monday. No matter what, I haven’t been able to get past this hurdle. Until I do, I won’t write any devlogs. I don’t get to do that until I prove myself worthy!

And now… I’ve got it!

As I solved issue after issue, at first it seemed like everything was wrong except the sprites.

Chunks of the tile map somehow ended up on the wrong Z plane—something impossible to notice by looking at it from a 2D perspective—so it wasn’t that I was passing through them, but passing in front of them. I noticed it mostly by chance when I got so desperate that I started looking over every individual setting of everything.

When I finally had sprites bumping into each other, triggers were working but collisions weren’t even though they’re pretty much the same thing. I chalked that up to differences between Unity’s current 2D physics and the tutorials I dug up using older versions of Unity. (I’ve gotten colliders functional since then, though; this was another matter of individual settings and nothing wrong with tutorials or videos elsewhere.)

Throughout this process, my antivirus programs’ real-time scanning kept blocking permissions to save or access data and Unity doesn’t give any indication of why permissions are denied; Dr. Google resolved that one. I still don’t know why that hasn’t been going on forever or at least consistently since I didn’t change anything with my programs, to my knowledge.

And all of this to say no, not only did I have these tangential problems, but on the direct front, I can only string together a C# script for character movement and animation if my life depends on it. =P (To my credit, I actually did put together some of the code on my own. I went through many a resource to get the basic gist of it, but most of them avoided diagonal animation for simplicity’s sake, so I had to figure out that much on my own. (Not that I intend to have eight-directional sprites; like Chrono Trigger and certain cutscenes of Final Fantasy VI, they’ll move diagonally even if the sprites only face four ways.))

But now it’s done! At very least a sprite can move and collide with itself. I told myself that I’d have everything working by Sunday’s end, but I’m pretty sure that character-to-character collision detection was the third hardest part, sprite animation was the second hardest part, and the random surprise errors from left field were the hardest part, so character-to-terrain collision detection should be comparably easy.

…I hope!