top of page
Search
  • Brendan McIntyre

A Change in plans

Sorry everyone for such a long time between updates, however I have a change of plans to what I am working on now. A few weeks ago, I decided to stop working on contract defender. This was because I was starting to become bogged down with the work. I was making very little progress while putting in a lot of effort in doing so. This was draining my motivation to work on the project. So I made the decision to temporary stop working on the game to work on other projects, I am not scrapping the project however, and may come back to working on it at a later date when I have some motivation to work on it.

So now this brings me to what I have done over the past few weeks. The first thing that I wanted to learn about Unreal's Niagara particle system. After following several tutorials, I decided to attempt to make some effects by myself; some were more ambitious than others. The two that I think turned out best were this stylised fire effect and this sparkle animation, which utilises sub uvs to generate an animated particle.

However, I am still new to this new particle system and so I will continue to learn about it over time.

The next project that I worked on was a small experimentation into creating dynamic splines from meshes. This is something that I saw a while ago but never really had the chance to take the time to learn about it. So I decided to take this opportunity to do so, with this being the end result.

While it certainly is an interesting mechanic to know about, it wasn’t really able to fully explore and utilise it. To do so would involve having meshes more optimised for this, which I currently do not have access to.

Now, the main project I have been working on is a small game about collecting and storing items. The main focus of this small project was to practice on some new mechanics that I haven't really made before. It also gave me an opportunity to learn some new things, such as utilising maps in unreal (especially in c++) as well as more blueprint widget mechanics and features.

One of the main mechanics that I wanted to work on was an interactive inventory system. The internal mechanics of the inventory were handled using two structures: one for the items and one for the inventory itself.

The original plan was to have the items in the inventory stored in a map. However, I wasn’t able to get it to work, so I reverted to a normal array (although I may still come back and attempt to change things). The inventory struct also handles the internal running of the inventory, performing tasks such as handling the insertion of items and keeping track of the location of each item.


On the other side, the player’s main interaction with the inventory is handled using blueprint widgets. Initially I was naively going to add in each slot and all of it’s elements into the one widget. However, this was tedious to implement and really bloated out the number of functions used; it also made it incredibly annoying and time consuming to adjust the number of items the player could have in their inventory. The solution came to me later on in the development, when I learned how to dynamically add in widgets to the screen, which I used in the player’s storage.

This allowed me to significantly reduce the amount of functions used and made it much easier to dynamically change the number of items the player could use. This process involved creating a custom widget that included a size box, which allowed this widget’s size to be adjusted. From there I could add in all the elements needed for the inventory slot, which included a background image, an image for the item and the text displaying the item’s quantity.

From there I could just create x amount of these widgets and add them to an existing uniform grid element whenever the player opens their inventory.

The other main part of this project involved making the storage. Since the design of the storage was different to the inventory, it gave me the opportunity to use a map to store all the item data that the player puts into it.

The storage is broken into three parts: adding items, removing items and displaying the items. Adding in the items was simple. This was just an instance of the inventory widget and a image, that when clicked on with an item, takes the selected item and adds to the storage.

When it came time to create the display storage item widget, I knew that I needed to approach it differently to how I originally would have done it. Already at this point I had realised that the way I had been doing the inventory was tedious; making this screen with a similar method would just not be worth it. So that’s when I looked into instantiating widget elements onto the screen during runtime. I created a widget that would be the template, which include an image for the item and text displaying it’s name and quantity.

When the display items widget is opened, it goes through the map and generates this widget and updates its information based on the values in the map.

The final widget that was made was the removal of items. This allows players to remove items from the storage and put it into their inventory. This ended up being quite tricky. My initial process was to add in both the display items and the inventory widgets. However, I realised that I needed the extra functionality of getting items from the storage to the inventory that the display items widget didn’t need. So I recreated the widget with one key difference; I created a different widget that had a button attached to it.

The exact functionality of this button did change several times. The final decision was that the button attempts to add a full stack of the item to the inventory and ,if its successful and that item is now depleted from the storage, it calls for that item to be removed.

While these were the main mechanics and features that I wanted to learn and implement, there was one other feature that was interesting to learn. In the game I wanted to create a piece of text that would display the item and quantity the player receives when they get it from an item node. Since the handling of the player receiving an item was done in c++, it made it difficult to for the widget to know when the player received an item. So that’s when I looked into and found that blueprint functions could be bound to a c++ created delegate. This meant that now I could display the item that the player receives when they receive it and have it remove itself after a fixed amount of time.

So that’s everything that I have been up to in the since the last blog post. Currently I do not have any solid plans as to what I will be working on. I have some ideas of working with both unity again and continuing my exploration of the Unreal Engine and c++. However, I’ve decided to focus on smaller projects to really focus on improving and developing my skills on specific areas of both languages and engines. I currently have no plans as to when the next blog will be, it’ll happen whenever I have enough content to talk about.

So until next time, Goodbye.

7 views0 comments

Recent Posts

See All
Post: Blog2_Post
bottom of page