next »

[Kevin G]

THE GAME:
 
Project XSYS is an untitled indie game that features world map HEX crawling, turn based combat, and multi-character party RPG adventuring.

Features thus far:

Hex Crawling

World map hex crawling is a unique feature. It's up to the player to ensure his/her party is well prepared and provisioned for each journey. Like many 4X games,time controls allow the player to speed up, slow down, and pause the passage of time. As time passes, various events will occur such as combat encounters, interaction scenarios, inter-party personality conflicts, discoveries, etc.    

The screenshot below is the most current view of the hex map. It is auto-generated by stitching smaller hand crafted Terrains together.  It has yet to be decided if the game will use procedural hex maps or not.
 





Tactical Turn Based Combat
The combat system was built to satisfy the itch of tactical turn based enthusiasts.  In addition, I've worked hard to ensure that the combat grid is truly 3D. This means that characters can climb, fly, crawl, and jump over and under obstacles.

The combat system is based on the concept that your character can try to do anything.  For example, if you want to fight with two weapons, trip, guard, parry, or disarm you don't need a special skill to try it. There are no talent trees just proficiency levels.



Character Party
The character creation system is extensive and is a multi-step process. Steps include selecting Class, Race, Ability Scores, Interaction Skills, Combat Skills, Exploration Skills, Spells, Appearance, Personality, Backgrounds, etc.  At the moment, the system allows you to create up to six characters.



Thus far, I've spent many long nights coding and refractoring the games numerous subsystems (true 3d grid pathfinding, sqlite database, event message system, animations, personality system, combat mechanics, inventory, character sheets, items, vendors, character creation, terrain based hex map, encounter system, survival mechanics, campaign events, etc).  The game has truly become a labor of love and I'm quite happy with the code thus far, but of course it's not perfect... yet.


Anyway,  I hope you enjoy watching my game take shape.  I really need all the feedback I can get as I have much to learn.  

[Sokuaisushi]

I love the look of that hex tile. My only suggestion would be to perhaps blend some of the tiles a little more. Though you likely already know that as it looks like some tiles blend but not all of them yet.

For the genre of game you plan on making I believe a procedural hex world would fit best, and it would require less memory than saving many large maps. Then you could allow the player to input their own seeds so they can share their world with their friends. Overall this is an incredible start! I can't wait to watch this game progress!

[Kevin G]

I love the look of that hex tile. My only suggestion would be to perhaps blend some of the tiles a little more. Though you likely already know that as it looks like some tiles blend but not all of them yet.

For the genre of game you plan on making I believe a procedural hex world would fit best, and it would require less memory than saving many large maps. Then you could allow the player to input their own seeds so they can share their world with their friends. Overall this is an incredible start! I can't wait to watch this game progress!

Thanks for your feedback.

You are very observant  

The hex grid is pure programmer art at this point and is shown with blending, fog of war, and water turned off.  Currently, after it stitches the terrain tiles together it applies a smoothing algorithm to the entire map, but I didn't like the look of it so I turned it off.  I'm now working on a smoothing mask that only applies smoothing to the edges of each hex tile.  In addition, I've created a hand painted greyscale mask that blends the textures together. 

This topic raises an interesting debate.  Apparently, there are Hex game enthusiasts who loath the idea of blended hex tiles.  In their view a hex tile should look like an actual hex tile.  The big question from them is "why make a hex tile game if it doesn't look like a hex grid?"

It's funny because my original design for the world map was a single hand crafted terrain world map with a simple hex grid overlay. Of course, I've since moved beyond that for the sake of replay-ability via procedural generation.  My only concern is how a procedural world might compromise a campaign story, if I chose to include one.   IMO, this game is more about sandbox style play than it is about epic fantasy stories and campaign worlds.

Sharing campaign worlds is a great idea. Of course, multi-player is out of scope.   

[Kevin G]

It seems like ages ago (yet less than a year) that the game looked like this.  A simple windows forms application.   Now all this purified game logic sits inside a class library (namespace XSYS).   



IMO, it's best to start on the core or your game first without the noise / confusion of an engine.  If you can't make your game logic work outside your game engine it probably won't work inside it either.

[Sokuaisushi]

Thanks for your feedback.

You are very observant  

The hex grid is pure programmer art at this point and is shown with blending, fog of war, and water turned off.  Currently, after it stitches the terrain tiles together it applies a smoothing algorithm to the entire map, but I didn't like the look of it so I turned it off.  I'm now working on a smoothing mask that only applies smoothing to the edges of each hex tile.  In addition, I've created a hand painted greyscale mask that blends the textures together. 

This topic raises an interesting debate.  Apparently, there are Hex game enthusiasts who loath the idea of blended hex tiles.  In their view a hex tile should look like an actual hex tile.  The big question from them is "why make a hex tile game if it doesn't look like a hex grid?"

It's funny because my original design for the world map was a single hand crafted terrain world map with a simple hex grid overlay. Of course, I've since moved beyond that for the sake of replay-ability via procedural generation.  My only concern is how a procedural world might compromise a campaign story, if I chose to include one.   IMO, this game is more about sandbox style play than it is about epic fantasy stories and campaign worlds.

Sharing campaign worlds is a great idea. Of course, multi-player is out of scope.

An edge smoothing mask rather than smoothing the entire tiles together would make it look really good in my opinion! Though I agree that hex's should still be discernable, maybe with a transparent black hex outlining the edges of the tiles or something to make each tile stand out still.

And if there are a lot of people who don't like the edge smoothing, then you could always make it a toggle option in the graphics settings for your game.

As for procedural genration getting in the way of a campaign, that is entirely plausible. My suggestion to avoid that would be to have hand crafted areas or zones, and have the world procedurally generate the areas in between. You could even make the entire starting zone hand crafted so that you can control the flow of gameplay while the player is still learning how to play. But for a sandbox style game I definitely feel that adding procedural world's increases the replayability of the game.

As for multiplayer being excluded, that's nearly a given considering the scope and nature of the game plus multiplayer is really hard to pull off well anyways and in my opinion wouldn't really add much to the value or gameplay of thus style of game (though multiplayer is always a good selling point, and could garner more sales than without multiplayer).

[Kevin G]

Over the last two weeks I've been working hard on the procedural hex map.  So far, not bad for a programmer.  

[Kevin G]

So far, I've greatly improved the hex map generator, added trees, radial texture blending, and a time of day manager.  
 






After trying number of different procedural hex map generation methods I've settled on a rather unorthodox approach.   Commonly used techniques using Perlin noise failed to create convincing landmass shapes without becoming over complicated.  After a bit of agonizing, I realized that I needed more control over the map generation and noise generators based on landmass height didn't offer me that.  
 
With a bit of research, I decided that I would try to replicate landmasses using randomly generated polygons. I then wrote a function to do just that.  
 

Code:

GenerateRandomPolygon(randX, randY, radius, irregularity, spikeyness, verts);

The function allows you to specify polygon irregularity, radius, number of corners, and spikiness.   This function turned out to be the exact solution I was looking for, as it provides granular control over the shape of the landmass.  
 
 
 
The above function was then used to generate a random number of tectonic plates on the hex tile grid.  Then, hills are created at the locations (hexes) where tectonic plates overlap.   Mountain tiles are subsequently created from hill tiles that are surrounded by hills.   As you can see, this approach produces satisfying mountain ranges.
 
At this point each tile is assigned a wind direction that is determined by its latitude.   Then, default precipitation and temperature levels are set.   Mountains are cooler and water tiles are warmer.  Tiles in rain shadows are determined by examining nearby mountain tiles and their wind directions.    As you can see from the screens above,  this approach creates deserts on one side of the mountain and forests on the other.    
The maps are rather small at this point, but I do plan on making them much larger by adding biome regions (savana, tundra, taiga etc.).  Creating biome regions shouldn't be too hard now, considering I have all the data I need (temperature, precipitation, wind, etc).
 
 
There are still many more features I want to add like, rivers, roads, settlements, beaches, coast line water foam, and the list goes on.   I figure there is at least another month of solid coding to go.  Working on the hex map wouldn't be so difficult if Unity terrains were much more intuitive and fully documented.   The coordinate systems used by a terrain's trees, heightmaps, alphamaps, are all different and that makes it an obtuse beast to work with.  

[Kevin G]

Added an optional grid that is projected onto the terrain from above.  I think I might make the lines a bit thicker. 

[Kevin G]

I've decided to take a break from the hex map code and advance progress on the combat system. 
Poor Adam, I'll bet he didn't know what he signed up for. 

[Kevin G]

This week I worked on the SQLite database.  The game now loads and saves itself using the database.  In addition, I've imported well over 100 different weapon types.  

At some point I might split the database up. I'll create one DB for instances/saved games, and the other for blueprints and modules. That way users can backup their saved games by copying the user.db

[Kevin G]

Against the Buggy Mutants - not even Guarding will save you

The new Guard feature is near complete. 
Poor Adam, not even his new guard attack could save him.  And the Mutants first attack bugged out.   LOL



 
Guarding (Gold Box Style++)
 
The game will now allow you to spend action points to guard with one or more weapons attacks.   The number of readied attacks is only limited by your action point total.  When an enemy enters your weapon reach, you attack first (gold box game style)  It's setup right now so that all your guarding attacks fire off at the triggering enemy.    I might change that by giving the player an option or only allow one attack per enemy.
 
How does it work?
 
Coding this was really f-ing complicated too, especially when several units are guarding the same square.   Without the internal Event Messaging System I created, the task would be near impossible.   I had to make a TileGuarder class that listened for a number of different events.    The basic sequence of events is as follows.

1. The TileGuarder listens for unit location changed events 
2. If a guard is triggered the moving unit is told to end its movement and pause.
3. The TileGuarder issues a guard attack request to each unit guarding the location
4. The guarding unit issues an attack normally and the attack is handled like any other.
5. The guarding unit issues an guard attack completed message
6. When the TileGuarder receives a GuardAttackCompleted message the attacker is told to stop guarding
7. When all guarding units have completed their guard attacks the target is told to unpause.
 
And this doesn't deal with death correctly.    An overwatch ability (guarding with ranged weapons) is next on my hit list.  Hopefully both systems will play nicely together. 


Don't mind the gif artifacts - I'm not sure why GifCam does that)

[Zireael]

You mentioned that the battle grid is 3d, that we can fly/walk over walls. But all the gifs show fairly traditional combat on a plane...

[Kevin G]

Yes, I haven't shown that yet.  The animations for climbing are still rather ugly, but flying and jumping might be good enough to demo. Perhaps I'll make a gif of that next

[Kevin G]

Here is a demo of the flying feature.   Using the mouse wheel allows you to raise and lower the movement selector.   



Don't mind the animations or the UI, as I haven't even focused on that yet.   

[PsycheMac]

Maybe you were already going to do this but it might be a good idea to show what ground tile the cursor is over when it is suspended in the air. Might help with understanding where it is in space better.

[Kevin G]

That's a great idea.  Highlighting the tile below is easy.  I could also make a translucent pillar that displays height information.   I'll need to pick something that looks good when the movement selector is above another creature. 
 Thanks.

[Zireael]

KevinG, that flying demo is already looking really neat, and I second the transparent pillar idea.

[Kevin G]

Thanks Zireael.

Now that I've thought about this problem a little more, it's not just the movement selector that needs a height/position indicator, the selected unit and the targeted unit require it as well.

With that said, I'll certainly make these optional settings for those who don't like them.

[Kevin G]

all done. I just need to do the same for flying units when they are targeted and selected.  I might also segment the pillar into cubes, that way you can tell how high you are.

[Pixel Noise]

I think is looking very cool already - your "programmer art" is not bad at all! I think you are definitely on the right approach - nailing down logic, mechanics first, and then assets second. Every time I see a devlog purposefully start that way, it usually ends well.

Seems it's usually the programmers/coders who most often approach their design this way, which makes sense I guess. Anyway - keep at it, because I think you are building something very cool here!