Unity3d Asset Store vs DIY

I’ve spent wasted a lot of money in the Asset store.

If you’re working in Unity, I’m sure you know how it goes. You need some functionality implemented, and you wonder if it makes sense to do it yourself. Surely it seems an awful lot of work to implement just that one feature… It doesn’t take long until you start browsing the asset store and find an asset that looks just right for the task. Most of the time, having no way to test if it will work for you, you buy the asset and import it in your project, only to be frustrated a while later that it isn’t working as you expected it to work. The no-refund policy of the asset store leaves you at the mercy of the author of the asset, and you might be lucky if you ever get your money back.

Surely, I’ve bought some assets that I have put to good use, but right now I have a total of eight assets, which weren’t exactly cheap, and which I have no use of. I should have learned to keep DIY the first couple of times I’ve burned myself buying assets.

If this experience has taught me anything, is that you should be damn 100% percent sure a particular asset will work for you. If not, then it might be a perfect opportunity to do it yourself, and learn new stuff in the process.

So, what is your experience with the asset store? Do 3rd party assets work for you? Do you prefer DIY? Let me know in the comments.

Be sure to follow ongoing and more detailed development of the game on Patreon.

Low poly, no flatness

If you’ve been following me on twitter or facebook, you know that I have been busy redesigning the low-poly look of the game’s buildings. While I haven’t altered the poly count, I went with much more detail on the texturing front.

At first, the idea and inspiration came from my favourite game of all time – Betrayal at Krondor – but as I went on, searching for the look, I knew such minimalist graphics wouldn’t cut it. I wanted more detail. So I tried my hand at texturing, by applying UVs in Blender and drawing the actual textures in Affinity Photo, which I wholeheartedly reccommend as a cheap and equally valid alternative to Adobe’s Photoshop.

The result you can see in this photo.

Of course the rest of the land was just too flat at that point, so I went to add more detail to the roads.

Pictured is the before/after result. I’m not quite satisfied yet, but it’s an improvement.

I’ll report as more progress is made. Thank you for reading!

Be sure to follow ongoing and more detailed development of the game on Patreon.

Unity3D Low-Poly Terrain Goes Modular

All I wanted was a low-poly old-school terrain for my game.

Since I’ve decided to have first-person 3D exploration, I knew I would need some kind of terrain. In the beginning I went for the most straightforward solution: Unity’s built-in terrain, but that soon turned into a fruitless search for a way to make the terrain’s polys render sharp or “unsmoothed”. Turns out you can’t do it natively, so I’ve looked into the asset store. Surely somebody must have stumbled into the native terrain’s limitations. After a couple of minutes I’ve narrowed down the search to a script, which basically transform the terrain into a number of meshes, but I found the results unsatisfactory, as it didn’t give me enough control over the final result.

There had to be another way.

I’ve created a test Unity scene and imported a simple grid-turned-terrain blender model into it. It looked fine; it had the sharp edged faceted look I was searching for, but it was uncomfortable for me to design the terrain and essentially the game world in blender, when Unity was clearly a superior tool for the task.

Next I’ve come to the idea that I would have a huge grass plane representing the ground and start building the world from its center. I would create modular mountains and hills in blender, and place them on top of the plane. This idea really enticed me as I could organically compose the world from wherever I wanted, like lego pieces on a large table. But, it didn’t occur to me that I couldn’t do much with that single large plane. I couldn’t paint roads on it and even if I could, I definitely couldn’t carve rivers into it. That’s how my plan fell into the water…

Until one day, when the thought of lego blocks came back to me.

Tiles in the Unity editor

Like I did for the mountains, I used blender to create equally-sized terrain tiles representing road sections, river sections and other basic terrain elements. I would then import the meshes into unity, create prefabs and easily snap them together with the handy V-key shortcut. Voila, I had a modular terrain, which allowed me the same organic way of composing the world as a large plane would. I did run into an issue though: where the tiles met, I would get visible seams as you moved across the terrain, but I fixed it by attaching a script to each tile, which scales the tile up by a minuscule amount, just enough to overlap the tiles and hide the gap.

The initial blunder into paper prototyping

Building a nice terrain does require a huge amount of pieces though, and an intelligent naming convention helps a lot to distinguish all of the pieces as you go. I’ve spent several days prototyping the tiles on graph paper prior to firing up Blender and I am grateful I did. I keep the paper tiles as a handy reference as I am building the terrain.

What the paper prototype couldn’t do, was define the right scale of the tiles in the world. The first iteration proved the tiles were way too large for the player character and the mountains, so I scaled them down to 75%. I wanted to scale them down even further (to 50%), but the relative size of the roads and rivers got too small.

A this point I will either keep the scale at 75% or create new tiles with larger roads and rivers.

Anyway, to be continued…

Be sure to follow ongoing and more detailed development of the game on Patreon.

Going 3D (With a Twist)

One thing leads to another.

In the previous post I wrote how I’ve switched from SpriteKit to Unity, and today I’m so very glad I did. Now, my gut instinct is telling me to drop the textual locations navigation and go to a full 3D first-person exploration experience.

How on earth did I come to this?

Those who know me well, know that I am not that interested in making computer games. At least not in the plural; what I always wanted to create is a game, one heavily inspired by the legendary 1993’s RPG, Betrayal at Krondor (BaK).

When the idea to begin working on Call of Saregnar finally popped in my head, I imagined myself alone creating a game that would be much alike BaK, but of course modern, and at the same time – due to me working on the game all alone – cut down considerably. What that entailed was creating nice high resolution UI graphics, accompained by a text-based exploration interface (essentially replacing BaK’s 3D world exploration), and all spiced up by an engaging overhead 2D travel system with detailed camping. It sounded like a great BaK game in my head, except that… it didn’t. What CoS was lacking in my brain, was a true sense of exploration, one you could only get if you had the world in front of you, a world you could reach out, interact with and most of all, see.

I struggled with the idea of somehow taking CoS into the 3rd dimension for a very long time, but I was always hitting walls that indie developers know too well: you can’t do what the big AAA studios do; not alone, and especially not on low budget. What you need to do is find workarounds and make them look good.

That’s when it dawned on me. In the 2D realm, indies often opt for pixel art to compensate for lack of artistic skill or budget, or both. Not all, mind you, some simply love the pixely look, and create gorgeous pieces of art in that style. So, the question was, does anything comparable to pixel art exist in polygonal 3D? I was somehow surprised to find the answer at the very source: the crude BaK’s 3D world from 1993.

I am still working on the exact style I want to achieve in 3D, but I am thinking of the following:

  • I want to simulate a low-resolution screen (probably 320×240) all over the game.
  • I want to go with low poly 3D for the world and large other objects, like buildings
  • use billboards for detailed objects, like trees, bushes, etc.
  • I am not so sure about characters yet…

The goal is to have an old-school looking game, but one which does not look dated. A tough nut to crack for sure, but I’m sure the answer lies in the art direction, and that’s the side I am currently exploring.

Thanks for reading, see you next time.

P.S. You may want to check out Neal Hallford‘s blog for his Betrayal at Krondor: Remastered project if you are interested in an ongoing implementation of Betrayal at Krondor in a modern 3D engine.

Be sure to follow ongoing and more detailed development of the game on Patreon.

On Converting

Yes, I have made a conclusion. I am switching over to Unity for good.

So far it’s been incredibly smooth sailing converting the Swift code into Unity’s C#, since the two languages have – to my initial surprise – much in common. Mostly it is just a matter of replacing keywords and adding brackets and semicolons.

And let me tell you something about parsing XML. While in Swift I’ve struggled with 3rd party libraries to read XML and turn it manually into game objects, in C# it is almost automatic. I’ve already got a couple of objects set up by parsing the original XML files and it took me what, an hour together with figuring out how to do it. What a time saver, especially if I decide to rename or add a field in the XML, I don’t have to modify the parser, since there is none.

Most of the hard work ahead of me is converting all the SpriteKit and GameplayKit-specific calls into whatever Unity’s got, but I figure it is going to be fun, since learning is fun.

On the other side I’ve managed to crash Unity a couple of times, but that was me initializing objects at incorrect places. Still I’d love Unity to catch such occurrences and report them to me, instead of crashing with no error message to refer to. Also Monodevelop has been crashing from time to time with no apparent reason. I’ve read people switching to other code editors, but this one has a built-in debugger, so I may stick with its shortcomings.


I have enough of you Apple.

It’s been a while now that I’ve been struggling to see solutions to mundane development issues with Swift/SpriteKit. On top of a constantly changing (but wonderful) Swift language requiring me to rewrite large portions of my source code every couple of months, I kept hitting bugs in the compiler and frameworks, and encountering issues with stuff that should just work in the first place.

A couple of days ago, I’ve decided to take another look at Unity and what has changed since the last time I’ve played with it a couple of years ago. It turns out, a whole lot! The support for 2D is amazing, the GUI system looks simple and powerful and none of the issues on the Apple platform seem to exist here. And although I really love Swift, I don’t see any problems switching over to C#…especially when it comes equipped with so many powerful libraries.

I am also looking forward to the prospect of having CoS run on pretty much any platform I want, and not just OS X and iOS. I know many of my friends will be glad for it.

I will spend a couple more days/weeks making sure that Unity has what it takes to suit the particularies of Call of Saregnar, then I will most probably jump on that bandwagon and hopefully, never look back.

Morale Boosting

I’ve been working on the game every day – no exceptions – for some time now, and I’ve rarely felt like I was forcing myself into doing it. As far as I recall, this is the first time in the development of the game, that I’ve felt this way. I feel like I’ve reached a certain point where I am confident that the game can be made and will be made, and that is a big morale boost when working alone on a big-scale project like an RPG.

Another thing that obviously works fabulously well in bringing motivation into a project, is exposition. Recently I’ve started revealing the existence of CoS to the world, and have received a lot of positive feedback, particularly from our Slovenian SloGameDev.net community and friends. Even if I don’t have anything flashy to show yet, just openly speaking about the project makes it somehow more… real, and I urge everyone to let their project out in the open – you can only benefit from it.

Now please excuse me, I have a magic system do develop.