Using Json in Unreal Engine 4 – Part 2


In the last post, we had a look at how to serialize Json in Unreal Engine 4 – that is, converting a C++ Json object into an actual Json string that we can do something with, such as send to a web API.

This time we’re going to look at the opposite, which is deserializing Json – taking a Json string and putting it into a C++ Json object that we can then read properties from.

Deserializing is significantly quicker and easier than serializing.

Let’s use the weapon example from the first post that we want to deserialize.

Similar to the serialization process, we first need an FJsonObject to work with

Where we used a TJsonWriter and TJsonWriterFactory for serialization, we now want to use a TJsonReader and TJsonReaderFactory for the deserialization process as such:

JsonString is simply an FString containing the Json that we are deserializing, which would be the Json at the start of this article.

The next step is to then deserialize the Json. Rather than using the Serialize function in the FJsonSerializer class, we simply use the Deserialize function. The Deserialize function returns whether the Json was successfully deserialized or not.

Note the two parameters that we pass to the deserialize function – the Reader,  and the JsonObject we want to deserialize into.

If the deserialization is successful, then we can simply read out the values from the JsonObject!

JsonObject->GetStringField( TEXT("Name")); will return “Super Sword”.

That’s it for simple Json deserialization! In the next post I’ll look at using some of the more advanced utilities available for Json in UE4.


Creating a Content Browser Asset in UE4


Sometimes when working in UE4, you might want to create instances of your object in the Content Browser as assets that can be saved out to disk, or have custom editors associated with them. For instance, having your own asset type allows you to create a custom editor UI for it. Editors built into the engine include things such as Blueprint Editor, SoundCue Editor, etc. The process to do this is actually quite simple! All you need to do is create a Factory for your object.

I’ve started by creating a simple class called MyObject – the header and CPP files are below

Once you have your object created, the next step is to create the Factory class. This class is only usable if you are including the UnrealEd module in your Build.cs file to the PublicDependencyModuleNames array. The Factory class is quite straightforward:

After that comes the implementation of the Factory itself. I’ll paste the code and highlight the two lines of importance

If you look through this code, we have two important lines

SupportedClass = UMyObject::StaticClass(); is the object that we want to create. If you have your own object then replace the UMyObject with that.

UMyObject* MyObjectAsset = ConstructObject(Class, InParent, Name, Flags | RF_Transactional); is the line that actually constructs the object. You’ll notice that the type of the variable as well as the templated call to ConstructObject. Once again, if you have your own object, then replace these with your class name.

Once you compile these and launch the editor, simply right-click in the Content browser and under Miscellaneous, you’ll be able to create your object



Once you create the asset, you’ll see it in the content browser like any other asset built into the engine



Finally, if you double click on the object you’ll get a standard editor where you’re able to edit the properties of the object


You can check out Factory.h for other ways to customize the factory. I’ll touch on some of those in a later blog post.

Its important to note that even though you can now edit the properties of the object once you open it (or start implementing your own editor), you need to configure your object to serialize that data out. That is a whole new post as well, another one that I’ll cover in the future. If you want to look into it yourself, check out the Serialize function in other asset types.

Using Json in Unreal Engine 4 – Part 1


Unreal Engine 4 provides some great JSON utility structures and functions for parsing and creating JSON. It’s a format that’s used a lot for data storage and transmission, especially with web requests.
This post is the first part in a short series introducing how to use Json in UE4. I’m not aiming to introduce what Json is – if you’re unfamiliar, there’s plenty of resources online.

JSON Modules
All the functionality for JSON in UE4 is included in two modules: Json and JsonUtilities, which are both in the Source/Runtime directory. To be able to use these in your project, simply add Json and JsonUtilities to your project’s PrivateDependencyModuleNames (located in your project’s build rules file – normally called Project.Build.cs)

Using Json
There are two ways to read and write Json in UE4. Either you can read the data and build the Json yourself, or you can use the built-in utility functions in JsonUtilities that use UE4’s reflection system to read from the UPROPERTYs in classes or structs.
This post will focus on the former – just using the simple Json functions to build some simple Json strings.

Json Objects
Json supports a number of types – bool, string, number. These are generally stored as a name with an associated value. Each of these name-value pairs are stored inside a Json object, which is essentially what is between the curly braces in a Json string.
These Json object is represented with the FJsonObject class in UE4, which is declared as such:

TSharedPtr JsonObject = MakeShareable(new FJsonObject);

Once you have created the root Json object, it’s as simple as adding the name-value pairs that you want. We’ll build a really simple set of properties that might represent a weapon, along with how much damage it does
JsonObject->SetStringField("Name", "Super Sword");
JsonObject->SetNumberField("Damage", 15);
JsonObject->SetNumberField("Weight", 3);

Note that you can call SetObjectField to add a new object type as well.

Serializing Json
Once you build your FJsonObject, you’ll need to get a string representation of that to do something with – save to a file, for instance. This can be achieved using a TJsonWriter to write the Json, and the FJsonSerializer class to serialize the JsonObject itself.
The simplest is the TJsonWriterFactory, shown below:
FString OutputString;
TSharedRef< TJsonWriter<> > Writer = TJsonWriterFactory<>::Create(&OutputString);
FJsonSerializer::Serialize(JsonObject.ToSharedRef(), Writer);

This will serialize the Json to OutputString which you are then free to do whatever you want with – pass to a Http request, save to a file, write to a database etc.

Print Policies
The TJsonWriterFactory is templated to accept a “policy” which determines the way the Json is printed – for instance, “pretty” so its correctly formatted, or “condensed” so all the whitespace is removed. The names of these policies are TCondensedJsonPrintPolicy and TPrettyJsonPrintPolicy.

To use these, you need to pass the appropriate policy when creating the TJsonWriter, as such:
TSharedRef< TJsonWriter<TCHAR, TPrettyJsonPrintPolicy > > JsonWriter = TJsonWriterFactory<tchar, tprettyjsonprintpolicy="">::Create(&OutputString);

That looks a bit long-winded, but you can easily typedef these yourself to make it more readable. This line of code tyedefs a TJsonWriter with the pretty print policy as FPrettyJsonWriter in place of the Writer we declared earlier:
typedef TJsonWriter<tchar, tprettyjsonprintpolicy=""> FPrettyJsonWriter;

And can then be used as such:
TSharedRef< FPrettyJsonStringWriter > Writer = FPrettyJsonStringWriterFactory::Create( &OutputString );

When put together, this code would produce the following Json:
"Name" : "Super Sword",
"Damage: " 15,
"Weight" : 3

That’s all for how to create and serialize Json in UE4. In the next part I’ll look at how to deserialize Json.

Input Axis in UE4


Unreal Engine 4 has some awesome features and a whole bunch of stuff that makes life really easy. Lots of these are small, minor things that people often don’t pick up on, or can be hidden away a little, and the Unreal Engine blog is doing a great job of explaining some of these things.

One thing I’ve found is that often the posts don’t go quite far enough in showing an example of how to use something, which is the goal of this post, and hopefully more into the future.

This concerns the Input Axis feature, which is well explained in this blog post from Epic
But how can these input axis bindings get put to use?
It’s actually quite simple!

In this example, I’m working on a Shoot Em’ Up prototype purely in Blueprint

Shoot 'Em Up prototype in UE4

Shoot ‘Em Up prototype in UE4

I’ve added a couple of simple InpuxAxis bindings as described in the Unreal Engine post.
If what you want to control is based off Character, then by default it has a CharacterMovementComponent which you can see in the Components tab.


CharacterMovementComponent in the Blueprint Components tab

If you have this, then there’s a very handy way to move your Character in Blueprint – the AddMovementInput node.


AddMovementInput node

This accepts a Direction and a Scale Value. In the case of the Shoot Em Up. The Direction is simply the direction you want to move the Character in, and the ScaleValue is the scale that you get from the InputAxis.


Using an InputAxis event

As you can see here, I’m using Horizontal Axis and moving it along X.

If you’ve already got a setup and don’t want to use the InputAxis events, you can also get the axis values as variables


Using an InputAxis variable

That’s all for this post!

Tegra K1 – What’s it worth?


I hardly consider myself any sort of authority on anything. I’m just another dude with an opinion who makes games and teaches people to make games. Thats why I generally avoid commenting outside of my area of expertise – generally I stick to talking about events I’ve been to, teaching things, some game design related stuff. Things I’ve done, screwed up and found solutions for.

This post will be a little different. This post is a piece of commentary, which I haven’t really done before.

This week was CES2014 – Consumer Electronics Show – and there’s always some great announcements. This year the one that has caught everyone’s eye is the announcement of the Tegra K1 – a 192-core mobile chip based on Nvidia’s Kepler desktop graphics architecture.
This announcement is big for a few reasons, not the least of which being accompanying videos showing Unreal Engine 4 running on a K1-powered device, and the reveal that it was a DirectX 11 chip.

Many websites have covered the announcement and tech specs of the processor, so there’s no point repeating all that. What I want to talk about are the potential implications for mobile game developers.

As developers we’ve had fairly powerful chips for a while. Granted, those chips aren’t anywhere near the power of the K1 but we’ve been able to make some pretty sexy looking games as it is. So what opportunities does one chip in a saturated marketplace offer to developers?

Despite a massive increase in power and the promise of coming close to matching PC quality graphics, I still believe there will be challenges developing for mobile devices in the forseeable future. While we do have DirectX 11 support on the K1, that will surely be limited to just Windows mobile devices which only make up a small percentage of the mobile market. Developers working with DirectX on PC will still need to work on dual rendering pipelines in order for games to run on mobile devices.
The proliferation of these chips is another potential concern. We are yet to see what else will come of the next generation to compete with the K1 for power, and without exclusive partnerships from hardware & device manufacturers I feel that developers would hesitate to design a game that focuses purely on the high-end, as its such a small marketplace.
Finally, the last challenge is that mobile devices are still inherently casual devices. 2D or small simple titles still totally dominate the mobile marketplace and given the lack of success by high-quality AAA-style 3D games on mobile devices in the past, you have to wonder where these style of games fit into the mobile economy.

We’re still probably a few years away from games being developed/ported to mobile in the same way that PC-to-console works right now. For developers who plan on using high-end engines like Unreal Engine 4 to take advantage of the better chips there are associated risks, given the majority of any target market will be in the mid-range of devices come next generation. But that doesn’t mean its not a risk worth taking – the payoff for a quality mobile title can still be huge.

Its going to be a hard for higher-end mobile developers to strike that balance. Perhaps a good first step is even some sort of asset sharing between systems. What I do believe is that this that Nvidia may have fired the first shot in what will be a long battle for mobile chip producers.

UnrealScript Training Content


In 2012, I wrote and delivered a single subject at TAFE, replacing a teacher who was taking a semester off. The subject was a programming and in the past had focused on Java, but the TAFE was trying to bring Unreal into its curriculum more, so considered this subject as a trial of teaching UnrealScript.

The subject went reasonably well with some hiccups, but unfortunately the idea of teaching UnrealScript as one subject in the course didn’t take off, for a variety of reasons. It seems like a waste to do nothing with the content I had written, so I’m releasing them here.

It consists of a handful of PDFs going through some basics of UnrealScript as well as basic mutator creation, basic weapons and basic gametypes. There may be some gaps in the content as it was a mix of Powerpoint slides, documents and working in a classroom with students. You can download a zip of the PDFs here.

New Years Resolution


Every time I seem to make a pledge to blog more it never seems to actually work – at my current rate I write 3, maybe 4 blog posts a year which is definitely not enough.
I say it every year, but this year will be different. This time, I think I mean it. In the past year I’ve gone between several jobs, worked on contracts and prototypes at Pub Games that we couldn’t talk about. With a more stable job (teaching distance-ed full time) and involvement in Pub Games part-time working on a variety of projects this year.
One of the commitments that we tried making as a company when we first formed was to be open in the development process. When you look at a lot of the successful indies, they share a lot of things about their game as it progresses. Its part of the indie way of marketing – development blogs, progress screenshots and reports, and early access.

My challenge is managing what I talk about. What I work on is often technical, inside the guts of game mechanics or engine technology. Its solving problems that a lot of people have solved before, but just not in our context. That doesn’t necessarily make for interesting blogging, especially if I’m not showing code or anything like that.
Anyone who has read my blog in the past knows that I’m often long-winded and heavily opinionated. Writing these sorts of posts requires a lot of time, something really interesting to talk about, or something interesting I’ve read that I have an opinion on. This is one of the aspects I want to try to change – the occasional big opinion piece, but keeping the blog more regularly updated, even with small tech things, small discussions on what I’m working on, etc. It might not be the best opinion, or even an opinion at all. It might just be the way I’ve gone about solving a problem.

So that’s my New Years Resolution. To be a better, more regular blogger. Lets see if works out this year.

PAX Australia 2013 Reflection


For those of you who weren’t aware, PAX came to Australia in 2013. Specifically to Melbourne. It was the first time such an event had been held in Australia. While we have events like EB Expo, it’s not the same scope or reputation as PAX. For the local industry, it was a fairly big deal that PAX was coming to Australia – it would give Aussie developers a chance to take part in a big event that gets lots of media coverage.

The expo itself was fantastic. The indie section is the best that we’d ever seen, attendance was good and we got to showcase our game to plenty of people. It did have its share of issues – for instance, the facilities left a bit to be desired, but that wasn’t unexpected due to the venue it was held at. While there was a bit of miscommunication during the organisation of the event, overall it was pretty successful and well run.
For Pub Games, this expo was something a bit special. We’re not strangers to exhibiting at all – we’ve been to both PAX events in the USA, as well as GDC and EB Expo. But not only was it being held in our home state, not 25 minutes from our office, but it was the first time that we got to showcase a released title. This meant that we could get far more information on the impact and success of the event in regards to download numbers, social media “likes” and website hits.

I’d like to mention that the Crabitron did a short analysis of how their sales changed during PAX. You can check it out on their website. In short, they did have a spike in sales during PAX weekend, as well as a decent increase in their rank on the App Store.

Unfortunately, the same can’t be said for BlastPoints. Our new installs per day during PAX pretty much stayed the same. Our social media “Likes” only increased when we ran a competition to win a MOGA Controller.
It is a fairly small sample size – one event, covered mostly by local media in a location that was awfully hard to try to get people to download the game on the spot. On reflection, we did some things wrong:

  • We didn’t make it obvious that the game was free-to-play;
  • Our signage with the Google Play and App Store logos was designed poorly in that the icons weren’t even visible due to monitors and a TV on our table;
  • We didn’t have a flyer or card with information about the game.

These aren’t things that had really occured to us in the past because the game had never been released at any other stage, and they’re definitely things that we will be keeping in mind for the future. Its the first time any of us had shown a released product at an expo.

So what does this really mean?

Its difficult to say much based on just these numbers. The first question is “What do you aim to get from your marketing dollar?”. Companies such as Riot Games and Wargaming invested big amounts of money in their booths and swag at PAX Australia, and one suspects they wouldn’t recoup that money in direct sales in the week after the event. What it does get them is exposure in the media. From interviews to their booth being in photos shared across social media, its all about exposure rather than a direct return in sales and download numbers. PAX got us a few interviews with various media outlets, helped us further build relationships with companies and, most importantly, strengthen the Pub Games brand.

The second question is “Should you still attend these expos if you don’t make back what you spend?”. The answer to that question is absolutely – no direct spike in numbers doesn’t mean we cut our losses and stop attending exhibits. This information is just another tool for us to use in the future on how we can do better. We can now ask ourselves how we can try to get more people to get the game on the spot, and how we can better promote our game and the company. Crabitron got a spike by discounting their game to 99c. Other companies often give away vouchers for free in-game items. These are steps we can look at taking for future events to help get a better bang for our buck.

One of the best aspects about PAX is that it was the first time I’d helped exhibit a game at an expo. I can tell you for sure that I definitely did not expect it to be as tiring as it was. By the end of the first day, I’d lost my voice. By the end of the second day I was definitely sick and ended up taking the third day off. But its something thats a great experience – having people walk past and take an interest in what you’ve crafted. Having people genuinely interested in your story, how the game came about and where you plan to take it. In the end, as a developer, you want to see people enjoying what you’ve made. And while it was an exhausting experience, I’m genuinely excited about the next opportunity that we get to showcase what Pub Games is about.

UnrealScript Game Programming Cookbook Review


It’s been a long time since I’ve actually made a post on this blog, and that’s been for very good reason. Frankly, I haven’t had much to talk about for a while. Real life interrupted, things happened, BlastPoints work kicked up, etc.
With BlastPoints now out the door (release is very soon), and prototyping of new projects underway (albeit things I still can’t talk publicly about too much), one of my goals is to start writing a bit more. I guess I have a bit of a varied life, between teaching, game development and possibly a software engineering job, so hopefully things will pop up more often that I can talk about from many perspectives.
The other issue I find with blogging is that often a lot of opinions I have are awfully strong and often contrary to other opinion. Some may view them as criticisms, rightly or wrongly, and often they don’t come across well.

But now onto the real purpose of this blog post. I was approached by Packt Publishing not long ago to review an UnrealScript book they had published. Quick disclaimer: I’m not being paid for this review or anything like that. This is just my honest opinion of the book.

The book is called “UnrealScript Game Programming Cookbook“. It’s important to note that this book doesn’t teach programming and syntax, but rather provides some practical applications of UnrealScript as well as explanations of the structure of things inside the engine – ie the relationship between Cameras, Controllers, and Pawns. I love this method of teaching, as you can learn the language and its constructs in a practical way that you can see results. Epic has provided some great documentation about the technical side of UnrealScript so more applied examples are always good.

The first couple of chapters don’t deal a lot in programming. They prepare the reader for some of the fundamental setup and prerequisite knowledge. Chapter 1 covers setup of a variety of IDEs. I’m glad to see is the suggestion to use Archetypes (covered in Chapter 2), as they’re a bit under-used by a lot of UnrealScript developers in favor of hard-coded data. Offloading changes to a system that doesn’t need to wait for compile and startup times is a great thing to do.

The topics that are covered throughout the book are Camera Systems, Pickups, AI & Navigation, Weapons, HUD, and a couple of miscellaneous recipes. I can’t help but feel a few of these re-tread well documented and sampled areas of UnrealScript already – for instance Camera system samples are already fairly well documented from both a practical and structural point of view on UDN.

The chapter on AI is by far the best and most valuable part of the book. While it probably doesn’t go into as much depth as it should, it’s as good of a starting point as I’ve seen for developing AI code and setting up navmeshes as appropriate. It covers the basics of pathfinding using both pathnodes and Navmeshes, which has been a headache for a lot of people I’ve known in the past. Unfortunately its also one of the areas that can go horribly wrong depending on your context, and very few of those issues are addressed in the book either.

The samples throughout the book are moderately well explained in a code sense and a structural sense. The samples look well constructed, but perhaps could have been more applicable to general development, or perhaps sequenced better to more gradually introduce people into the structure of the engine. Mutators aren’t covered at all, despite being a great introductory point for programmers starting with the engine. Gametypes could probably have been covered in more depth, as well as some more custom behaviour for Pawns and PlayerControllers. In my opinion, that sort of basic game structure are things that are more in demand and valuable for anyone looking to learn UDK.

I have two main criticisms of the book.
The first is simply the formatting and some of the way in which information is presented. There are many errors and typos throughout the book – I came across a variable declaration that looked like “var(Camera) constboolUseThirdPerson;”. While any experienced programmer will figure out exactly what this is meant to look like, it can still be confusing and just serves to confuse readers. Don’t get me wrong, this isn’t the first technical book to have typos and it won’t be the last, but most of those books have been (rightly) criticized for those issues.

Secondly, a lot of pretty important concepts are brushed over, or mentioned in passing and never referenced again (and no references are provided for further reading  Despite its intention being to provide “recipes” to be quickly followed to get a result, theory on how you go about some of these things is important as well. A couple of examples spring to mind here. The use of Sockets is mentioned on one page and a screenshot of a character with sockets is shown. However, there is no further explanation on what Sockets are for, or even a link to documentation on how to access the Socket Editor. The other one relates to sub-objects, which are used all over the engine (and several times in the book) but never explained, at least not that I could see. These are just two of a few examples where a fairly important concept is mentioned but never expanded upon at all.

I’m going to be honest here. I haven’t read any other UnrealScript books, and the times I’ve taught it I’ve written my own subject material. It’s hard to compare the quality of this book to others, because I simply haven’t read them. This book hits some good notes (the general approach, Cameras despite them being a well-trodden area, AI/Navigation) and misses the point in a few areas. The typos and formatting issues are a huge problem, even as far as incorrect characters being used for important concepts (explaining the log macro used ‘ rather than `)
One of the upsides is that the book is available in digital format, which is always a great thing for programmers and programming books. If I had to give it a rating, it would be a generous 6/10.

Steam Greenlight


Steam Greenlight has been live for slighty over two weeks. In this time it has seen the submission of hundreds of games, a change from a free submission to a $100 paid submission, much public scrutiny about the discoverability of titles on Greenlight and discussion about whether its simply a popularity contest

Despite this, people are already jumping to conclusions about the sort of games that players are looking for in Greenlight after the announcement of the first batch of 10 games Valve will be releasing on Steam. Amongst the inclusions were perennial favorites such as Black Mesa, No More Room In Hell and Project Zomboid – titles that have huge community followings as it is.

The question I’d like to pose is why people are making judgements on what players are looking for based on 16 days of the service being available. 16 days that has been, at best, a mess of a launch. What we have are 10 games with existing community followings and a system that doesn’t encourage exploration or discoverability on the part of players. Not only that, but suggesting that designers take something away from this first 16 days is irresponsible.

As it stands, Valve doesn’t release any details about player habits and title/genre popularity on Steam, nor do we know or understand the correlation between these players and the players who vote and visit Greenlight. We simply don’t know which markets Steam is appealing to right now (as we have no sales figures) and what market is actually visiting Greenlight. To attempt to infer details about a market based on the small fraction of the 50 million players who use Steam is a poor approach.

What we have is a young system that’s the first of its kind to be made available to players and a set of already very popular games to get voted as the first 10. Anyone who didn’t expect the first games to be big-name titles is kidding themselves. Lets give Greenlight a chance to mature and see what other games get Greenlit before jumping to conclusions.

Go to Top
%d bloggers like this: