This week I've spent quite a few hours with Unreal Engine 4. Myself and a couple friends are toying around with the idea of developing a game. We're not at the level of disclosing what that game will be precisely, but I'd still like the share my experiences as it goes along.
Much of the time I've spent developing with UE4 has been familiarising myself with the editor, as well as the general workflow of game development. One of the hardest aspects is balancing game design, game development, and asset development.
For me, asset development is the worst aspect - I have no experience in 3D modelling, or graphic design, and not much drive to spend significant time on it although I realise any indie developer likely needs to do part of everything even if they have fellow team members.
Game development (programming) is my most natural activity. I've been studying Computer Science for 3 years at this point - coding almost every day. Even though UE4 primarily uses a language I have no experience with (C++) I'm perfectly comfortable (and excited) to learn whatever I need to get the task at hand done. UE4 also presents an interesting variation on game development, as even complex behaviour can be programmed using Blueprints.
Blueprinting is a type of visual scripting - you connect functions, macros, and operators together using graphical lines. Your initial reaction to this may be negative if you're familiar with regular coding, but Blueprints provide an awesome way to prototype behaviour and scripts very quickly. The performance of Blueprints are definitely comparable to native C++, but they can be a bottleneck if used in performance critical code.
The real benefit in Blueprinting is to quickly grasp an idea of what functionality is required to complete a task, and working out the best to do it. Once some functionality is written in Blueprints, it seems relatively easy to convert this code to C++. Blueprint code follows Object Oriented Programming design principles just like C++ - and there are even automatic conversion tools in the pipeline (currently an experimental feature in UE version 4.10).
The third aspect of creating a game is game design. This is the aspect of game creation that involves thinking of game features. What will this game look like? What will the gameplay be like? Who will play the game? How will we keep them playing? Currently we have a steadily growing document that lists everything we want included in the game. This is the most social aspect - discussing game features which we all likely have differing opinions on is tough, but rewarding. There have been many multi-hour conversations going back-and-forth over the same couple aspects of this game-to-be.
Overall my first foray into game creation has been pretty awesome. I look forward to getting to a technical demo level with the game, so that we can actually start showing off what all these hours of discussions have been around.
I have to say, one of my favourite things to do is daydream about what would happen if we actually manage to develop this game, get it Greenlit on Steam, and make it big - somewhat like Stardew Valley did extremely well last week. Although we're some way off, Stardew Valley was in development for 4 years before it's release.
Most Related Posts
Guest Post: Poker Analysis With HaskellThomas Fletcher is a Maths/Physics undergrad who has been working on a poker hand analysis tool in Haskell.
Amazon Development Centre Interview ExperienceIn a previous post, I spoke about my application experience for an Amazon internship. Here's how the interview stage went.
Enjoyed my post? Sign up to the newsletter to receive a small email when I post. No spam, I promise.