I literally only made this post so that I could say I have not yet missed a day. Okay, see ya!
Just kidding. Let's see... there was a little bit of heartache today, mainly involving rewriting code to allow arbitrary players to be controlled. I can say that we are ready to start implementing the logic behind all of the Cephalinian interactions. For instance, we need to begin working on ways to dynamically change dialogue based on the selected character as well as a more robust framework for denying entry to areas/interactions while controlling certain characters.
For instance, the first real playable part of the game will not be controlling Bodom at all, but instead Moroch. Spoiler alert: Moroch has a bit of a reputation around Cephaline already. But his main objective is to make it to Apolith's house (a failed venture anyhow). Clearly we don't want to give him access to all of Cephaline right off the bat, nor would certain NPC's be present while controlling Moroch.
Currently we are controlling this via a... uh... a plot state variable that we are changing at different times. This is basically a counter that increments upwards whenever key plot points/events occur. We have level loading/unloading callbacks implemented already, so really, it just boils down to writing a LOT of custom code to handle what objects should be present/what dialogue should be loaded/which scene transitions should be active/etc.
Anyhow, on the GUI front, we have reached a decent stopping point. Of course, there is more work to be done, but being able to see stats/use items is sufficient for now. Weapons, armor and skills are all hard-coded at the moment, but expect to read a lot of bitching about that later.
Since that's out of the way, this has freed Andy up to work on the world map, or at least... the early part of it. (About 1/5th or 1/6th of the total map). We have some ideas on how we'll create different enemy zones (probably use trigger colliders, easiest, most obvious solution). What I mean by enemy zones is basically assigning a probability to different groups of enemy encounters based on the area of the world map you are in. (Wow, that was a terrible sentence) This can be broken down further into certain regions (forested areas, roads, et cetera). It's also likely that certain enemies will only spawn in certain locations or zones. Keep in mind also, this is only talking about random enemy encounters on the world map as enemy encounters in actual dungeons will not be random. It's a lot to think about.
Until next time!
Tuesday, June 30, 2015
Monday, June 29, 2015
Cutscenes (Continued)
This post is not about Korn's masterpiece album. Sorry. It is, instead, about a very specific type of issue. We call them bugs. After a busy (yet productive) weekend, I managed to cobble together a few early cutscenes. This was not my first foray into cutscene creation, but I kinda went overboard with the new ones. Specifically, I wanted to talk about the two issues encountered today while attempting to record and upload a video of these cutscenes (Of course, Murphy and his law decide to show up at precisely that moment). Warning: this will be a fairly long and descriptive (aka boring) post.
After getting everything prettied up and presentable as much as possible, it was time to build the executable and run that bad boy. Right off the bat, as soon as Moroch stumbles down the stairs and begins to utter his first lines, a massive freeze-up happens, taking about two seconds to resolve itself. This hiccup, as it were, did not show up at all in the debug build (I believe that's the third or fourth law of programming, but don't quote me on it).
So we go back into the Unity editor. Unity, by the way, has an extremely handy tool that I had mostly taken for granted as a student and a younger developer. This little tool is called a profiler, and when hooked up to the program, immediately shows the culprit: the very first time we go to render any text, (but never any time thereafter), some random function decides to shit itself. I can't really follow it too deeply, but the actual issue seems to be something to do with loading cached fonts. Amazing. What is the point of a cache exactly?
So, we decided to consult the programming bible. After a quick google search, we found a bunch of different proposed solutions. Like any lazy bastard, I tried the 'fixes' in order of increasing difficulty (aka, changing a setting as opposed to needing to write a custom script). Despite our efforts, guess which method ended up working? Somehow, people are always able to find multiple solutions to these problems, but the easy ones NEVER work for me. Haha. Personal rant. Anyhow.
So, after a few modifications to a mostly-pieced-together script, we basically needed to 'force' Unity to load these fonts upfront. An unfortunate side effect of having the ability to dynamically change font sizes/styles is the fact that Unity, for some reason, needs to render all of this to a texture the first time you try to display it. The issue, mainly, is that Unity does not do this at the beginning of the script/program in any meaningful way. Basically, our custom script forces Unity to do just that, thus shoving this overhead to the beginning of the program and not in the middle of it.
With that out of the way, it was time to keep pushing on. The second issue had actually shown itself several times during development, but I thought I had killed it. That's the twelfth law of programming: Bugs never die. They just hide forever and come out every once in awhile like a nice swarm of cicadas/herpes.
This particular bug involves scene transitions. Specifically, during our scene transitions, we display a black texture laid across the entire screen. We smoothly fade from 0 (Aka, you don't see the black texture) to 1 (Aka, you DO see the black texture). Pretty standard stuff. We can control both sides of the transition, fading out (leaving a scene) and fading in (entering a scene). So far, so good.
When transitioning from cutscene to cutscene, Bodom's position in the scene actually changes as does his animation. For instance, at the end of the first cutscene, Bodom is laying down. At the start of the second cutscene, however, he is sitting on the bed, perhaps, not understanding how beds actually work. In order to produce an acceptable result, the position needs to change AFTER the fade out but before the fade in. This part is no problem at all--setting the position of something is more or less instant (or until the next update loop).
The issue, however, came about when trying to transition from one animation to the other. Without going too much into it, Unity handles animations rather nicely by providing what is called an Animator Controller. The way this works involves 'animation states'. There is a state for walking, a state for idling, a state for sitting, et cetera. Unity allows you to 'blend' between these states. It takes one pose and it takes the other pose, and over some amount of time, makes one pose match the other. For example, if you have an animation for idling and an animation for throwing a ball, without blending, you would simply go from idle immediately to having your arm raised in one frame's worth of time.
This behavior is clearly incorrect unless your name is Dock Ellis. For everyone else, there is a smooth transition from having your arms at your sides to throwing a damn ball. But for the case of the scene fading in, we do not want this transition. The reason why is because we basically want this transition to occur while the screen is completely black. We want it to happen before the fade in entirely, so that as soon as the alpha value begins to change, we can see that Bodom is already in the correct pose. There is a small window of time available in which to do to this. Basically, this required me to guess a bunch as to how long I waited to start the animation transition so that it would not be visible at all.
There were two immediate solutions to this: one bullshit one and one moderately ok one. I obviously went with the former, but with a slight modification to make it less bullshitty. Since that's what I went with, and I know the tension is palpable already, I'll explain the second solution first.
The moderately ok solution is to actually just set the animation transition from laying down to sitting up to zero. In this way, there would be no actual timing window (we hate timing windows) in which I needed to start the transition and I could do it immediately once the scene had loaded, but before the screen transition had started. The main drawback to this solution is that any other part of the game that would want to use this same transition would also have no actual blending. The main point being, it's fine to transition without this 'exit time' as long as the character cannot be seen. If the character can be seen, however, it's just not realistic (but it is slightly humorous).
This could still work, however, but would require different states for the same animation transitions: ones without exit time and ones with exit time. While it would fix the problem without actual code (which is always a plus), it would cause other issues down the road with maintainability and complexity. (two big minuses)
The first solution is pretty cheap: basically, we insert an artificial delay every time we are loading a scene. This means that the screen is guaranteed to remain dark for at least some pre-defined amount of time. This has a few issues: first off, it's an artificial delay, and it's almost never a good sign when you need one for something. Second, if the delay is only a half a second and the transition takes a full second, then guess what? YOU SOLVED NOTHING.
Sorry for yelling. Ahem. So, the modification was to account for this extra time if it existed and essentially only delay if the exit time was greater than zero. This meant that there was no possible time frame in which the character could be sliding around like an idiot, instead of sitting down and shutting up as he was told.
OK. That's all for now. Thanks for reading.
After getting everything prettied up and presentable as much as possible, it was time to build the executable and run that bad boy. Right off the bat, as soon as Moroch stumbles down the stairs and begins to utter his first lines, a massive freeze-up happens, taking about two seconds to resolve itself. This hiccup, as it were, did not show up at all in the debug build (I believe that's the third or fourth law of programming, but don't quote me on it).
So we go back into the Unity editor. Unity, by the way, has an extremely handy tool that I had mostly taken for granted as a student and a younger developer. This little tool is called a profiler, and when hooked up to the program, immediately shows the culprit: the very first time we go to render any text, (but never any time thereafter), some random function decides to shit itself. I can't really follow it too deeply, but the actual issue seems to be something to do with loading cached fonts. Amazing. What is the point of a cache exactly?
So, we decided to consult the programming bible. After a quick google search, we found a bunch of different proposed solutions. Like any lazy bastard, I tried the 'fixes' in order of increasing difficulty (aka, changing a setting as opposed to needing to write a custom script). Despite our efforts, guess which method ended up working? Somehow, people are always able to find multiple solutions to these problems, but the easy ones NEVER work for me. Haha. Personal rant. Anyhow.
So, after a few modifications to a mostly-pieced-together script, we basically needed to 'force' Unity to load these fonts upfront. An unfortunate side effect of having the ability to dynamically change font sizes/styles is the fact that Unity, for some reason, needs to render all of this to a texture the first time you try to display it. The issue, mainly, is that Unity does not do this at the beginning of the script/program in any meaningful way. Basically, our custom script forces Unity to do just that, thus shoving this overhead to the beginning of the program and not in the middle of it.
With that out of the way, it was time to keep pushing on. The second issue had actually shown itself several times during development, but I thought I had killed it. That's the twelfth law of programming: Bugs never die. They just hide forever and come out every once in awhile like a nice swarm of cicadas/herpes.
This particular bug involves scene transitions. Specifically, during our scene transitions, we display a black texture laid across the entire screen. We smoothly fade from 0 (Aka, you don't see the black texture) to 1 (Aka, you DO see the black texture). Pretty standard stuff. We can control both sides of the transition, fading out (leaving a scene) and fading in (entering a scene). So far, so good.
When transitioning from cutscene to cutscene, Bodom's position in the scene actually changes as does his animation. For instance, at the end of the first cutscene, Bodom is laying down. At the start of the second cutscene, however, he is sitting on the bed, perhaps, not understanding how beds actually work. In order to produce an acceptable result, the position needs to change AFTER the fade out but before the fade in. This part is no problem at all--setting the position of something is more or less instant (or until the next update loop).
The issue, however, came about when trying to transition from one animation to the other. Without going too much into it, Unity handles animations rather nicely by providing what is called an Animator Controller. The way this works involves 'animation states'. There is a state for walking, a state for idling, a state for sitting, et cetera. Unity allows you to 'blend' between these states. It takes one pose and it takes the other pose, and over some amount of time, makes one pose match the other. For example, if you have an animation for idling and an animation for throwing a ball, without blending, you would simply go from idle immediately to having your arm raised in one frame's worth of time.
This behavior is clearly incorrect unless your name is Dock Ellis. For everyone else, there is a smooth transition from having your arms at your sides to throwing a damn ball. But for the case of the scene fading in, we do not want this transition. The reason why is because we basically want this transition to occur while the screen is completely black. We want it to happen before the fade in entirely, so that as soon as the alpha value begins to change, we can see that Bodom is already in the correct pose. There is a small window of time available in which to do to this. Basically, this required me to guess a bunch as to how long I waited to start the animation transition so that it would not be visible at all.
There were two immediate solutions to this: one bullshit one and one moderately ok one. I obviously went with the former, but with a slight modification to make it less bullshitty. Since that's what I went with, and I know the tension is palpable already, I'll explain the second solution first.
The moderately ok solution is to actually just set the animation transition from laying down to sitting up to zero. In this way, there would be no actual timing window (we hate timing windows) in which I needed to start the transition and I could do it immediately once the scene had loaded, but before the screen transition had started. The main drawback to this solution is that any other part of the game that would want to use this same transition would also have no actual blending. The main point being, it's fine to transition without this 'exit time' as long as the character cannot be seen. If the character can be seen, however, it's just not realistic (but it is slightly humorous).
This could still work, however, but would require different states for the same animation transitions: ones without exit time and ones with exit time. While it would fix the problem without actual code (which is always a plus), it would cause other issues down the road with maintainability and complexity. (two big minuses)
The first solution is pretty cheap: basically, we insert an artificial delay every time we are loading a scene. This means that the screen is guaranteed to remain dark for at least some pre-defined amount of time. This has a few issues: first off, it's an artificial delay, and it's almost never a good sign when you need one for something. Second, if the delay is only a half a second and the transition takes a full second, then guess what? YOU SOLVED NOTHING.
Sorry for yelling. Ahem. So, the modification was to account for this extra time if it existed and essentially only delay if the exit time was greater than zero. This meant that there was no possible time frame in which the character could be sliding around like an idiot, instead of sitting down and shutting up as he was told.
OK. That's all for now. Thanks for reading.
Friday, June 26, 2015
Down the Road
Today was another day consisting mainly of cut scene creation. At this point of the game, we need at least three to four different cutscenes (yes, the early game has a few cutscenes, but we are looking at 5- 10 minutes worth before the player is actually unleashed on the world). Thankfully, all of these cutscenes occur in the same location.
That's not to say that this hasn't been a complete bitch though--something as innocuous as getting the player to sit on the edge of a bed is... uh... not really that innocuous at all. Much of this, however, is still a learning process. I'm sure there are easier ways to accomplish some of these things (like using a ControllerBehavior to manually shift the character over as he lays down on a bed).
The Status/Item GUI panels are more or less finished with the addition of a few scrollbar tweaks and character portraits. We plan on posting screenshots of these at some point for constructive criticism and hopefully, a little ridicule and perhaps a few outright insults.
As for future development, my efforts will be focused on finishing up these cut scenes and reworking the Cephaline dialogue. Basically, we'll need two versions of Cephaline: a nighttime and daytime scene. The daytime scene will represent our first real 'playable' section of the game and since the main character will be controlling Moroch, I'm sure there will be some fun involved in figuring out all the places, in code and elsewhere, that we idiotically referred to Bodom specifically and not his "Player" tag.
Andy will be focusing on designing the main fragment of the world map where the early game takes place. I imagine this will tie us both up for quite some time once we begin implementing random battles, enemy zones and whatever else happens to need implementin'. *spit*
That's not to say that this hasn't been a complete bitch though--something as innocuous as getting the player to sit on the edge of a bed is... uh... not really that innocuous at all. Much of this, however, is still a learning process. I'm sure there are easier ways to accomplish some of these things (like using a ControllerBehavior to manually shift the character over as he lays down on a bed).
The Status/Item GUI panels are more or less finished with the addition of a few scrollbar tweaks and character portraits. We plan on posting screenshots of these at some point for constructive criticism and hopefully, a little ridicule and perhaps a few outright insults.
As for future development, my efforts will be focused on finishing up these cut scenes and reworking the Cephaline dialogue. Basically, we'll need two versions of Cephaline: a nighttime and daytime scene. The daytime scene will represent our first real 'playable' section of the game and since the main character will be controlling Moroch, I'm sure there will be some fun involved in figuring out all the places, in code and elsewhere, that we idiotically referred to Bodom specifically and not his "Player" tag.
Andy will be focusing on designing the main fragment of the world map where the early game takes place. I imagine this will tie us both up for quite some time once we begin implementing random battles, enemy zones and whatever else happens to need implementin'. *spit*
Thursday, June 25, 2015
Menu Progress
Not much to report today as I spent most of it setting up cutscenes within Moroch's basement. I can say, however, that they be loooookin goooood. (Being humble is for sissies!) I did, however, add a few little tweaks, such as being able to transition to other transition nodes within the same scene itself. This essentially displays the fading/transitioning behavior as if you had actually loaded a new level, but doesn't actually do any of the heavy lifting. This is useful for a number of reasons, especially since we have not really nailed down level loading.
For example, we are currently treating interior scenes as wholly separate and loading them upon entrance. This part is fine. However, when you leave the building, it needs to completely reload the previous scene. For a scene like Cephaline, this is a pretty massive penalty to be incurred each time. Unity, fortunately, does provide several convenience functions that allow you to load in certain 'chunks' at a time, which will probably solve this issue entirely. However, it would require a rewrite and... you know, who wants to do that?
Da real MVP of the day though is Andy, who managed to slay Unity once and for all. No, seriously, try to search for Unity on google. It's gone. Entirely. We now have scrollbar functionality within the inventory menu, which, from what I understand, was quite the bitch to set up. With a few more tweaks, we should be able to show this thing off... at which point, we will decide that it looks like utter garbage and completely redo it all. Ok, that's all. Until next time...
For example, we are currently treating interior scenes as wholly separate and loading them upon entrance. This part is fine. However, when you leave the building, it needs to completely reload the previous scene. For a scene like Cephaline, this is a pretty massive penalty to be incurred each time. Unity, fortunately, does provide several convenience functions that allow you to load in certain 'chunks' at a time, which will probably solve this issue entirely. However, it would require a rewrite and... you know, who wants to do that?
Da real MVP of the day though is Andy, who managed to slay Unity once and for all. No, seriously, try to search for Unity on google. It's gone. Entirely. We now have scrollbar functionality within the inventory menu, which, from what I understand, was quite the bitch to set up. With a few more tweaks, we should be able to show this thing off... at which point, we will decide that it looks like utter garbage and completely redo it all. Ok, that's all. Until next time...
Wednesday, June 24, 2015
A day which will forever live in infamy
Today was a bad day. Sometimes you can just tell. It all started with Unity deciding to ditch the lighting that I had worked so hard on in exchange for some half-baked (literally), dimly-lit, back-alley lookin' shit. Thankfully, that was resolved very quickly, which brings up another crucial tenet of programming: sometimes things just fail to work, even if you haven't changed anything (or insist that you haven't, as is often the case).
It's just how it is: programs just inexplicably fail to produce the behavior you expect. Maybe they did at one time. Maybe they never did. Sometimes you literally won't change a thing, run it again, and voila! It works just like you expect. In this particular case (This is 99.9% programmer error, btw. Programs don't really just spontaneously change, but we like to fool ourselves into thinking that they do), this seemed to stem from Unity's new global illumination model, which, while being very nice, also tends to do its own thing behind the scenes. So, that was issue #1.
As we wiped off the blood and tears, issue #2 came screaming through like a bat out of hell. Fortunately, this was something that Andy was working on at the time, so I just ducked outside for about six hours straight while he took care of it (I usually just take 5-hour breaks). From what I understand, (I couldn't really get him to talk about it--he just kept mumbling and cursing and kept insisting that "Unity would pay"), Unity decided to wipe out about half of the scripts that he had worked so hard setting up. Apparently this can happen when Unity inexplicably crashes in the middle of doing something else and when you fire that bad boy up again, you'll find that random things... just don't exist anymore.
Ultimately, fixing this involved some esoteric sequence of steps that Andy found in a 1893 version of the Encyclopedia Britannica (actually, that's probably worth quite a bit, now that I think about it). I'm not even going to try to describe them here, but it involved removing all of the errant scripts (funny that you have to remove something that has already been 'removed') and rebuilding them from scratch. Needless to say, much of his day was spent simply 'resurrecting' these fallen scripts.
Of course, why would that be everything? Issue #3 was pretty much the bastard son of issue #2, which involved fixing the destruction wrought by that initial crash, which involved figuring out why the GUI was so horribly fubar'd. I'm actually pretty sure this was a blessing in disguise as it caused him to rewrite much of the GUI system to account for different resolutions (I sabotaged it, actually, just to get this to happen). Yes, we were always going to do this, but, you know... some other day.
What was issue #4? Ah yes, another inexplicable Unity thing. I know it seems like I'm blaming Unity a lot, but I can assure you that it has messed something up way less than I have. With such a good track record, it was only a matter of time before it started hanging out with the wrong crowd. Anyhow, again, completely inexplicable, but it turns out that several objects within Cephaline had taken on some ridiculous proportions (think of a table as large as a house) and apparently, additionally gained the ability to levitate. Going to guess that this has something to do with how Unity decides to merge scenes (Yes, it is the golden rule of Unity never to work on the same scene as another team member, but sometimes... it happens). I suspect that there is a line of code buried deep within the bowels of Unity that reads something like "If table in scene, make table big as hell sometimes". That's all 100% valid C#, by the way.
It's just how it is: programs just inexplicably fail to produce the behavior you expect. Maybe they did at one time. Maybe they never did. Sometimes you literally won't change a thing, run it again, and voila! It works just like you expect. In this particular case (This is 99.9% programmer error, btw. Programs don't really just spontaneously change, but we like to fool ourselves into thinking that they do), this seemed to stem from Unity's new global illumination model, which, while being very nice, also tends to do its own thing behind the scenes. So, that was issue #1.
As we wiped off the blood and tears, issue #2 came screaming through like a bat out of hell. Fortunately, this was something that Andy was working on at the time, so I just ducked outside for about six hours straight while he took care of it (I usually just take 5-hour breaks). From what I understand, (I couldn't really get him to talk about it--he just kept mumbling and cursing and kept insisting that "Unity would pay"), Unity decided to wipe out about half of the scripts that he had worked so hard setting up. Apparently this can happen when Unity inexplicably crashes in the middle of doing something else and when you fire that bad boy up again, you'll find that random things... just don't exist anymore.
Ultimately, fixing this involved some esoteric sequence of steps that Andy found in a 1893 version of the Encyclopedia Britannica (actually, that's probably worth quite a bit, now that I think about it). I'm not even going to try to describe them here, but it involved removing all of the errant scripts (funny that you have to remove something that has already been 'removed') and rebuilding them from scratch. Needless to say, much of his day was spent simply 'resurrecting' these fallen scripts.
Of course, why would that be everything? Issue #3 was pretty much the bastard son of issue #2, which involved fixing the destruction wrought by that initial crash, which involved figuring out why the GUI was so horribly fubar'd. I'm actually pretty sure this was a blessing in disguise as it caused him to rewrite much of the GUI system to account for different resolutions (I sabotaged it, actually, just to get this to happen). Yes, we were always going to do this, but, you know... some other day.
What was issue #4? Ah yes, another inexplicable Unity thing. I know it seems like I'm blaming Unity a lot, but I can assure you that it has messed something up way less than I have. With such a good track record, it was only a matter of time before it started hanging out with the wrong crowd. Anyhow, again, completely inexplicable, but it turns out that several objects within Cephaline had taken on some ridiculous proportions (think of a table as large as a house) and apparently, additionally gained the ability to levitate. Going to guess that this has something to do with how Unity decides to merge scenes (Yes, it is the golden rule of Unity never to work on the same scene as another team member, but sometimes... it happens). I suspect that there is a line of code buried deep within the bowels of Unity that reads something like "If table in scene, make table big as hell sometimes". That's all 100% valid C#, by the way.
Tuesday, June 23, 2015
Battle System Updates
In an effort to appear as if I am actually going to update this thing semi-regularly, I am going to semi-regularly update this thing once or twice. While this video gives a basic idea of the battle system, the main bread and butter behind the system is the potential to combo abilities, which in turn, stacks damage bonuses and provides additional effects on enemies.
Most of yesterday and today was spent implementing this part of the battle system (which amazingly, did not take long at all). As it stands, abilities have charge times that indicate how many turns must elapse before the ability executes. By carefully managing abilities, it is possible to set up your characters so that they attack a specific target in sequence, which triggers increased damage. Of course, enemies can do this too, so...
This essentially required storing the specific skill's target(s) at the time when it was selected. Previously, this was done only once (since abilities previously executed at the time they were selected and did not have 'charge times'.) Skills are then 'queued' up. Essentially, any time a character performs any action, all abilities in the queue are granted one charge. When the charge becomes greater than the required turn count, the ability will execute, in the order that they were first selected.
Of course, there were all kinds of little 'fun' issues that arose: for instance, if a character tried to use an ability on an enemy that had since moved from its initial range, the character would still attack it. Obviously not correct. Worse, if a character had been killed, but had an ability queued up, it would still execute it from beyond the grave. Straight up Freddy Kreuger shit. Or if an ability was queued up for a longer duration than it took for that character's next turn to arrive again. Just to name a few strange interactions that arose.
While many of those have been fixed, there are still issues. Corpses can block projectiles. Projectiles can fly over enemy targets if the character is standing on sloped ground (which leads to a wonderful infinite loop). If a character dies, its bounding shape does not reflect the position/orientation of its corpse. So on and so forth.
Despite these lingering issues, I can say with pretty high confidence that the battle system is mostly done, which is an extremely important milestone. Like more important than when we faked the moon landings to beat the Russians. You get the idea. As such, it's time to switch gears, which sadly, consists of designing several interior scenes and their associated cut scenes and dialogue. That being said, future updates will be sparse for a few days. (Unless Andy decides to hop on here for some reason, but let's be honest...)
Most of yesterday and today was spent implementing this part of the battle system (which amazingly, did not take long at all). As it stands, abilities have charge times that indicate how many turns must elapse before the ability executes. By carefully managing abilities, it is possible to set up your characters so that they attack a specific target in sequence, which triggers increased damage. Of course, enemies can do this too, so...
This essentially required storing the specific skill's target(s) at the time when it was selected. Previously, this was done only once (since abilities previously executed at the time they were selected and did not have 'charge times'.) Skills are then 'queued' up. Essentially, any time a character performs any action, all abilities in the queue are granted one charge. When the charge becomes greater than the required turn count, the ability will execute, in the order that they were first selected.
Of course, there were all kinds of little 'fun' issues that arose: for instance, if a character tried to use an ability on an enemy that had since moved from its initial range, the character would still attack it. Obviously not correct. Worse, if a character had been killed, but had an ability queued up, it would still execute it from beyond the grave. Straight up Freddy Kreuger shit. Or if an ability was queued up for a longer duration than it took for that character's next turn to arrive again. Just to name a few strange interactions that arose.
While many of those have been fixed, there are still issues. Corpses can block projectiles. Projectiles can fly over enemy targets if the character is standing on sloped ground (which leads to a wonderful infinite loop). If a character dies, its bounding shape does not reflect the position/orientation of its corpse. So on and so forth.
Despite these lingering issues, I can say with pretty high confidence that the battle system is mostly done, which is an extremely important milestone. Like more important than when we faked the moon landings to beat the Russians. You get the idea. As such, it's time to switch gears, which sadly, consists of designing several interior scenes and their associated cut scenes and dialogue. That being said, future updates will be sparse for a few days. (Unless Andy decides to hop on here for some reason, but let's be honest...)
Monday, June 22, 2015
Overview/Current Development
Little bit of background: I wanted to create this blog to give those who were interested a look at some of the underlying development work going into Bevontule. As many of you already know, Bevontule is an upcoming RPG being developed using the Unity game engine. As it stands, there are currently two of us working on the project and as such, we have tentatively set a conservative release date of October 19th, 2082, which is only a few short years away.
Working on an ambitious project with two people has its drawbacks, obviously, especially when we are both primarily programmers at heart (although Andy is capable of some really nice stick figure art when he gets going). Content creation is, and will always be, the most difficult part of this endeavor. The nice thing about Unity, however, is that, upfront, you have access to an insane amount of content (models, animations, particle effects, et cetera). These may not be the best assets ever (or even really make sense in the context of Bevontule), but they are passable for now.
Having access to so much content already allows us to focus our efforts on the underlying systems and framework. Since this is a development blog (and possibly a confessional on some days), we should probably talk about actual development. Here is a list of some of the features and modules that we have implemented:
-Waypoint handling (Unity makes this a breeze)
-Cut Scenes (Unity makes this less of a breeze and more of a strong gust)
-Dialogue and associated GUI elements and scripting
-Interactions with objects (treasure chests, dialogue, custom events)
-Items/Inventory System
-Skill/Attribute System
-Character controllers and subclasses (CharacterBattle, CharacterAlly/Enemy, etc.)
-Scene transitions/screen transitions (fading, swirling, etc)
-Custom animator controllers
-GUI Elements (Status window, Item window, etc)
-Enemy roaming, chasing behavior
-Battle system (About 75% done)
Additionally, we have created the following cutscenes:
"Intro" (Need to sharpen this up with a better camera positioning/interpolation script)
"Outside Atonia" (Needs touch-ups)
The smash sequel: "Inside Atonia" (Needs an exit transition)
And the following actual scenes:
"Atonian Wilds (Shoreline)" (Still needs enemy placement, transitions)
"Atonia Interior"
"Cephaline" (Needs... a lot, still)
Our current development efforts are focused on two primary goals: finishing and tweaking the initial implementation of the battle system and creating a prototype GUI system to be used when in the main menu. Specifically, the battle system is functioning, more or less, as envisioned. It is now possible to queue up commands to be combo'd, and the battle-specific GUI has been polished (still far from being final). This is not to say that it is anywhere near being finished, as a whole, as there is still the massive question of enemy AI. But for the most part, we are quite pleased with the way it plays thus far.
In terms of the main menu GUI, the status panel has been finished (displays character attributes, EXP levels, etc.) and the item panel is mostly functional. On that front (are you really still reading this?), we still need to design the equipment and skill panels (will likely require a few weeks of work) as well as connect the internal skill system with the display itself.
So now that we have discussed the past and the present, let's talk about the past again. Our long-term future development plan for Bevontule is to first and foremost, create a playable demo, comprising nearly four to five hours of solid, balls-to-the-wall, edge-of-your-seat paranoia and existential doubt.
Basically, what I'm saying is, if you don't need a gallon of Peptol Bismol after playing our demo, then we have failed.
We expect to have the following features implemented (we set a hard seppuku-related deadline of six months, so expect us to deliver or de-liver):
-Random encounters / World Map
-Basic quest system (We are NOT going down the Xenoblade/Skyrim/Farmville route)
-Crafting/Gathering (Expect more details on this mini-game one day)
-Dynamic leveling of enemies / time-based respawning, randomization
-Lots of custom inspector panels
-Branching dialogue / options
-Saving/loading game data
-Finished/polished battle system
While this may seem like a short list of features, it kinda is. That's because I have probably forgotten a million things. Nevertheless, the bulk of our work will be in creating this 'c' word we keep referring to: content. But, basically, the overall goal is to whittle Bevontule down until there is nothing left to do, save for the actual content itself. And we got our whittlin' gloves on.
Working on an ambitious project with two people has its drawbacks, obviously, especially when we are both primarily programmers at heart (although Andy is capable of some really nice stick figure art when he gets going). Content creation is, and will always be, the most difficult part of this endeavor. The nice thing about Unity, however, is that, upfront, you have access to an insane amount of content (models, animations, particle effects, et cetera). These may not be the best assets ever (or even really make sense in the context of Bevontule), but they are passable for now.
Having access to so much content already allows us to focus our efforts on the underlying systems and framework. Since this is a development blog (and possibly a confessional on some days), we should probably talk about actual development. Here is a list of some of the features and modules that we have implemented:
-Waypoint handling (Unity makes this a breeze)
-Cut Scenes (Unity makes this less of a breeze and more of a strong gust)
-Dialogue and associated GUI elements and scripting
-Interactions with objects (treasure chests, dialogue, custom events)
-Items/Inventory System
-Skill/Attribute System
-Character controllers and subclasses (CharacterBattle, CharacterAlly/Enemy, etc.)
-Scene transitions/screen transitions (fading, swirling, etc)
-Custom animator controllers
-GUI Elements (Status window, Item window, etc)
-Enemy roaming, chasing behavior
-Battle system (About 75% done)
Additionally, we have created the following cutscenes:
"Intro" (Need to sharpen this up with a better camera positioning/interpolation script)
"Outside Atonia" (Needs touch-ups)
The smash sequel: "Inside Atonia" (Needs an exit transition)
And the following actual scenes:
"Atonian Wilds (Shoreline)" (Still needs enemy placement, transitions)
"Atonia Interior"
"Cephaline" (Needs... a lot, still)
Our current development efforts are focused on two primary goals: finishing and tweaking the initial implementation of the battle system and creating a prototype GUI system to be used when in the main menu. Specifically, the battle system is functioning, more or less, as envisioned. It is now possible to queue up commands to be combo'd, and the battle-specific GUI has been polished (still far from being final). This is not to say that it is anywhere near being finished, as a whole, as there is still the massive question of enemy AI. But for the most part, we are quite pleased with the way it plays thus far.
In terms of the main menu GUI, the status panel has been finished (displays character attributes, EXP levels, etc.) and the item panel is mostly functional. On that front (are you really still reading this?), we still need to design the equipment and skill panels (will likely require a few weeks of work) as well as connect the internal skill system with the display itself.
So now that we have discussed the past and the present, let's talk about the past again. Our long-term future development plan for Bevontule is to first and foremost, create a playable demo, comprising nearly four to five hours of solid, balls-to-the-wall, edge-of-your-seat paranoia and existential doubt.
Basically, what I'm saying is, if you don't need a gallon of Peptol Bismol after playing our demo, then we have failed.
We expect to have the following features implemented (we set a hard seppuku-related deadline of six months, so expect us to deliver or de-liver):
-Random encounters / World Map
-Basic quest system (We are NOT going down the Xenoblade/Skyrim/Farmville route)
-Crafting/Gathering (Expect more details on this mini-game one day)
-Dynamic leveling of enemies / time-based respawning, randomization
-Lots of custom inspector panels
-Branching dialogue / options
-Saving/loading game data
-Finished/polished battle system
While this may seem like a short list of features, it kinda is. That's because I have probably forgotten a million things. Nevertheless, the bulk of our work will be in creating this 'c' word we keep referring to: content. But, basically, the overall goal is to whittle Bevontule down until there is nothing left to do, save for the actual content itself. And we got our whittlin' gloves on.
Subscribe to:
Posts (Atom)
