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.

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.