CLEANUP
Just wanted to give a quick update as to what we have been doing for the past few weeks and what our plans are going forward. In the weeks leading up to OGDE, we cut more than our fair share of corners and despite having immediately recognized some of these problems, we did not have time to properly address them. Now that the conference is out of the way, we can look at the bigger picture and more firmly establish exactly what still needs to be done. Spoiler: It's a lot.
The first thing we needed to do was get rid of our old repository, which is really just a fancy term for storing your project in such a way that two people can easily work on it at the same time. OK, that's not all it's for, but still, that's the basic idea. We've been struggling against a 2GB file size limit for a long time (seriously though, how is that a thing) and it was time to finally make the jump to something a bit more meaty. To put this into perspective, the repository's total size was just barely bigger than the actual installer for our demo. Yeah.
We spent a few days migrating everything from the old system to the new system, which also spurned a massive cleanup of our entire project folder structure, which is also something that has been needed for a very long time. The largest part of this was cleaning up unused assets. Seriously. We had about 7 gigs tied up in assets that we didn't even use, scripts we didn't need and a whole plethora of other 'goodies' that otherwise sit there gathering dust. Our small recycle bin grew three sizes that day.
We also took this opportunity to upgrade from Unity 5.1 to 5.2, which I can't even talk about without getting irrationally angry. But I will try. While I do not fault anyone in particular for this, any person that has ever used Unity will attest to the fact that something WILL break when you upgrade. Flat out. Doesn't matter if you aren't even using Unity or never had it on your computer to begin with--it will find something to break. Crisp, clean graphics, you say? 60 FPS? Not anymore, your graphics card is now a baked potato. Seriously, I encourage everyone to try to upgrade from Unity 5.1 to 5.2... I hear there is a large reward if you are able to do this without issue.
Anyhow, after hunting down the sources of these weird peculiarities (or so we hope), the project is back to its former glory. Whole, intact; weary and injured, but functional. The next thing to do was actually dig into the code itself.
THE CODE ITSELF
It takes an alarmingly small amount of time to write enough code to majorly confuse yourself. In our case, it took us about two months--then we ran with it for another three or four. Point being, maintaining and refactoring is honestly probably more important than writing the code itself. Any idiot can write it, but it takes at least two idiots to go through and clean it up. So that was the first thing on our agenda, stepping through line-by-line. This is a very boring, but amazingly satisfying part of programming which usually involves the following steps:
- Find something of interest: what does this variable/function/class/structure/file/prefab/block/etc. do?
- "I don't know"
- "I don't either."
- Find all references: No results found
- Delete it
- Program breaks next time you run it
- Put variable/function/class/structure/file/prefab/block back where you found it
- Go to step 1
After you go through that list of steps about fifty times, your code is production-ready. In all seriousness though, we have essentially firebombed the shit out of everything and salted the earth as a precaution, so that even if we wanted to rebuild it, we couldn't, which is for our own protection.
Seriously though (double serious), we tidied it up a lot. There are a lot of reasons for doing this, but the biggest one, by far, is so that the intervals at which we have to do this kind of cleanup are ideally reduced. Programming is like evolution: shit stacked upon shit. The key difference is that evolution has no real guidance, whereas programming does. This makes programming about a million times more dangerous and unwieldy. But it also means that your programming mistakes can be fixed if you go back far enough. Go too far ahead, however, and you have no chance of fixing it.
Without any more analogies: we fixed shit.
TRANSITIONS
We have also majorly revamped our transition system, which is responsible for removing the active character from one scene and placing him or her in another. This system, in a nutshell, handles questions like this:
- How does the character progress from one scene or area to the next? Is it trigger-based? Does it require an interaction on the part of the player? (Both cases are handled).
- What kind of graphical transition will occur? (Fading/swirling/etc.)
- Will this transition actually load a new scene or will it just put me somewhere else in the same scene?
- If it does load a new scene, what types of things do we need to preserve between scenes?
- If it loads the same scene, but in a different position, what changes do we need to make? Say, if we're going into a battle scene.
We have gone back and forth many times on the question of whether battles would actually take you to a different scene or not. Ideally, you would only want to load a new scene in the case that it is absolutely required, but for whatever reason, we decided early on that battles would actually place you in a completely different scene. What I mean by completely different scene is that a function call is necessary to force Unity to load the new scene. Loading a new scene takes time and as such, we would like to do it as rarely as possible.
The entire combat system was predicated on the idea that the scene you were loaded into (in battle) would have specific objects in it that were necessary for battle and that these objects would be destroyed (or cleaned up) automatically once you left the battle. A large motivation, too, for having all battles take place in a separate scene was that we could have a scaled-down version of the scene in question. Unfortunately, we never really did this and opted instead to make direct copies of each scene for use in battle. This is a terrible idea and requires not only maintaining the original scene, but also keeping those changes up to date with the battle scene itself. The only real case in which this makes sense is for world map battles, where the battle scene HAS to be a different scene.
Instead, we now have it set up so that a battle can take you to any scene, including the same scene. This requires massive changes in too many things to list, but many of them have already been implemented. This gives us a crazy amount of flexibility in how battles happen in the first place, but the main takeaway is that loading into battle now takes a fraction of a second, whereas, previously, it took several seconds. This is huge, especially when it happens as frequently as battles do.
BATTLE UI CHANGES
Not much to say here except that some experimentation will be required in order to figure out the best way to display the information available. The main issue is that character information runs horizontally across the top of the screen. For battles of eight or less combatants, this is not a problem. However, if the number exceeds this (which it will), a different approach is needed.
The idea is that we would have all of this information run vertically along the right side of the screen instead. Sounds like a small change, but it has some pretty huge implications. In this case, vertical space is much more valuable, but we can also get away with 'sandwiching' each panel, or compressing it, rather, to a much smaller height.
The other main change is that these panels will need to be entirely revamped (regardless of how they are oriented). This change will probably happen concurrently with some major battle changes anyhow (for instance, order of turns is still confusing and we need an actual queueing system, instead of whatever the hell it is we're trying to pass for one). Additionally, characters need to display their charging skills AND the expected targets. This will require some thought and effort.
Finally, as learned from the conference, there is no actual visual indication that a combo is occurring and no real indication that they even exist in the first place. This will be easier to display once the necessary UI changes have been made, but the hope is that battles will be more intuitive and obvious.
NEXT STEPS
While there are still many, many things to do, our long-term plan is to actually make the game now. Despite how ridiculous that sentence sounds, I mean, actually start from the beginning and work our way forward, plot and all. We are highly satisfied with the way Molsha turned out, but it too, will require a few changes going forward. At the same time, we need to flesh out the inventory and skills system, and specifically, allow players access to menus that allow them to customize their characters (and by allow access, I mean, actually make the damn things).
The overall idea is to focus on actually completing the first 'part' of Bevontule (now that much of the underlying framework is stable). The first 'part' of Bevontule, by our estimates, would comprise anywhere from 10 - 20 hours of gameplay and includes the following areas, in order:
- Intro scene/waking up near Atonia
- Atonia interior and associated cutscenes
- Cephaline (Medium-sized town)
- Cephaline area world map (Encompasses areas between Cephaline, Auvane, Molsha and Atonian Steppes to the south)
- Auvane entrance (and associated cut scenes)
- Cutscenes outside Cephaline (including refugees from Molsha)
- Molsha (first large-scale 'dungeon' and associated cutscenes)
- Atonian Steppes (second large-scale 'dungeon')
- More Cephaline/Atonia cutscenes
- The cutscene where Apolith kills everyone
- More cutscenes around Atonia
- World map south of Cephaline that connects Cephaline, Yelev and Sarcosa
- Optional dungeon?
- Yelev (Small village) and associated cutscenes
- Sarcosa (third large-scale dungeon)
So yeah, lots to do... the good thing is that we have bits and pieces of several of these locations designed already. The other bit of good news is that, as said before, much of the framework is in-place already, and ideally, it will take us considerably less time to design many of those places than it took us to design a single place when we were just starting out.
Once again, thanks for reading and keep in mind that the demo can be downloaded and played here.
