My Blog

Unity - Custom Editor & Item Data System

2020-06-18 12:46:42

A while ago I started working on a small RPG prototype for mobile, built within the Unity engine.
The idea was that you could collect a large variety of resources and build structures and craft special items.
With such a large amount of resources and items, managing it all by hard coding would quickly become a nightmare to sort, adjust values, or even just debug.
I wanted to design a system that I could quickly and easily add, remove, and adjust items at will, thus "The Oracle" was born. I called it that cause it sounded cool at the time.

 

The Oracle was built with Unity's custom window API, with a small selection of tools and other helpful features to allow easy editing of items in the game.

 

When I was building The Oracle, I had to move all my item data into a storage system instead of just one last script, something that allowed The Oracle to read and write to.
Doing some research I decided to use scriptable objects, this allowed me to attach prefabs and other Unity based objects and easy to implement into my code.

So now that we understand what The Oracle is, let us talk about some of its features.

 

The Resource Tab
The resource tab was all things relating to in-game objects that drop crafting materials when the player interacts with them, such as Trees, Rocks, and Bushes.
With this tab, I could easily create new resources that spawn in-game by a click of a button. I could change its name, its spawn chance, and even what tool it required to harvest.
I also added a system that allowed me to add multiple drops to it, with each drop having its own unique drop chance and amount dropped.



The Structures Tab
The structures tab did not have much as the other tabs since I didn't have the full construction system built yet, but within it, I could create structures that randomly spawned within the game world and easily change their model prefabs if I needed.


The Items Tab
The item tab was really useful, it handled all the crafting materials, weapons, armour and seeds (I had a whole farming system planned too). Like all the rest, this tab allowed me to easily create and adjust item values. Because of the different item types, the window automatically adjusts with different sliders and other customizing elements for the items unique values, for example I can change armour defence stats that I would not find on let's say a crafting material, a log doesn't need to know its defence or attack values.



The Recipe Tab
And lastly, the recipe tab, my personal favourite. As the name suggests, this handles all the game recipes. It allows me to create new recipes and pick what tool/structure is needed to craft the recipe, as well as what the end result of the recipe is and the amount it returns. It also allows me to edit what the ingredients are, not only allowing me to select from any item that exists in the game but also how many of that one item you need.



So that is it, that is The Oracle. I had a lot of fun designing and coding this small tool for my prototype, it was probably an overkill for a prototype but I learnt a lot.

Networking Demo - C++

2018-08-28 11:02:27

Back when I was studying at AIE, I did some messing around with a network library called Raknet. Using Raknet I made a small multiplayer Tetris demo, though it didn't work too well, was really buggy and it gave me a bad taste for networking.

 

A few weeks ago I decided to give networking another shot, but this time use a different library. This time I used a networking library called Enet.

 

Enet is a fairly lightweight UDP based library for C++. Unfortunately, it doesn't have much of a community to fall back to if things go sour and you need a hand. Even with this drawback, I decided to try it out regardless.

 

So now my adventure back into networking begins, but the question remains, what am I going to make to try out networking again? At first, I wanted to make a 2D space game with players flying around planet to planet to gather resources and trade them into a mothership at the center of the map. This idea stuck with me for a while until I found a tilemap I made for my first year of AIE, It was a tilemap I made from the sprites in the game Legend of Zelda Oracle of Ages.

 

 

This gave me huge inspiration to make a multiplayer demo using these sprites. So I decided I was just gonna make a small demo that lets multiple Links (players) just walk around together in a rebuilt town from the game. It might not be as complex as the space idea but at least it would look nicer.

 

I decided to use SFML again for this project, the same library I used for my multiplayer Tetris demo I made back in 2017. So after setting up a small playable area with collidable tiles, and ImGUI for debugging purposes. I got started on my networking.

 

Lucky for me, Enet has a really useful tutorial for setting up a basic server on its site. Without this, I probably would have soon gone back to Raknet again.
I did run into a few small problems with Enet, with the lack of community forums or such, I had to push my way through them with next to no guidance.
While making my server for the game I was constantly paranoid that I would run into a problem with the library that I wouldn't be able to fix. Which would force me to use a whole new library and rewrite a lot of my server code. Lucky for me though, I never run into a problem as such. (yet)

 

After I finished setting up my server, I started working on my clientside code. Like the server, I never ran into many problems, it was fairly smooth. Once I got them both finish and started up my server and clients, I noticed a major problem. I severely underthought about character movement. In Tetris, the players piece drops down 1 square at a time at set intervals if the player doesn't force it down. So I never noticed it, but in this game with the player constantly moving around, It was really jittery. Of course, I could just up the packet send rate, but that wouldn't work well over distance networks and it would flood my server with up to 60 packets per second, per client.

 

As sweet as that quick fix sounded, it was a no go. With next to no knowledge about networking player movement algorithms or stuff, I came up with a simple idea. It would work in most cases to just lerp the player from its last position to its most recent packet position. But this would have some drawbacks in a high latency client, but for now, it works well enough for a demo.


My networking demo contains a working chat console, allowing clients to talk to one another and changeable player names. Sadly I didn't get the animations to work for the connected players to ones client, so the Links just slide around.

 

I had a lot of fun working with networking, and I think it has really cleared up the bad taste from it. I've already learnt so many new things about networking and I'm eager to learn more.