2016 :
Aug |
Sep | Nov
| Dec
2014 : Jan | Feb | Mar | Apr | May | June | July | Aug | Sep
2013 : Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2012 : Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2011 : Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2010 : Jan | Feb | Mar | Apr | May | June | July | Aug | Sep | Oct | Nov | Dec
2007 : Jan | Feb | Mar | Apr | May | June
2006 : Jan | Feb | Mar | Apr | May | June | Oct | Nov | Dec
2005 : Aug | Sep | Oct | Nov | Dec
11/30/16 -Wednesday: SCREW
VERSION CONTROL, HAVING TOO MUCH FUN WITH
SOUND & MUSIC!!!
|
So, I was supposed to start working on some
version control. To be fair, not a lot of work has to be done.
I just need to create a
Github
repository for the project, create a prototype
branch, and check in the code. But damn if I'm
not getting distracted integrating sounds and music into the
game! SOUNDS EFFECTS
You know, it's a weird thing regarding sound effects. On all
the other Rose of Eternity games
I've made, I never had to put that
much thought into the bread and butter SFX. Menu cursor,
confirmation button clicks, etc. It was already in the game,
and out of everything I was doing to make those earlier games
as custom as possible, those effects (if changeable at all)
we're not on my radar. Fast forward to
today, and well... It's a thing now. I actually have to
implement it. And let me tell you, I had to sit back and think
a lot about it. Because I've never thought, "Oh yeah, when
moving the cursor, it has to sound
like this!". As I said, just not on my radar. I ended up
looking up some videos of other RPG's to get a feeling for
what they used, what worked well, what didn't, etc. I also
fired up some stuff that I had on hand.
Since I'm not looking to spend $ on anything during this
prototyping phase, I ended up using
Fantasy Menu SFX from the Unity asset store. It's good enough to get me
going, and has everything I need at the moment.
MUSIC Ah,
music. If SFX is something I have never given any thought to,
music is the complete opposite. I'm always thinking about how
to integrate music into my games. Anyone who has played them,
or followed this blog for a while knows how important video
game music is to me. Hell, I'd list it as one of the main
pillars for my games. One thing that
I've long wanted to do (I'm talking about since the good old
NWN days with Cry The Beloved) is
have dynamic music in my games. Not, what they call horizontal
dynamic music, where the music changes to another track when
something happens in the game, say a combat encounter starts,
or you leave a village and enter the forest. Well, I actually
do want that as well, but that's not what I'm talking about.
I'm talking about vertical dynamic music, where you have a
track that plays, and then depending on the event, maybe some
instruments are added to it, say, percussion. Nintendo has
been doing this for years now. Think about the music in some
Super Mario 64 water levels, where
the music removes some instruments when Mario goes under
water, and adds them back when he comes out. Or
Super Mario Galaxy during the first Bowser
fight, where the longer you fight him, a chorus is added to
the music. One thing that has
really inspired me is the music in the
3DS Fire Emblem games. Up until that
point, besides a few songs here and there, the music in those
games was passable. It wasn't terrible, but it wasn't the
best. All of a sudden, starting with Fire Emblem:
Awakening, it's like they got a whole new budget
or something. The music is absolutely superb, and one of the
best parts of it is the dynamic elements to it.
For most levels, there are "calm" and "fire" versions of the
songs. "Calm" is when you're in the menus, selecting what unit
you want to move, etc. "Fire" is when an
attack/heal/ability/etc. is happening on screen. The way it
transitions between the two is magical to behold, and for me,
one of the best parts of the game. You better believe that I
immediately went out looking for the soundtrack.
Now, their implementation wouldn't work for me, because all
the combat will take place on the board without transitioning
to some "attack" cutscene. The switch to the "fire" music
would only last 1-2 seconds at most.
No, the way I have figured out to use
it is with using the range between allys and enemies.
Basically, if anyone is within range of an enemy (or vice
versa), the music will change to the "fire" version, and then
move back to "calm" when not. At first, my
implementation just didn't seem right. The music did switch,
but it was jarring. It was then that I realized that I needed
to smooth the transition out. I needed to slowly fade out the
old music, while at the same time, fading in the new music.
Functions like the below ended up working out great for me:
private void TransitionMusic(AudioSource audioSource1Stop,
AudioSource audioSource2Start) {
print ("TransitionMusic");
StartCoroutine (FadeOutMusic (audioSource1Stop));
StartCoroutine (FadeInMusic (audioSource2Start));
}
private IEnumerator FadeInMusic(AudioSource audioSource) {
float volume = 0.0f;
while (volume < 1.0f) {
volume += Time.deltaTime;
audioSource.volume = volume;
yield return null;
}
}
private IEnumerator FadeOutMusic(AudioSource audioSource) {
float volume = 1.0f;
while (volume > 0.0f) {
volume -= Time.deltaTime;
audioSource.volume = volume;
yield return null;
}
}
Once I had this in, oh man, that dream I've had for, well, 10
years, finally came true. Hearing the music change when
getting within range of enemies was awesome.
Add in the other SFX I added, and well, this game is seeming
more and more like a game.
Good times.
Till tomorrow...
11/26/16 -Saturday: ABOUT TIME I
WROTE SOME UNIT TESTS...
|
Ah, good ole Unit Tests. When I
joined the industry in 2004, my company,
Vindigo, was all about
Extreme
Programming. One of the pillars of it is
test driven development. Unit tests in particular are pieces
of code that test particular components of your code, usually
the public methods in your classes. I won't go into all the
details of it, but unit tests give you some level of comfort
(when written properly) that if you make changes to the
functionality of your application, if tests pass, you probably
didn't break that much stuff. So from the start
of my career, I was taught the right way to do things. Then,
many years passed, we got
shut down, and in the next stage of my
career, test driven development sort of fell to the wayside,
in favor of "Get this shit out the door now!!!".
¯\_(ツ)_/¯
Recently, it has come up again as something that is very
important, which I am very happy about. Like I said, I know
better, but sometimes as a developer, you just don't have time
to write tests. Sometimes, stake holders don't truly
understand them, they just want results, and fast,
So now we come to my game. Even
before I started, I knew I wanted some level of unit tests, at
the very least. This game will be, undoubtedly, the largest
project I've ever undertaken. Add to it the fact that it's
going to be a commercial product, and well... I know I just
can't rely on QA. So I did a lot of research on the matter,
and learned all about the
Unity Test Tools and how to make use of
them. It's actually pretty straightforward, and
today, I was able to implement a couple tests classes, one for
my TurnOrder class (determines whose
turn it is to move), the other for my TileData
class (holds information like terrain details,
current unit standing on it, etc.). I feel good
that I'm moving in the right direction, and it's better that I
started doing it now, versus scrambling to do it late in the
game. Tomorrow, I'll look to write some more
unit tests where applicable, then start looking at doing
something else I know damn well I should have been doing from
the start: Source control. Till tomorrow...
11/25/16 -Friday: RUDIMENTRY
SCROLLING IMPLEMENTED...
|
The development train keeps up its momentum
with the latest implemented system: Map Scrolling. Yeah, I
know, it's not exacly sexy, but it's something that is super
important, and key to the look and feel of the game.
Now, as I've said over and over again, I'm still in prototype
mode, so I just whipped up something pretty rudimentry. I know
there are ways to to improve it, however, it does what I need
it to do, and that is all that really matters.
As for how it's implemented, it comes down to the following:
-
You can move the camera
left/update/down/right with the AWSD keys
-
If you move the mouse cursor to the end of
the screen, the map will scroll in that direction
-
The movement class has a boundary, defined
by the size of the tilemap itself. This makes sure that
you can't just keep scrolling in any direction forever.
The only real issue thus far (besides just a
general level of polishing) is that when scrolling is started
by the mouse cursor being on the edge of the screen, it only
goes horizontol or vertical. No diagnols at all. Diagnol
movement does work with the AWSD
keys, so I'm sure it's something small I'm missing. But not
going to waste any time on it at the moment.
Something else I'll be keeping my mind on in
the future is
Pro Camera 2D. This will, presumably, do
everything I want to do, out of the box. I'm very careful
about not using anyone elses assets, until there is no other
recourse. But it's something to keep in mind if I end up
needing to focus on other things down the line, instead of
wasting time re-implementing camera movement logic.
Anyway, gf course, after I added this new
scrolling functionality, you know I had to make a larger map
to take advantage of it. It was at this point that I had to go
back to my dreaded CSV files I used to dynamically load the
maps at run time. Ugh. I felt like I was that guy in
The Matrix who had been watching it for
so long, he could pick out the girl in the red dress, or
whatever he said. I'm sitting here making this map, looking at
a spreadsheet of numbers, losing my mind, but at the same
time, sort of seeing the patterns form enough to know what I
was doing.
There is some
software out there, called
Tiled Map Editor.
I have know about it for a while, but didn't
want to deal with it due to the fact that I would really need
an all inclusive solution, inclduing allow me to set triggers,
waypoints, units, etc., on a map. This software would only
allow me to create the map.
However, I just found out that you can export
your maps into a CSV file. While I haven't looked at it yet,
it might end up looking to be in the same format as mine, and
that could be a boon. A sort of
middle ground for speedy development of different maps, while
I continue to prototype things. As with everything else, I'll
just keep it in the back of my mind, as I begin to move on to
other important things.
Finally, with regards to keeping things in the
back of my mind, well, that's a bad idea. Sort of. I shouldn't
exclusively use my mind to remember things. I should use
software. For
Rose
of Eternity - Family & Country, I used the
very open
Google Code, which apparently shut down in
2016. I already knew it was going to shut down at some point,
and archive whatever used to be. I'm a little annoyed I can't
find what old project, but... Yeah, anyway, I'm thinking about
using the free version of
Trello. I just need something visual so I
can keep everything together as this project continues to
grow.
Till tomorrow...
11/19/16 -Saturday: DECENT TURN
ORDER GUI PROTOTYPE PROGRESS...
|
Even though I knew exactly what I wanted to
work on today, the morning started out very slow. I was
attempting to do some work in the bedroom while my daughter
watched some cartoons, but that didn't work, as she was more
impressed with sitting next to me and pressing every single
button on the laptop. Then, she laid on me, I decided to "rest
my eyes", and a couple of hours later, I woke up, feeling like
shit. I ran off to the gym, got a smoothie
afterwards, some tennis balls at Kmart after that, and made my
way home. It would still be a few hours until I got into my
groove. But damn, once I did, I was very happy with the
results! Today's plan was pretty simple. Take
the existing backend structure I implemented for turn orders,
and make a GUI representation of it. At first, a lot of the
time was taken up by me trying to implement the math involved
to position each unit in the proper place, and then I decided
to take a step back, and see what Unity had to offer out of
the box. As it turns out, there was a lot. I
quickly stumbled across the GUI Auto Layout
components of the new UI system, and was good to
go from there. Now, all I have to do is add the unit to the
panel that has the auto layout on it, and they're
automatically added to the right spot. If they're removed, the
next one moves up, and if they're added again, they'll be at
he back of the line. And of course, I need to make sure to
call back to the data class to make sure all the non-GUI stuff
is updated as well. Pretty straightforward stuff. Here's some
sample code:
public void AddUnit(Player unit) {
Image unitImage = Instantiate (imagePrefab);
unitImage.sprite = unit.portrait;
unitImage.transform.SetParent (_panel.transform, false);
_images.Add (unit, unitImage);
_turnOrder.AddCombatant (unit);
}
public void RemoveUnit(Player unit) {
Image unitImage = _images [unit];
unitImage.transform.SetParent (null);
Destroy (_images [unit]);
_images.Remove (unit);
_turnOrder.RemoveCombatant (unit);
}
Next up is for me is to go back to the data
side of things, and actually implement the priority queue,
based off of the speed of the unit. Also, I'll need to add
more units to the map itself so that turn order GUI can fill
up a bit, just to get a better idea of how it'll function.
With regards to adding more units, I think I'll be needed a
larger map soon, and with that, I'll need map scrolling :)
Ah, the honeymoon phase of things continues!
Till tomorrow...
11/18/16 -Friday: NEXT UP... UNIT
TURN ORDER...
|
I've been a little busy with work
lately, getting ready for a pretty big release in the coming
weeks. It sucks, because it's taken so much of my time that I
haven't been able to do as much game development as I would
like. But, such is life...
So, after I finished working on the
pathfinding prototype a few days ago, I realized that I needed
the ability to switch back and forth between allies. I spent
so much time trying to get the pathfinding working that I
didn't do too much thinking about what comes next. It was
pretty clear to me that I would need some "Turn Order" system,
which would essentially be comprised of a priority queue and
some value that the queue could be prioritized off of. For
now, just due to lack of a character stat system in general,
that value will be based off of a characters SPEED
attribute.
I mean, it's exactly as you would
expect it. Whoever has the highest speed will be at the front
of the queue. If someone has 2x the speed on someone else
(whether naturally, or through a spell or something), then
they'll have the chance to move 2x before the other person
can. The concept is pretty straightforward, it's just going
about and implementing it that will be the work.
As of now, I just have a plain old List
object, where I'm adding the existing party members to.
Whoever's turn it is, only they can be selected to move. Once
their turn is over, they'll be removed from the list, then
added at the back of it, and it will be the next person's
turn. Rinse, repeat. Next up will be some GUI work so you can
actually see the turn order on the screen, which will allow
you to better plan your next move.
I don't plan on spending
that much time on tihis little prototype, but I
hope to get a good deal done over the weekend.
Then, I can move on to yet another
prototype. Heh, you never really know how many systems are in
a turn based strategy RPG until you start making one :)
Till tomorrow...
11/15/16 -Tuesday: IMPLEMENTING
DIJKSTRA'S ALGORITHM...
|
In my last entry, I ended with saying
that I was going to watch another quill18
tutorial on YouTube, and as expected, I came away with
lots of new information, as well as an algorithm for
pathfinding, which you can see in today's GIF.
Last week, I had some rudimentry
movement in place, as a placeholder. Now, the
character/unit/ally/whatever is now actually following a set
path of tiles calculated using
Djikstra's Algorithm. I won't go into all
the technical details (if you care, follow the link), but I
think this illistration below does a good job of showing
exactly what is going on:
The starting point is the south west
point, the destination is the north east point. From the
starting point, or node, if you will, it continues to branch
out towards all surrounding nodes, and when it finds the
destination, it will then calculate the shortest path to said
node.
On the wikipage, there is some
pseudocode, which quill18 used to
create his method in his tutorial. I happily took advantage of
the work he did for everyone, and integrated it into my
Pathfinder class pretty easily. Within a
few hours, I was generating paths of nodes (which was easy
enough to translate to my TileData class, since it's more or
less the same thing... in fact, I should combine the classes,
but I'm rambling now...) to make use of whenever I selected
where the character should move. Taking those generated nodes,
I simply iterated over them, node by node, and had the
character transition from tile to tile. Pretty simple stuff.
Oh, and those red tiles you see pop up
at the end? That's just some other prototyping work I did to
indicate where the character can attack once they've finished
their move. I'll get back to that at some point.
Now, some people might be screaming,
"Why are you using that algorithm? Why not A*?!!!".
Well, it's mostly because quill18
decided to not use A *, and because
I actually had restraint for once, and decided to simply get
something working. Without a doubt, A *
is the better solution. And when the time comes, I'll
implement it as well.
Finally, just wanted to end on where my
head is at right now. In short, I'm in a good place. My
Destiny days seem to be behind me, and I'm
finding more and more that I just want to come home, eat
dinner, hang out with the family, and once they're off to bed,
come down to the man cave to work on the game. Plus there's
the time I have on the train.
There's also a co-worker of mine who is
also working on a game using Unity.
We have our little "Motivation Monday's",
which sort of gives me a reason to knock out a lot of work
over the weekend so I don't come up empty handed while we show
off what we've done. Speaking of the weekend, last weekend was
certainly my most productive thus far. It felt like 2006! I
think I put in 6-7 hours total on Saturday, another 2-3 on
Sunday.
I'm also experienced enough to know
(and if you have read my journal, or continue to read this,
you'll either know how often I say, or will
notice how often I'll say it in the future) that this is the
normal peaks and valleys of the emotional state of a game
developer. Things are going great right now. I'm energized.
I'm focused. I'm hungry. Maybe next week, I won't be any of
those things. That's why when I feel like this, I just get it
in. No bullshit, no distractions, just good old fashion work.
Till tomorrow...
11/9/16 -Wednesday: BEGINNINGS OF
PATHFINDING LOGIC...
|
Well damn, look at that! I'm back, and
it didn't take a few months. Maybe I can keep things going
this time :)
So, keeping with my rough bullet list
of things I wanted to work on, I started the initial work on
pathfinding for the characters/units in the game. Actually,
before I could even do that, I had to take the spaghetti code
I currently had, and try to break it up into logical pieces,
so I could then implement a basic state machine to control
everything going on. As of now, I have the following states
defined:
public enum GameState {
PLAYER_TURN,
PLAYER_MOVE_SELECTION,
PLAYER_MOVE,
PLAYER_SHOW_ATTACK_INDICATORS,
PLAYER_ATTACK_SELECTION,
COMBAT_MENU,
}
This has changed many times in the past
week, and I'm sure it will continue to change as time goes on.
What might make sense as a single state ends up making more
sense as two. Or, sometimes I fold up two into a single one.
It's all over the place right now, and that's okay, since I'm
learning as I go.
Once I had this set up, before I
started looking at actual pathfinding logic, I just wanted to
test out moving the character from one tile to the other. I
already had a pretty decent idea of what I wanted to do
(having previously done similiar work while doing contract
work on
The Shadow Sun).
I basically needed to do 2 things:
-
Create a function that would slowly
move from one tile to another, over x seconds
-
Make said function a coroutine that
is called from the state machines Update()
method.
Using my previous experience, I was
able to cook something up pretty quickly. But, as you can see
from today's GIF, the character isn't following a path towards
the final tile. It's just going right to it.
And that's exactly what I'll be working
on next. Integrating true pathfinding. Lucky for me,
quill18 has a
youtube series on it that I'm going to watch
tonight. I had previously watched his series on tilemap
creation, so I'm expecting some good stuff.
Till tomorrow...
|
11/1/16 -Tuesday: BACK TO IT...
|
STATE OF THE UNION
What's up, people? No, I'm not going
away for another 2 years. Life has happened over the past
month, but now, I'm back to it!
So yeah, long gone are the days where
I can put in 8 hours a day of work, 6-7 days a week. I mean
hell, I was already doing that while
holding down a full time software engineering job. I
was 24-26 during those times. I'm now 36. I'm married. I
have a house. I have an almost 2 year old daughter. Yeah,
not happening.
However, to be fair, I can't blame it
all on that. There is this other thing, called
Destiny: Rise of Iron. That launched 9/20, and
being the hardcore player that I am, I had to experience all
parts of it, on my Hunter, Warlock, and Titan. Story
missions, new strike, Iron Banner, and most importantly, the
new Wrath of the Machine raid on
both normal and heroic modes. I'm sorry! I just had to do
it, and get it out of my system. New content shouldn't be
dropping until their annual spring update, so I'm good now,
I promise!
But enough about non-Rose of Eternity
stuff, because you're not here for that. Here are the
highlights of things I've been working towards:
Character Sheet Display
On Highlight
After I finished up prototyping
displaying terrain details when moving the tile selector
around, I figured I would take a stab about character
sheets. You know, the standard issue GUI that shows a
portrait, name, some stats such as hit points, and other
things.
First thing I needed was a
Character class that could hold all
that data. That was easy enough to implement. This class can
technically be the parent class for all units you willl see
on the battlefield, ally and enemy alike.
Next, I had to get some sort of on
screen representation of them. For prototyping purposes, I
decided to just use a 3D capsule object, which already had
some default colliders on them. Obviously, it will be
replaced by an actual sprite, but that stuff doesn't really
matter at the moment.
Once I had the capsule prefabs
defined, all I had to do was drag and drop the
Character class script on them, and they were
good to go. From there, via the inspector for each of the 2
characters in the prototype, I entered in the appropriate
values, including some old portraits I dug up from
The Coming. One, made by long time
collaborator, Oli Ferrando, the
other, most likely included in the original set of assets
for Neverwinter Nights 1.
From there, I had to catch events
where the tile selector hovers over the capsule, and when it
does, pop up the Unity GUI object, which is already set up
to read the appropriate data from the Character
class.
If you look at the GIF for this post,
you'll get an idea of 2 cast members that will be in the
game. One is wholly new, the other, well, if you played the
old games and paid attention, you might
know who he is.
Movement Tile
Highlighting
I've been having one hell of a hard
time figuring out how to refer to it. But you all know it
well. It's the tiles that are highlighted indicating where
the selected party member can move. I did a shit ton of
research on how best to implement this, and while I didn't
do it the most efficient way, I was surprised as all hell
that it just sort of... worked.
Forgetting for one moment about how I
actually calculate which tiles the party member can move to,
there's the entire part of how to
display it. Remember, my tile map is a single mesh, which
the appropriate number of vertices and triangles for the
size of the map I need. Even though you see what look to be
individual blocks with their own sprite on them, it's really
just one large texture that has had the sprites dynamically
added to it in the right spots.
So if I was doing this right, I would
figure out a way to re-draw the texture, but this time,
wherever the party member can move, I would need to
darken/highlight that sprite before applying it to the
larger texture.
If that seems like a lot of work,
well, it is, which is why I implemented a poor man's
version.
I simply created a square 3d object
that had a height of like 0.5, set the material color to
blue (50% or so of transparency), and decided that wherever
I needed to show where the party member could go, I would
simply spawn one of those squares at that spot. And when
they weren't needed anymore, just destroy them.
Hell, even in this terrible solution,
it would have been smart to at least use some caching or
something, so that I wasn't instantiating a new one every
single time.
And therein lies the problem. I'm
working on a prototype. It doesn't have to be perfect. I
don't have to spend all the time scaling things. I just need
to get things working, so I can determine if this is the
proper path forward (engine wise). I know all of this, and
have probably blogged about it before. But I always get
caught up in doing the right thing, and it brings things to
a screeching halt because of it.
At the end of the day, even if my
laziness, the performance is quite good, and never dips
below 700 FPS while playing it via the editor.
As for the implementation of figuring
out which "tiles to highlight", I poked around for a bit,
and found stuff like the oft mentioned "Flood Fill"
algorithm. Again, not really wanting to spend too much time
on anything, I wrote my own method, that ended up working
out quite well. Even better, it literally worked the first
time I tried it. As you can expect, I was happy as hell!
What's Next?
As you can see in the last few frames
of the GIF, I've selected the party member (well, you can't
actually see that, but trust me, I'm doing it), and the
combat menu has popped up. So yeah, that's what's next. More
specifically:
Most important is the state machine,
as that will control the entire flow of the game, all the
systems, and whatever else I end up creating. It's the
heart, body, and soul of this game. This, I need
to get right (within reason, I can't go to
crazy and spend a month doing it!)
Till tomorrow...
|
