So, after a considerable amount of back and forth, I’ve decided to go with a fully 3D world and a fixed isometric camera. The 2D method was intriguing, but ran up against a few issues:
- Physics in 2D isn’t quite as… real? I’m sure 2D physics can be made to feel real to some degree, but our worldly physics exists in a 3D world, and I just wasn’t a fan of the flat feeling.
- Art in 2D is harder to make and get made. This one surprised me the most. It seems far easier to create and find 3D models and assets than 2D. It’s even easier to find 3D modelers than it is to find sprite artists.
- Partly related to #1, lighting, LoS and other similar bits are much more difficult in 2D (for me, at least). These things sort of exist naturally in 3D worldspace. They seem very shoe-horned into 2D.
So, I’ve found some tools and assets that are helping me move this along. After spending months (literally) trying different methods to create the levels, I’ve settled on a tool crafted by Code Respawn called Dungeon Architect. It’s a fairly extensible dungeon/level generation tool that is giving me playable spaces out of the box. Over time I will need to modify the underlying code a bit, but for now it is a HUGE time saver. If you’re interested in checking it out, they also make a version for the Unreal Engine here.
One of my other struggles was art. I am not an artist. I can modify art like crazy, but aside from my past experience as a semi-professional photographer, creation of new art is difficult for me. That led to a big concern; I could pay thousands of dollars that I don’t currently have to artists to create fresh new content, or I could find cheap, existing assets and have a game that looks like other games that use those assets. Neither are great options. Lo and behold, a third option presented itself via the absolutely amazing and customizable assets from InfinityPBR. Tons of 3D models, materials and substances that are extremely malleable right inside the Unity engine. The brick wall in the image below is created from their Brick Generator. The options are incredible enough that I spent an entire evening – literally hours – making, remaking, and fine-tuning a wall just the way I wanted it. The image below isn’t great (it’s not runtime, it looks better in the game), but it’s a fine example of some of the stuff from InfinityPBR. The torch is also theirs, with a few particle effects and a point light added for effect.
If you are trying to break into game development and need assets, I cannot recommend InfinityPBR highly enough. The assets range from US$45-60 each, but each asset isn’t a static thing – it’s a small library of things. They also offer a $25/package option to pick up every new package (seems like a couple each month) at a HUGE discount the day they come out, before they are available on the Unity store. Even if you get some assets you might not use now, it never hurts to have a great 3D library, and at that price you really cannot go wrong.
It’s been a busy few weeks with family and work and catching up on reading (and trying to complete my platinum trophy on The Witcher 3). But now it’s time to delve back in. Hopefully there should be some more regular updates coming again soon.
Sometimes I see something that just pleases me. This bit of code is one of those things.
So there’s been some refactoring to how rooms are created, a new set of room tiles made a couple of weeks ago, the addition of some more realistic torch placement in the deep dark cave and it seemed like it was time to run my ‘SIZETEST’ map again just to get a feel for things.
The ‘SIZETEST’ is set to a base of 2500 rooms, far larger than anything expected in the finished game. Currently, it ends up being 2674 rooms in the cave biome. The base size is used to generate a rough estimate of a given maze/dungeon size, but other factors and randomizations will throw that off by a factor. At any rate, clearly the refactoring has been good. With only general logging enabled, it now only takes ~3 seconds to create that 2674 room behemoth pictured below.
That leads me to another thing that my day job should’ve taught me, but that somehow had been slipping my mind of late – logging is a resource hog. Turning on the full compliment of logging nearly doubles the generation time. Still, even with logging now, it takes ~6 seconds with logging. Previously, the SIZETEST was taking closer to ~35-45 seconds to generate. This is pleasing.
Same map without the room-stage color coding, so you can see the lighting placement.
Well, I’ve overcome the first major hurdle for cave/dungeon lighting. It’s no longer haphazardly sprawled about – it’s now at wall vertices. Next step – put in on the line segments instead and randomize them a bit more.
In the first “Trying to Figure it Out” segment, I’ll share a question I posted on Stack Exchange. Sometimes things just aren’t that easy to figure out, and crowd-sourcing an answer, or at least some guidance, can save huge amounts of time.
A couple of the first unique rooms in the game (interestingly this screenshot shows two of the same room – oops!) with lighting from a single torch.
Tiled and Tiled2Unity are both saviors, but neither come without a few major question marks. Interestingly, right now every time I import a new room into my project, I have to reimport the tileset, even though it doesn’t change at all. Not quite sure what’s up with that. But it’s a minor headache.
I’ve switched to a properly top-down perspective player character as well. It’s a place holder with no animation, but it gives a better feel for scope, motion, and lighting. The movement script is a bit weak, and something funky is going down with the rotation of the sprite – sometimes he just rotates eternally for no good reason after coming to a stop. It’s the joy of figuring out these little things that cause development time to increase.
Remember, great ideas don’t always lead to great code. Hell, great code doesn’t even always lead to great code, and first attempt code is rarely great.
Oddly, the thing I found most difficult about this was using Pyxel Edit to actually put the tilesets together. Not that PE was a problem, *I* was a problem. I ended up overwriting some tiles here and there, then creating duplicate tiles as I was moving between the editor and the tile set itself. But, the lesson is learned.
For anyone interested in the process, I started with a “dirt” image from some other tilesets out there, edited it a bit in Photoshop CS4, brought it down to 64px x 64px (since that’s the “unit” size I’m using in Unity) and used that as the base. The darker dirt color was that base. For the lighter dirt, I lightened the tiles or selections from the tiles by +30. For the cave walls I darkened the selections by -70, then ran Photoshop’s Sponge filter with settings of (0, 0, 8).
Beyond the base full dark dirt tile, I mostly worked in a 3×3 grid with a feathered mask that ran from 32px in and over to 160px back and down, making a sort of rounded, feathered area that blended from a midpoint 32 pixels into the edges. This helps ensure that all tiles will fit together nicely and look decent.
For the diagonal tiles, I overlaid opposing corners, used the polygon lasso tool to cut across the opposite diagonal, merged the layers down and BOOM! There’s a diagonal tile.
The sections at the very top center and bottom center are where the three types of terrain blend together. I’m fairly certain that I’m missing a few combinations, but this should be pretty good to start.
For anyone looking to work in tilesets and the like, Pyxel Edit is a GREAT tool. And I think it costs about US$9, so it won’t break the bank.