The End of an Era

A few things have happened this year that I can no longer ignore, or keep silent about.

UE4

The community Epic has managed to craft around UE4 is amazing. Not only is the engine completely open-source, and the forums livelier than ever, and phenomenal assets available on the new Marketplace…Epic is also making excellent tutorials in both blog and video form. They are striving to make it possible for anyone to be a game developer, and I would say they are succeeding.

I got into game development in high school because of this thing called “senior project.” The idea was we could pick anything reasonably hard for a high school student to do, do it, and then we’d graduate with honors. Making a video game is hard, right? 😛 At that time UDK had just debuted (2009 seems so long ago…) and looked really awesome, so I picked it up and just rolled with it.

Documentation back then was hard to come by. Apart from packaged editors for games like UT3 and Gears of War, this was the first time Epic had unleashed their tools on the public. As I struggled to understand everything that was going on, I felt the similar pain of countless others online. So naturally, I started making video tutorials. And then because videos were hard to pump out at a constant tempo, I started a blog. This blog.

Fast-forward to now. I was one of a select group chosen to be a part of the UE4 beta because of my blog/videos, and I can’t imagine receiving a higher honor. Although I did not contribute much, I was deeply humbled to be a part of the road leading to one of the greatest advancements in gaming. The thing is, as much as I love using UE4 — except for C++, I still hate the language and always will — development is useless without a goal. As I have learned over the years, I am quite terrible at coming up with ideas for cool games, and even worse at coaxing them to fruition.

I started out as a game developer wanting to make a game, and ended up (hopefully) helping many others to make their own. But I must face the fact that there are much better resources out there now.

I Got a Job

Like a real job. Not some freelance gig, but a job where you get some numbers on a piece of paper every month and have to take an elevator to get to.

It’s no coincidence that this job has nothing to do with game development. For the past 3.5 years I’ve been studying computer science in college, and I’ve realized that the great big world of computers is much more diverse than my feeble mind could have ever imagined in high school. I particularly like web development now, in these things called JavaScript and Python.

The thing about having a real programming job is that at the end of the day, the last thing you want to do is program some more — even if it is a game. If you don’t believe me just try it and see.

Making a game is an adventure, true, but it’s a decidedly dedicated one. There just aren’t enough hours in the day to support two programming lifestyles. I do want to have some semblance of a life, after all.

So What Does This Mean?

Does this mean I’m done making videos? Done writing blog posts? Well, no. But there are some changes in order.

First off, I happen to have a new blog that’s tied to my official site. I hope you find it just as snazzy as this one; unlike this one, I built it from the ground up with a mixture of blood and joyful tears. You’ll notice that most of the posts have nothing to do with game development. I made this blog specifically to supplement my video tutorials, and for the longest time I’ve felt constrained by what subject material was appropriate to publish. On my new blog, I write whatever the heck I feel like. Freedom is cool.

I also might start making videos again, but they’ll probably have nothing to do with “how to do _____ in UE4.” I’m not exactly sure what they’d be about. We’ll see 🙂

There is, however, one thing that won’t change. If you have any questions, comments, or concerns about anything UDK/UE4 related, feel free to email me and I’ll try to help. I might not always be quick about it (as some of you who have emailed me in the past can attest to), but my door is an open one.

It’s been a great 5 years, and I want to thank everyone I’ve met along the way for making my game development adventure a blast. I’m sure it won’t be the last.

Until next time, happy gaming!

Book: Game Programming Patterns

Go read it now!

It’s free and online! This is the book I wish I had when I started making games, and I want you to have it now!

I’ve only read the first few chapters, but already I can see this will be an indispensable resource for game programmers. The book is more low level, less on game design and more about the code at the heart of things, but it’s written beautifully and is chock full of examples.

It’s also all C++. So yeah, UE4 and stuff.

Unreal Engine 4 Review

NOTE: This post was originally written in 2013, but could not be published due to certain NDA clashes. Now that UE4 is public I can finally share my thoughts with the world. Small edits have been made to make sure the post remains relevant, since UE4 has advanced a lot since last year.

TL;DR

I was given the amazing opportunity to preview Unreal Engine 4 in private beta. Verdict? UE4 is currently the best game engine in the known universe.

Contents

1. UnrealScript is Dead, Long Live C++
2. Faster than a Cheetah on Jet Pack Rollerskates
3. Blueprint: Kismet on Steroids
4. UE4 Loves Version Control
5. An Editor for You and Me
6. Let’s Rocket To Infinity and Beyond

UnrealScript is Dead, Long Live C++

I may as well get the biggest rumor out of the way first. UnrealScript is gone. 100% out of there. You know all that effort you put into learning UnrealScript these past few years for UDK? Yeah, not important anymore. Forget all of it.

Well, not all of it.

But most of it.

I could go into great detail about how much I hate C++, but we’ll leave that for another post. The sad truth is, C++ is pretty much the de facto language in game development and if you want to get anywhere in this industry you should at least know its basics. And what better incentive than UE4?

My loathing for C++ aside, programming in UE4 isn’t really that bad. It helps to have had a course in C/C++ (as I did) and one or two C++ books lying around (my personal favorite is C++ Primer Plus, but a better starter book is C++ For Dummies), and a second monitor for Stack Overflow is indispensable. Even with all these resources, though, the learning curve for C++ is gigantic.

In that respect, Epic Games has tried to make programming as painless as possible. Remember the hot-load feature from the UE4 Features Walkthrough? Totally works. You no longer need to quit the editor to recompile code; in fact, compiling from the editor is recommended. There’s a C++ Class Wizard, also in-editor, to help with generating boilerplate code. And there are dozens of sweet C++ macros to learn that help boost your code’s functionality. For example, this:

UFUNCTION(BlueprintCallable, Category="MyAwesomeFunctions")
static void MyAwesomeFunction();

will allow me to call MyAwesomeFunction() from Blueprint (we’ll get to that later). I also love the Unreal Smart Pointer Library. If you’ve coded in C-and-friends for any length of time you probably despise pointers. In UE4, just use TSharedRef all over the place and you’re good to go.

Of course, you’ll have to learn all of these UE4-specific tricks and shortcuts in addition to learning C++ by itself. So prepare yourself for a lot of learning.

Faster than a Cheetah on Jet Pack Rollerskates

One reason why C++ is so popular is that it’s fast. For UE4, this means a dramatic speed improvement in almost every way. On my computer, the editor starts up in a little under 5 seconds, whereas UDK can take up to half a minute to load. Compilation takes about the same amount of time in either version (20-40 seconds for a smallish project), but I chalk that up to Visual Studio doing a bunch of linking junk in the background that UDK never had to do.

The engine is also no longer strictly limited to 30 FPS. The editor (which is build upon the engine, mind you) consistently runs over 60 FPS and usually clocks in at 110 FPS for the default level. Depending on the game, I do get FPS drops occasionally, but never below 30 FPS. And there are crazy optimizations at work: open a menu while in the editor and you’ll flat-line at 120 FPS, because the world doesn’t need to render since you’re looking at a menu. Yeah, they’ve thought this through.

Epic was also not lying about gameplay performance. I’ve done the million-particles test and UE4 was able to pull it off with no sweat. And a good friend of mine has dropped over 3000 dynamic lights into a single level — UE4 didn’t even blink.

You might be wondering about the state of lighting in the engine. In a video I posted a while back, I said UE4 would have dynamic global illumination. This is not entirely true anymore. I’d have to agree with the reasoning; if it makes the engine that much faster at the expense of “fake” dynamic lighting, then I can live with it.

So how fast is UE4? Well:

It’s a well-known fact that jetpack rollerskate cheetahs are the fastest Earthbound objects in existence.

Blueprint: Kismet on Steroids

Wait, that title isn’t accurate. “Steroids” gives Blueprint a negative connotation, when in fact Blueprints are quite positively awesome. I should really say something more along the lines of “Blueprint: Kismet if Kismet Exercised Daily, Ate a Balanced Diet, and Learned C++“. But that’s kind of a long title. I digress.

Blueprint is in some sense the successor of Kismet, but it’s really a lot more than that. Put very simply, Blueprint is a visual scripting language. Imagine if you took any piece of code you’ve written in UnrealScript and tried to draw it out as a graph of nodes connected by wires. That would be Blueprint.

In UDK, Kismet was only a visual graph for events in a single level. But in UE4, Blueprints can be applied to pretty much anything. You have your standard Level Blueprint (doing what Kismet did), but you also have Class Blueprints that extend the functionality of C++ classes within the editor. Blueprints can be saved like any other asset in the Content Browser. Blueprints can talk to other Blueprints (this functionality is current kind of lacking, but Epic says it will become a lot more robust in future releases). Blueprints can even be included in other Blueprints via macros.

Blueprint can’t do everything C++ can do, but I envision that at some point it will become powerful enough that we don’t need to depend on C++ at all. In fact, Epic has already released a demo game called Swing Ninja that is written completely in Blueprint, and some people on the forums have already done things in Blueprint that I wouldn’t even begin to try coding in C++. And a final added bonus is, it’s incredibly easy to learn. Actually, if you’ve done any work in Kismet at all, you already know it.

Let’s end by revisiting my previous code example:

UFUNCTION(BlueprintCallable, Category="MyAwesomeFunctions")
static void MyAwesomeFunction();

In UDK it was a real pain to add custom Kismet nodes, but in Blueprint this is all you need to do. Just hop on over to the editor after compiling and you’ll see your custom MyAwesomeFunction node in the MyAwesomeFunctions folder within Blueprint. Sweet, right? Yeah, I thought so.

UE4 Loves Version Control

One of the last things Epic did before stalling UDK development altogether was integrate Perforce version control. I’d like to take this time now to say that if you haven’t used version control before you should be ashamed of yourself. Even if you’re developing your game alone, you should try it out. Version control systems make life easier for software developers and increase the productivity of large teams dramatically.

In UE4, Perforce is enabled by default but can be disabled with the click of a button. I don’t use Perforce myself — not a hypocrite, I just like GitHub better — but I can see where this automatic integration would be insanely useful.

But suppose you don’t use Perforce (like me)? What benefits does it give you (and me)?

To facilitate better version control, Epic has rethought their entire project structure. Remember in UDK how we had the single folder, and all our game code lived in \Development, and all our assets in \UDKGame\Content, and so on? Ever tried working on two games at the same time using the same UDK release? No? Well it’s a pain in the posterior. That’s why I usually had two or more UDK version installed, one for each project I felt like messing around with. And if I wanted to somehow “separate” my game’s code/assets from the rest of the engine (to distribute its source, for instance) I had to resort to copying a bunch of folder paths all over the place.

In UE4, all your projects live in a folder called (appropriately enough) “Unreal Projects”. Inside this folder you can have any number of subfolders, one for each project you’re working on. And each project subfolder contains all your game’s code, assets, levels, etc. Here, each project’s structure is completely self-contained and separate from engine code. If I want to distribute the entire project, I just zip up its folder.

Each game asset is also now a separate file. No longer do we have giant 100MB files containing all the Necris archways and pillars and whatnot. Rather, we’d have a directory containing 200+ individual files, each one encapsulating a single mesh or texture or material. This makes version control a breeze because instead of having to upload the diff of a 100MB package every time you change the color of a single material inside it, you just have to upload the changed ~40KB material file. It’s beautiful.

An Editor for You and Me

One thing I’ve always loved about the Unreal Engine is that it’s very much community-oriented. Unlike in many other AAA game companies, with Epic the Unreal Engine is actually a product, so they put a lot of time and effort into making it useful to other developers as well.

UE4 takes this to the next level. Perhaps I should let Epic speak for itself:

Many Unreal Engine subsystems were designed to be extensible, allowing you to add entire new features and to modify built-in functionality without modifying the engine code directly. You can create new file types, add new menu items and tool bar commands to the editor, or even add entire new features and editor sub-modes!

The way to do this is through the new Plugin system. It’s currently very experimental and Epic cautions us that it will change in future releases, but I’ve already created a plugin and it’s actually pretty easy to do. A plugin, like a game project, is self-contained in a single directory. That means it can be zipped up and distributed for other users, and all they have to do is drop the code into the plugin directory \[UE4 root]\Engine\Plugins and it’ll be available to be installed in the editor.

At some point, I hope that Epic will have a plugin hosting service integrated into the editor itself a la Sublime Package Control, so that all we have to do is browse for available plugins, click a button to install, and profit.

Even if you don’t use plugins, though, UE4 is already way more customizable than UDK. For example, I know someone who’s made their editor pink. I’ll leave it up to you to figure out who that is.

Let’s Rocket To Infinity and Beyond

I believe I’ve already said this, but it bears repeating: UE4 is currently the best game engine in the known universe. It has its little quirks and flaws and many of its subsystems aren’t finished yet, but it’s already leaps and bounds above UE3 before it (and dare I say any other engine in the industry).

You may disagree. That’s cool. I’m not going to say you’re wrong.

But even if you don’t agree…at least give Epic a big hats off for all the work they’ve done. With UE4, they’ve certainly earned their name.

UE4 For Everyone

GO GO GO GO.

Yes, that’s a publicly available Unreal Engine 4. No, your eyes are not deceiving you.

For the past 9 months, UE4 has been in closed beta. Over that time it has evolved from a mere successor of UE3 into a next-generation experience. There are new Stack Overflow-style forums. The documentation is ridiculously extensive. There are sample projects galore. The community is, as always, very willing to help. This is not just a game engine, but as Tim Sweeney put it, a game ecosystem.

The engine appears to be free no longer, but rather subscription-based. I’m usually very much against subscriptions for software, but I can tell you that in this case, UE4 is a steal. For $19/month (about $230 a year), you get the best game engine on the market.

What I’m most excited about, though, is that Epic has finally open-sourced everything. They have a GitHub now! Well…okay, you need to be a subscriber first. But that sure beats the old model of paying thousands of dollars for the engine source.

The community has already made amazing leaps and bounds with UE4, and I cannot wait to see what’s coming next.

Redesigning WillyG Productions

In lieu of other topics to write about, and in case you may not have noticed it yet, I recently redesigned my online identity. Part of that can be seen in the banner at the top of this site. The best example, however, is at my new “hub of operations“.

The Logo

Showing the evolution of my logo from late 2009 (left) to present (right).

My logo has remained relatively unchanged over the years, but this month I really cracked down on making the final iteration as professional as possible. This is a far cry from 2009, when I made my first version for a high school graphics assignment. We were tasked with designing a product label, complete with nutritional information and a fake company. I decided to instead make a logo for myself (the name was, of course, different back then). I took the W from the font 28 Days Later, put it over a diamond, and colored the whole thing the first okay-looking dark red I saw in Photoshop.

During the summer of 2012 I decided my logo was a bit unclean (see all those little blood streaks in the W?) so I resolved to vectorize it. The way I did so was almost equally unclean; I just used the Pen Tool and traced the outline of the original W. As a result, the lines were straighter and the speckles were removed. I thought it looked fine, but…

Note to Self: NEVER create a geometric logo without using pure geometry.

With that in mind, I built the 2014 version completely from scratch out of a diamond, two ellipses — the subtle top/bottom curves of the W — and four extremely long triangles canted at precise angles. The red was also carefully chosen, and by “carefully” I mean stolen from Solarized, one of my favorite color schemes…although in my defense, Ethan Schoonover has spent quite a lot of time perfecting the colors to look good across a wide spectrum of applications. So, too, will my logo.

The Tagline

“I make things that do stuff” sounds rather dull and generic, but there’s a story behind it.

In my computer science program we frequently have to do group projects. Thankfully, we also usually get to pick who we work with. My default teammate is an army vet who happens to be just the right combination of smart and cynical, on top of being a great public speaker. Good for me, since I despise public speaking (can you tell from my YouTube videos?).

For the longest time, he would introduce our project by saying something along the lines of, “So yeah, we made this thing and…it does…stuff.” Created a database application that maintains WoW player information? “Our project was this database thing. It has data and does stuff.” Made a 1970’s text adventure parody of Oregon Trail? “So this is our game. We made it. Will’s gonna show you the stuff it does.” You get the idea.

I always hated it, because our grade was on the line and in 2-3 sentences he could make our cool project come across as…well, dull and generic.

But then I got to thinking. What do we really do as programmers? I’m not talking game designers or application developers or kernel hackers. I’m just talking programmers. Most of the time — no, not all of the time, life is never that easy — we’re making things. And these things do stuff. What they do depends on what the programmer is interested in, but the common trend is that we’re all creators.

Out of nothing, we make something.

I can no longer call myself strictly a game designer. I’m also not just a web designer or app developer. But I do make things that do stuff. So there you go.

The Site

Back to willyg302.github.io. One thing you might notice right off the bat is that it’s designed in discrete tiles. The root of this idea came from Google, but I took it a step further by making everything tiles, from the social icons to the welcome message to the list of projects I’m working on. The whole thing is powered by Isotope, giving it several unique properties:

• The site is instantly responsive, no extra work needed. Try resizing the browser window to see what I mean.
• Tiles can be filtered. This means creating a “site menu” is as simple as assigning categories to tiles (“Contact”, “Project”) and adding the filter dropdown.
• Tiles can be sorted. Not much use now, but likely useful when there are 70 projects or something up (not that I’ll ever be involved in that many projects).
• Tiles can expand. Click the “Research Assistant” tile for a demo. This allows for more, not immediately relevant information to be displayed if necessary.

I think it’s a cool idea, and definitely unlike any personal site I’ve ever seen on the Interwebz. One thing that’s great is that I don’t have to worry about formatting at all, and the content works even better when it’s jumbled and chaotic. Try doing that with a Bootstrap theme!

Why Mobile Games Are Ruining Gaming

First off, I’ve got nothing against the mobile platform or mobile games in general. I even made a mobile game once, and it was a pretty fun experience (sans Apple being an absolute donkey about the whole submission process).

I also have nothing against Flappy Bird. I think Dong Nguyen is awesome, assuming his story is true. He symbolizes an entire industry of one-man indie gamers, and his meteoric rise and fall should serve as a lesson to the rest of us. This post is not about Flappy Bird.

Rather, this post is about two other games I saw on the top charts this past week, and by association a plethora of other mobile games that are slowly destroying the values we indie developers hold dear. This post is about Flying Cyrus and Flappy Miley.

Okay, I get it. Flappy Bird becomes one of the most popular games of all time, not just on mobile devices but on any device period. There are bound to be people making parodies and tributes, even more so to fill the void following the game’s pull from app stores. I understand this need and even welcome it. I learned a lot about basic HTML5 game development from several of the open-source tribute/parody games on GitHub. Terry Cavanagh, creator of Super Hexagon, gave us his own creative spin with Maverick Bird: a game that has quickly become one of my favorites.

So somebody decides to take out the bird and put in a disembodied Miley Cyrus head? Sure, why not. It’s a kooky idea that’s almost guaranteed to stop app store browsers in their tracks. But then — and here’s the kicker — someone decides to rip off that game.

Neither game is particularly good, mind you. Like the original, they were probably created in the span of days. Their assets are horrendous. Their music tracks are thoughtless. Unlike the original, they seem to have been created solely to rake in money. They are shameless. Are they even games? Yes, I’m sad to say. But just barely.

Sadder still, they are not alone. I was mildly disgusted to see a commercial for Farm Heroes Saga the other day on TV — not because I hate Candy Crush Saga, but because this new game is such a blatant clone of it. So you have fruit instead of candy. Maybe it’s a healthier game? Is that what they’re going for? Or are they too busy being wholeheartedly greedy to invest time into making a better sequel?

Right now, we are at the dawn of a new age in gaming. The three giants of consoles have just released their new products and there has never been a better time for indie developers to get their feet wet. All around me, I see amazing and beautiful games being made. Some are AAA like Titanfall and Destiny. I can only hope these live up to the hype. But others are smaller, birthed by studios as small as Dong Nguyen’s, nevertheless having just as much potential to blow my mind.

At the same time, we are increasingly becoming shrouded in darkness, a darkness born out of the basest of human needs to make money, even if it means doing horrible things like churning out knockoffs or forcing consumers to pay to turn off ads. This isn’t what gaming is about. This isn’t why I dreamed of becoming a video game developer years ago.

So I see these things, and I can’t help but feel disillusioned by the whole matter. I spent the better part of 7 months making a mobile game, pouring my heart and soul into every asset and corner of every level. It was a flop. Then these heartless, soulless husks of games dominate the top charts. If you can’t beat them, join them, am I right?

Maybe I’ll make a game called Cyrus Crush Saga. See how King.com likes that.

The Plan for 2014

A Happy New Year to you all!

As this is the beginning of the year, it seems like a great time to lay down some resolutions that I will (hopefully) stick to.

First up, the last few months I have been really slipping off the old YouTube/blog wagon — especially when it comes to tutorials. Granted, I ran out of ideas for things to do (by “things to do” I suppose I really mean “things I’d be willing to invest time in doing”) quite a while back, but tutorials are what my channel is known for. The last semester has been particularly rough because I’ve had a heavy course load in school, two jobs, and a few side projects I’m not even allowed to talk about, much less make a tutorial for. But 2014 should be better. No…it will be better.

Next up: games. I’m supposed to be a game developer, but what did I actually accomplish in that regard in 2013? I made one game. This game took one week to make. The other 51 weeks were not wasted effort, but they were far from productive. I had many ideas that never came to fruition — ideas that I still have tucked away in the dusty corners of my mind. Maybe in 2014 I’ll wash a few of them off and see where they take me.

And finally, it should be no surprise to anyone that UDK is no longer the center of my creative universe. And yet the subtitle of my entire online identity remains “Your Premiere UDK Resource”. As UE4 looms over the horizon and I start to focus more on things like HTML5, Python, Java…well, what should become of my identity? I’d love to start blogging and YouTube-ing about more than just UDK. So in many respects, 2014 will be an interesting transition year.

I’m excited to see where the next 12 months takes us. Here’s to a year of happy gaming!

A Note on Noat

Ever since I started college, I’ve been working almost on a daily basis on two different computers: my desktop at home, and my laptop at school. I also occasionally do things on my phone. Having this many devices to keep track of radically changed the way I work. For example, I do most of my homework directly out of Dropbox to keep it synced across both computers.

But one thing I’ve always struggled with are notes. What to do with that little 3-sentence blurb I caught on my laptop but now need on my desktop at home? How can I let my laptop know the URL of the important site I just found on my phone?

My old solution was the tried-and-true email system. Yeah that’s right…I’d send myself emails. Lots of them. And the more I delved into the murky waters of computer science and game development, the more emails I found myself sending. I needed something else.

Wunderlist? Evernote? No. Pastebin? Tried it. GitHub Gists then, surely. No, I needed a tiny bit of privacy. What then? Dropbox? I didn’t feel like managing a text file of notes to myself on top of everything else.

Oh wait, I’m a programmer.

So I made this thing called Noat. It’s yet another note-taking app that looks like this:

A look at Noat

The image above showcases some of the features of Noat. It’s basically just a long stream of small boxes, each with a title and importance level (gray – default, blue – info, green – success, yellow – warning, red – danger) and some content. The content can contain some pretty rich formatting and even embedded images and URLs. But what sets Noat apart (at least in my opinion) is its simplicity. All you get is this stream of notes. You can edit or delete existing notes, or add a new one. That’s it.

It’s powered by App Engine and is built to be responsive, so you can use it on your mobile devices as well (and you can add a home screen shortcut on iPhones!). If you’re at all interested, the code is living over on GitHub.

I’ve been “testing” Noat for several months now and am exceedingly pleased with it. Hopefully someone else will find it useful as well.

Parse Is Awesome

There’s a maxim in software development that goes something like this:

If you have a great idea, someone is already working on it.

For me, the “great idea” was a simple, easy-to-use online game service (preferably free). For me, the “someone” is Parse. Given the amount of research I do into all things gaming, its a wonder I didn’t know about these guys before. They’re awesome.

You could wander over to their site to see why, but let me highlight a few of the more important things here. First off, they’ve created a system far better than I could have ever managed with either Gemini or Sagittarius. Parse is powered by Amazon EC2, comparable to Google App Engine in performance. And they have a pretty crazy database setup that focuses on MongoDB — what I would use for Sagittarius if I had a choice — but also includes MySQL, Cassandra, and Redis.

One thing I’m wary of about third-party services is that they usually kill on pricing or membership. For example, Steamworks is notoriously hard to get into for the average weekend game developer, and most other existing backend services offer pay-as-you-use, meaning nothing is free. But Parse offers one million request ops per month free. To put that in perspective, that’s about what Gemini clocks in at (it gets around 30000 hits a day at peak), and I’m servicing over 200 regularly active users. For someone just demoing a game or even sharing it with friends, Parse is perfect.

Just make sure you don’t go over 1 million though…$199 a month is steep. On the other hand, I always say that if your game does become that popular you probably wouldn’t worry too much about $199.

I got set up with a Parse backend and SDK in a little over 1 minute. I have been playing with it for a few days now and it does everything I’d want a game service to do. I’m planning to rewrite Dave Likes Pizza to use Parse as a better test of the backend, but from what I’ve seen it’s great.

At this point you might be wondering, “well what about Sagittarius?” In truth I have no idea. I was running into the proverbial brick wall in many ways with Sagittarius, and have spent a good part of the last month searching near and far for solutions. That’s how I found Parse. But now that I have this solution, I don’t know what’s going to become of my own service. Maybe I can turn Sagittarius into an UnrealScript/UE4 SDK for Parse?

Unreal Engine 4 at a Glance

I recently got the amazing opportunity to try out Unreal Engine 4. I hope to post more detailed info and a review of the engine at some point in the future, but for now I can only confirm a few things you should already know:

• UnrealScript is dead, long live C++
• Hot Reload (also known as Runtime-Compiled C++) is awesome
• Dynamic global illumination (SVOGI) isn’t a reality as I mentioned in my lighting tutorial; Lightmass is sticking around for the foreseeable future
• Epic Games is really good at living up to their name

Oh, and then there’s this:

A simulation of our Sun in UE4

One million lit, collision-enabled particles running at a silky-smooth 30 FPS on my middle-of-the-line rig. With UE4 around, the future of gaming looks equally bright.