After getting the debacle with my git repo fixed up, I decided to work on some shader stuff. I’ve never made a shader before, so I started with some great tutorials Makin’ Stuff Look Good in Unity, a great series of tutorials for Unity devs.
I started out with the tutorial on Winston’s barrier from Overwatch and this is what I had:
It looked pretty cool, but wasn’t much different than the tutorial, and also the hex pattern looks far more sci-fi than fantasy RPG. I made some modifications using temporary PNG assets that I reworked the RGB channels on and ended up with this:
Much better – arcane symbols work more nicely than the hexes. Of course, this will be developed over some time to get a better effect, then slightly modified for different elements (there are 12 of them in the game).
Anyone following this at all might be asking: “why the heck are you working on shaders and effects when the game systems aren’t done yet?” I think it’s a valid question. Most blogs and books on game development seem to point to it being better to get functionality in, then make things look good. There’s probably wisdom in that, and I’m sure it works for a lot of people – maybe most people. But I thrive in chaos. I also have a bit of the ADD. And being a (semi-)solo developer, I have to really work on all of the things, so… sometimes I jump around to not get bored or when I get stuck on something and want to revisit it later. There’s nothing wrong with this. Always find the work flow that works for you, rather than trying to fit yourself into the work flow you read or learned about.
So, I lost 1-2 weeks of development time because I hosed up my git repository. Anyone else ever do that? Anyone? *crickets*
Well, since the whole point of source control is to protect you from these things, clearly I did some very bad things. Turns out it was a series of bad things. First, I change my asset serialization to force text. That part was fine, except then I had a failed merge and merge conflict markers got dumped into the files – which can’t happen with binary files. At the same time, I was setting up LFS for binary files. I’m not sure what I did wrong there, but LFS half-worked. At some point files duplicated, went to LFS but then the pointers in the repo were overwritten by the original binary files.
At this point, I was hosed up good. My repo was well over it’s limit, I couldn’t push anything (not that I wanted to), and was having a hard time finding a commit I could roll back to that was good.
Now, I have a working copy of my project. But it doesn’t work for everybody, so something is still amiss.
I’ve been working on the core combat mechanics for the past week or two, and have finally got things feeling decent – at least to start with. I wanted to do something modular so that over time it would not only be easy to tweak, but also easy to add additional features. So, here’s a sample of what I have so far:
The base element here is the DamagePackage, which contains information about the raw damage amount (DamageArray – from each of the 12 possible elements of damage), the cause of the damage (DamageVehicle – e.g., weapon, creature, trap, environment, effect), any damage effects which would include damage over time (DoT) type effects, and any special effects from the attack (chance to be set ablaze, frozen, sleep, silence, etc.).
There is a slight error with the diagram above, as I’m typing this all out – the CharacterStats are brought in on the Talker and Listener levels.
At any rate, the DamagePackage moves to the DamageTalker, which takes in the attackers stats for any modifications, then sends the package along to the DamageListener on the attacked actor. The Listener works in reverse, unpacking the information from the package, applying resistances and such from the attacked actor’s stats, then applies that modified damage package to the actor itself.
The beauty of this system is it’s flexibility. The downside is that different components reside on different levels of the actors and their equipment. For instance, on the player, the stats and the listener are on the root, but the talker and all of it’s constituent parts live on each weapon (or spell). For a non-humanoid creature, almost everything lives on the root level. Except listeners – the listener must always reside on the same layer that the collider lives on. Well, it doesn’t have to, but it makes things worlds easier. So… this is something I’m trying to figure out. Though honestly, I could probably package this up for the Unity Asset store once I get it all cleanly situated. I’m happy with where it’s at now, but it has a LOT of work still ahead of it to be a nice, simple-to-use package.
Of course, the system needs to be set dirty whenever an actor’s stats change, or when weapons/armor are swapped out that might impact stats.
Even the most digitally-inclined sometimes have an easier time wrapping their head around ideas on paper instead of a screen. I’m currently working through some logic with my combat system in exactly this way.
Mapping out idea, and sometimes even just writing things down helps me really get a good idea of what I want or need to do – better than typing and seeing it on the screen. It’s not a bad way to get thoughts out of your brain.
Often, I’ll jot down a URL to a page that talks about something similar to what I’m trying to do. I currently have three books. This lined book is full of notes and charts and drawing and ideas.
I have a grid/quadrille book that has database-like charts and some organized info, and I have a dot-pad book that so far has only a few layout ideas for UI.
It may seen archaic to some, and I typically prefer digital information, but hand-written notes has really helped me break through some of my issues so far in this development cycle.
I assume that most people working on their first (or twentieth) game probably know about Stack Exchange, probably even use it now and then. If you don’t, I can’t recommend it highly enough. It’s my go-to place to help me figure out what I’m doing when I get stuck. GameDev.SE is a great place for game development specific stuff. StackOverflow is the place to go for code-specific questions that aren’t related to game design or development.
Yesterday I posted a question for a sanity check. This is the sort of thing that I have to think through several times before getting it right.
If you don’t want to click the link, the short situation is that I’m probably going to have DamageListeners on all creatures that can take information about an attack and process it for the actor. All damage-causing things (weapons, spells, traps, environment) will have a DamageTalker that processes the information and tailors it to the specifics before sending it to the receiving actor. In between, a DamagePackage will contain the specifics of the attack. I’ve debated whether this is overkill or not, but because of some custom damage, DoT, and effects that an attack can apply, I wanted to have a very customizable collection of information about the attack from both sides.
The other day I did a little post with some images showing the difference between the game’s early incarnation and where I’m at with it today. Here’s another small dose of that in the form of YouTube videos showing the torch lighting in the game.
The old setup:
The new setup:
I actually was able to reuse some code and particle effect info from the original torches. Even though the game view was from a top-down 2D camera, the torches themselves were 3D assets with particle effects, just viewed from the top. But yeah, this is a pretty big change, and I can’t complain at all about how it looks now as compared to before.
I posted these images on Facebook a couple of weeks ago, and they somehow never made it here. After struggling with a few things related to graphics and map/level generation, I feel like I finally broke through the wall that was holding me back. I started working on character creation, mobs, and am starting to work on some game mechanics finally after months of scrapping attempt after attempt.
I figured one of the core ideas behind Labyrintheer was, well… labyrinths: mazes, dungeons, et cetera. If I couldn’t get those done right, or at least make some progress toward them, then the rest of it was all for nothing.
This image shows progress on level generation. There were actually a few iterations that don’t show up here. I’m not even sure I have screenshots of them. Maybe at some point I’ll look back and try to find a few. It really started out with an idea that I wanted to create levels using cellular automata. And I did. And they actually were simply too organic. I made a small, playable game that would randomly generate a new map every time the spacebar was pressed, and would spawn the player in to one of eight edge/corner areas and create a goal that was as far away from the player as possible.
Map generation was very quick, even with large maps, but trying to skin everything immediately made me realize it just didn’t feel right. At this point, though, I wanted a true top-down 2D game (think Legend of Zelda on the NES).
After that experiment, I started looking at graph grammars and how they could apply to attaching branching groups of pre-made sections of dungeon together. I started down this road and was using Tiled and Tiled2Unity to import simple square rooms that had varying exits and would connect via those exits (top-left). The upside to this approach was that maps generated just as fast as the CA map generation, were much less organic, and had order (top-right). Green rooms came first, then yellow, the red. After, a purple room was created (boss room) and then all dead ends were capped off (blue rooms). This actually solved a few problems that I’ll now have to resolve entirely.
The downside to this approach was that it felt TOO inorganic. Even using a wider variety of rooms and hallways to create a dungeon via graph grammars gave it a feeling of being too symmetrical. I was able to use that to test some stuff with random placement of torches in a dungeon and allowing that to be the sole source of light (bottom-left).
Still, something new needed to be done. I decided that an angled view of a 3D world would fix a lot of issues, many of them related to physics, line of sight (LoS) and environments. I ended up trying, and am currently using, Dungeon Architect with Unity to create the maps (bottom-right). This has allowed me MUCH greater freedom to customize pseudo-random levels. So far I’m quite pleased.
The next part of my struggle was related to assets. I presumed there were two options – pay through the nose for an artist to give me custom assets, which is what I preferred, or use free/cheap assets and run the risk of the game looking very similar to other games out there. Neither of those were great options.
The top-left (yeah, very similar to the first top-left, right?) shows some very 8-bit stylings, which would’ve been fine if they weren’t so utterly generic. I ended up using Photoshop to create the top-right tileset for Tiled when I thought I’d use shape grammars. It wasn’t too bad, actually, for not being an artist. Multi-directional blending of regular, light, and dark dirt floors gave me pretty good control to paint tiles as I saw fit within those parameters. It still just didn’t feel right.
The bottom-left shows some early work (two months ago or so) with Dungeon Architect, some great assets from InfinityPBR that I somehow screwed up royally, and a REALLY bad camera design. The bottom-right is more or less the current look of the dungeon biome for the game. I have tons of biomes still to design, and tons and tons of stuff to still bring into the dungeon biome, but I have a good enough playable space that feels and looks “right” that I’ve gone, as I said, into the mechanics of things for a while so that I can do greater play-testing as I move along.
As a note to anyone reading this because they are embarking on their own game development adventure, just because I stopped using some tools or processes does not mean they aren’t great tools. They just weren’t right for this project. Tiled is a fantastic tool to design tile-based maps for many, many types of games and can deal with top-down, isometric, and even hexagonal tile systems. Tiled2Unity is a life saver if you’re using Tiled for a project in Unity, and Sean is incredibly helpful and quick to respond to things. Cellular automata is… well, it’s just fun. There’s tons that you can do with it, and making EXTREMELY organic feeling maps is one of those things. If you’re developing a game that is in caves or other natural systems, give it a shot. Graph/shape grammars is also really cool, and you can do a lot of different things with it. In fact, I still might use it for custom weapon creation, and even if I don’t I have another game idea for someday where shape grammars would be a perfect fit.
In the end, don’t be afraid to throw away a few months worth of work because it isn’t working. Don’t let it get you down, either. Sometimes that’s just the way of things. And I had heard it before it happened to me. It’s different when it is actually happening to you. Just know that many, many people have been there, too, and great things can come from it.
I’ve been working with the extremely awesome material generators from InfinityPBR. However, I can’t quite figure this issue out. In the demo scene provided with the generators (and sitting inside my staging project), the walls looks great. When I export them, bring them into my game project and attach them to my walls, they look awful. So… now I need to figure out what I’m doing wrong.