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

9/11/16 -Sunday: LOOK AT THAT... IT WORKED...

As you can see from the above GIF, I definitely was able to get something done these past few days. And luckly for me, they were more or less the things I outlined in my last post as things I wanted to work on next.

TILE DATA CLASS

This class encapsulates all known data about a specific tile. More specifically, it currently contains:

• Terrain Name
• Is Walkable
• Defense Modifier
• Dodge Modiifier
• Accuracy Modifier
• Movement Modifier

Mountains aren't walkable, the desert has a movement modifier of -2, grass doesn't alter any of these attributes, etc. You guys get the idea, not doing anything revolutionary here.

So now, when I'm loading my TileMapData class with the 2D array of tiles, instead of just passing a range of 0-3 for each tile (which used to just represent which graphic to show), it's now replaced with an instance of TileData.

In fact, here's a rudimentary understanding of how everything works together thus far. Maybe I'll get fancy and start using real flow charts and whatnot:

• There is a data file that contains all the tilemap information for a particular area of the game. For simplicities sake, we'll call it VeronaForest_1.json.
• TileMapDataLoader loads VeronaForest_1.json, and begins to parse each tile attribute.
• Each parsed out tile attribute will become an instance of TileData.
• Each instance of TileData is stored in an internal 2D array, which is contained within a TileMapData class.

It should be noted that all of these clases are Engine agnostic. They're simple C# classes that don't know anything about how to render, draw, etc. They're just filled with data, data that can be passed to any system. So while this is being done in Unity, it could easily be ported to something else.

But I am using Unity, so, to continue to the pipeline:

• TileMap (Unity class) has a referfence to TileMapData, and can iterate over it in order to draw the actual tile map. Now, being a Unity class, it does have to know about TileMapData. However, the way things are split up, if I need to change how everything is drawn, say, I'm moving from top down to isometric, the only class that needs to know about that is TileMap. TileMapData can stay as it is.

TILE SELECTOR ICON

This was pretty easy, as it was more or less implemented during quill18's tutorial. Unity has a fairly easy to use event system with regards to mouse movement, and it was pretty easy to override the Update() function, which runs every frame, and do the following:

1. Check the position of the mouse.

2. See which tile coordinate it is in.

3. Move the tile selector icon, which is really just a flattened 3D cube, to said tile.

4. Make the movements snap into place by moving a distance equal to the width/height of the tile.

So yeah, nothing special here.

UNITY UI

Ah, Unity UI. Released maybe 2 years ago, I think? It's supposed to make rendering all sorts of UI easier, and give better performance. Whereas with the old system, it was pretty much all scripting based, this time around, you gave actual gameobjects you can create within the editor. Once you create a UI you are happy with, you can create a prefab of it, and then use it anywhere in your game.

The biggest thing I dealt with was how to utilize them. Sometimes, I don't think people appreciate how much work goes into actually designing a system that is robust, less prone to errors, and highly performant.

In my case, I did a lot of research into the pros and cons of dynamically loading the UI prefabs when I need them (caching them, of course, once loaded), or just including a reference to each one I need wherever it's needed.

After a lot of soul searching, I am going to go with the latter solution, and see how that pans out. I'm think some sort of UI Manager/Controller is in my future. Main issues with loading assets at runtime is that I'm already going to be doing a lot of that as it is. So the less strain I put on the system, the better.

In terms of getting the values to change on the tile terrain details panel, that was pretty easy. As I already have a rerference to that UI gameobject, in the code where I move the tile selector icon around, I get a reference to the TileData object that represents the tile that is seletced. Then, I just grab the important data, set some text values, and I'm good to go.

THOUGHTS ON PROTOTYPING IN GENERAL

So in general, things are going quite well. I technically had most of these things done days ago, I just ended up getting pretty busy with work, and not having time to write this blog. So if I take that into account, I'm really doing good.

Also, I'm a firm believer that during this prototyping phase, the "look" of things does not matter. I know that most blogs want to show things off looking as good as possible. However, with this blog, I've always wanted it to be a catalog of true history. No revisionists history here. I absolutely love going back to old blog entries, to see how shitty my games have looked, and then look at the final product. I also think it's good to show people the real side of game development, as much as I can. And that way of blogging isn't going to change.

On the other hand, even though I'm prototyping, from a coding perspective, I'm definitely striving to make all the right decisions up front. Coding standards, best practices, that sort of thing. Sure, I've been a software engineer for 12 years, but when people say, "Oh, picking up another language is just syntax", it goes deeper than that. You must really learn the guts of the language if you want to write some as complex as a game.

Performance is the first thing on my mind in every decision I make. So even though I'm prototyping, I'm still trying to keep things respectable :)

Till tomorrow...

Ever since I started working on Rose of Eternity games, while I have definitely squeezed as much as I possibly could out of the Aurora & Eclipse engines, there were always limitations. There were so many times were I was like, "Shit, if only the engine exposed this functionality" or "Man, I wish I could change the look of this character sheet UI".

On the other side of the coin, I was given so much out the gate. Conversation editors, level/area creation tools, scripting languages... And that's not even counting all the stuff under the hood. Rendering, physics, and who knows how many other systems. I never had to think about it. I was able to just sit back and do what I do. Implement combat systems, create semi-branching story lines, a little level design, and tie it all up with a nice, shiny bow.

Now, I have to start from the bottom. But where? That was one of the biggest lingering questions I had in my mind over the past few months.

Well, being a turned based RPG, I figured I would start out with implementing the map system that the combat will take place on. After a lot of googling around, I realized that what I wanted to implement was a Tilemap system.

Now, one thing I knew from the jump was that I didn't want to just integrate some existing asset package that had a tilemap system in it. I knew going in that I needed to implement it myself. I'm going to always need to have 100% control over it. One thing I've learned over the past 12 years, as both a game developer, and a software engineer, is that sometimes putting your future in the hands of other people doesn't always work out so well.

So with that said, I went about looking for tutorials. And boy, did I hit the jackpot. There is this guy named quill18 who has one hell of a YouTube channel where he does these in depth tutorials on coding solutions for Unity (there may be non-Unity stuff there too). The one that got me started was his Unity 3d: TileMaps series. All I can say about it is it's a master class in how to do a video tutorial.

 I've never been a fan of them, as I'd normally rather written ones. What separates him from the rest is his tone, his delivery, his knowledge, and the way he explains things. I mean, look, some people got it, and some people don't. He does. I could sit there and watch a tutorial about some subject I don't care about, and be totally fine. His voice simply captivates you, and you get sucked in. And at the end, you will have learned a lot. In fact, I learned more than just how to implement a Tilemap, as he was always throwing in little tidbits here and there about the Unity engine in general. It was a great experience, something I'll always remember when I look back at the early days of the development of this game.

So, with this newly gained knowledge, and set about my task. It went... pretty smoothly. There were really only 2 ways to create the tilemap. One was with using Unity game objects, one per tile, which is pretty easy to implement, but doesn't scale well once you're getting into larger maps. The other way, which quill18 did most of this tutorial on, was implementing it uisng a Unity mesh. Instead of all of these game objects with a texture drawn on each one, I just use a single mesh that has a single texture on it, and draw everything on it.

The actual math and components involved in creating a mesh were all new to me, including learning about quads, triangles (2 per quad), vetices, uv, normals, etc. It was at this time that I knew I was in the big leagues.

The first thing I did was take a 4 sprite sprite atlas, and randomly populate the map with them. That's essentially that garbage image you see at the top. The sprite sheet (which was taken from the quill18 demo) includes water, grass, mountains, and desert. See below:

So, I created a 50x25 Tilemap, and then randomly fed it these sprites, which produced the following:

I also had to do some work to make sure that every time a Tilemap was generated, the camera would calculate the center of it, and move there. I have some work to do with regards to the math and how some of the tiles are chopped off on the edges, but in terms of generating my first mesh based Tilemap, I was pretty happy. But I needed to do more... I started thinking about how I wanted to actually store this data.

As stated above, I want to create my own Tilemap system, for the reasons I mentioned above, and for other reasons I cannot get into at the moment. But another reason I want to create my own system is because of the way I want to serialize/deserialize them. Or, save/load, if you will.

For every map in this game, I want to dynamically load it from a file. Let's say the format is, oh, I don't know... JSON. There will be a directory of JSON files that contain all the data needed to generate the map. The positiion of the tile, the type of tile, the sprite associated to it, and all sorts of other things I may add down the road. Is the tile walkable? Is it destructible? Is there some benefit from standing on this tile, versus another? Maybe you walk slower in the desert. Maybe your ranged accuracy goes down in the forest. Just spit balling ideas here. And I realize as I'm typing this that I sound very much like Sean Murray and his now infamous interviews about No Man's Sky. Because I'm neither confirming nor denying these elements will be in the game, I'm just throwing things out there. So yeah, please don't hold me to anything I say here, because anything can (and will) change at any time. Such is game development.

Anyway, knowing that I needed to load this data, I knew I needed a new class, something I ended up calling TileMapDataLoader. Now, I didn't want to go too crazy, so I actually created a CSV file, which each value ranging from 0-3, corresponding to the sprite atlas. Then, by hand, I set all the numbers in a fashion to at least make something resembling a less shittier, random tilemap. The CSV file would end up looking like this:

3	3	3	3	3	3	3	3	3	3	3	3	3	3	3	3	3	3	3	3
3	3	3	3	3	3	3	3	1	1	1	1	1	1	1	1	1	1	1	1
3	3	3	3	3	3	3	1	1	1	1	1	1	1	1	1	1	1	0	0
3	3	3	3	3	3	3	1	1	1	1	1	1	1	1	1	1	0	0	0
3	3	3	3	3	0	0	0	0	0	0	0	0	0	0	0	0	0	0	2
3	3	3	3	0	0	0	0	0	0	0	0	0	0	0	0	0	0	2	2
3	3	3	0	0	0	1	1	1	1	1	1	1	1	1	1	1	2	2	2
0	0	0	0	0	1	1	1	1	1	1	1	1	1	1	1	2	2	2	2
0	0	0	0	0	1	1	1	1	1	1	1	1	1	2	2	2	2	2	2
0	0	0	0	0	3	3	3	3	3	3	3	3	2	2	2	2	2	2	2

And the Tilemap that was produced looked like this:

So, going from south to north, we have some mountains, some grassy plains in front of them, a river, followed by more grassy plains, smaller mountain range, and then the beginning of the sahara desert (or whatever).

Those looking closely at the CSV and the Tilemap will know that everything is flipped upside down. It's because in Unity, the 0,0 coordinate starts at the bottom left, but the way I'm reading in the CSV file, the 0,0 coordinate is actually at the top left. But besides that, everything looked good.

So all in all, it's been a very productive few days. I've:

• Learned a shit ton about Tilemaps and meshes

• Implemetned said mesh based Tilemap

• Created a simple CSV data loader so I could at least make the maps look like something other than static on an old ass TV

Next on the agenda? I don't know, actually... It's all going to depend on how much time I have. I'd like to expand on my TileData class (well, I haven't created it, but that is what it'll probably be called), and start adding some attributes to it, like the aforementioned "is this walkable", or "does this slow you down".

I would also like to get a tile selection icon in there, something I can scroll around in order to see the various tile statuses. In fact, shit, I want to get scrolling in general going. You know, panning around the map and whatnot.

Yeah, that sounds like a plan.

Heh, I was chatting with an old buddy of mine who was helped with these projects since like 2006, and I told him that I'm in the honeymoon stage of development right now. Everything is fun. Bouncing around from one cool idea to implement to another is great. But I know all too well how it ends. So, I'm going to enjoy this while it lasts:)

Till tomorrow...

STATE OF THE UNION

Well, folks, it's been a long time coming. It's finally time to officially talk about what's been going on in this crazy mind of mine over the last 2+ years.

During the last year or so of the long death march that was the development of Family & Country, I started beginning to think about what was next. Even though I was still working on a game, the bulk of the work was already finished. It was more about dozens and dozens (and dozens!) of play tests, bug reporting, bug fixing, and the like. There was lots of work surrounding the marketing campaign. I was working like a mad man trying to get in contact with some generous voice actors, to fill the last remaining spots in the game. I know that seems like a lot (it is!), but I wasn't really doing any hard code development. Since I was in a holding pattern for a lot of the time, I had lots of time to think...

...And when I have lots of time to think, ideas start to take shape.

The first thing I had to tackle was the idea that I was done spending time doing the following 2 things:

• Working on projects for other people

• Creating Rose of Eternity games based off of existing RPG engines (NWN Engine, Dragon Age Engine, etc.)

It was all good and fun doing this from 2004-2014. But I'm 36 years old now. I'm married. My daughter is almost 2 years old. We just bought a house last fall. I just don't have time to spend on the projects of others (i.e. Ossian Studios), or on games where the engine restricts what I can really do. I need to take everything I've learned over that decade, and make something wholly my own.

Enter, a new engine:

I was fortunate enough to get a little experience with this engine while working with Ossian Studios on The Shadow Sun. In all honesty, it was one of the reasons I took on the contract. I didn't care about the money, I cared about the experience that I would be able to leverage one day. Today is that day.

The next thing I had to address was how to realistically create my next game. Most people who really know me know that I've always had big dreams for this game franchise. Way back in 1999, I knew what type of game I wanted to make. Unfortunately, I'm not there yet, and it would be foolish for me to think I can attempt to create a AAA title, in the vein of Dragon Age: Inquisition and The Witcher 3. It's just not possible.

I mean, can I really make this with my current resources?

What about this?

Um, yeah, I think you know where I'm going with this. I have to do what's within my means, and realistically, making a tactical turn based RPG makes the most sense, and for the following reasons:

• From an engineering standpoint, while still complex, it's still something that I believe I can tackle well enough. This doesn't include art, animations, music, etc., but those are things I can worry about later. For now, it's all about prototyping all the various systems of the game.

• Rose of Eternity has always been a game with multiple layers of combat systems, like Unison Abilities, Last Resorts, Passive Abilities, Bonds of Battle, etc. Said systems will be a natural fit for this type of game. And since I already have a large list of these implemented over 3 games, I'm already ahead of the game.

• There is a market for these types of games. Arcadian Atlas raised 95K+ in funds from kickstarter over the summer, for instance. And at the same time, the market is not flooded with these types of games.

• The story I intend on telling still fits within the overarching narrative already seen in the first 3 games. In fact, it expands the hell out of it, game world/lore wise.

So that's it, folks. The next game I intend on making will be a tactical turn based RPG and I'm using Unity to do it. These last 2 years have been fun, but now it's time to get back to doing what I do.

Till tomorrow...