UE4 4.7.3 | ~7.5 hours in-engine
Personal notes via Google Docs
I wake up at 0430 and go about my routine: splash a bit of water on my face, put the kettle on, brew a cup of coffee. Then I sit at my machine & do what I do every Saturday morning: scroll through the images I’ve collected throughout the week from Tumblr, DeviantArt, & Flickr, trimming & curating & pinning to the Dark Acre Pinterest. As I’m doing this, a strange ball of anxiety begins to form in my chest, squeezing so tight it’s affecting my breath.
It’s the growing realization that I’m finally ready to build in Unreal Engine, & I’d better start doing something about that.
Do I jump right in & start reconstructing The Child, as I’d done the moment I’d 1st downloaded the Engine almost 4 weeks ago? No, that doesn’t feel like quite the right thing to do. What, then?
1 year, from November of ’11 to December of ’12, I’d resolved to produce little games every weekend as practice. Thus the Darkade Project had been born. I hadn’t always managed to complete something based on the constraints I’d set for myself, but for the most part I’d been able to make a fully-functional videogame in a day or two. It had been as good a practice as game jams had been, though in the end I’d abandoned it as I’d felt I’d been using up huge amounts of creative energy on throwaway results.
Since those designs are all done, (& by & large mostly clones), I think it would be a good idea to try & reproduce them 1st. They’re compact, the logic is all straightforward, & I have the originals as reference. So, that’s what I’ll do.
Darkade (UE Edition) #1 – Unreal Invaders
Documenting the steps I’m taking to achieve a game loop:
- Created a new, blank project with no starter content, targeting desktop at maximum quality.
- Created a new Pawn Blueprint (BP) named “Avatar_BP”, to which I added a Sphere and a Camera. Moved the Camera into an overhead view position.
- Created a new Game Mode BP named “GameMode_BP”, assigned Avatar_BP to Classes > Default Pawn Class.
- Figured that’d be it, pressed Play, realized I had to assign GameMode_BP in Project Settings… > Maps & Modes > Default Modes > Default GameMode.
- Alt+P, got expected result:
- Assigned some basic Input values for HorizontalMove (gamepad left stick X, A & D). As I’m taking teeny-tiny baby steps, I wired up this spit-stupid BP in the Avatar_BP’s Event Graph. I didn’t know Append was a thing until I wanted to do it, again demonstrating the intuitive power of the Blueprint system:
- In attempting to add movement to the avatar, I tried to simply wire the HorizontalMove axis value to the World Direction X on an Add Movement Input node. I quickly found out that that node is specific to Character Actors, & does nothing for base Pawns. This was remedied by using Add Actor World Offset instead. I added a variable to control the speed, & it worked like a charm.
- Went for a run.
- Got back & decided to play with camera movement. I’m not sure how verbose I need to be in this diary, so I’ll try to keep it brief & just post the resulting BPs. The initial & default location of the camera is a kind of overhead, 30° down view. I want to be able to toggle between that & 1st person view on the avatar. In the Construction Script for the Avatar_BP I set the start & end transforms to variables, then in a bound action I switch between them. Also gating the movement with booleans to prevent action during the switch, parenting the camera once it’s at the avatar, & wired the reverse logic:
- Clamping the avatar movement to within a specific range took a little longer than I expected, but the logic worked the same as it would’ve in C# scripting: set a horizontal limit, if the avatar moves outside of that push it back inside.
- After a lot of screwing around trying to do something utterly pointless (track a bullet position), I cleaned up projectile spawning & have movement & shooting. For some reason the movement clamping is broken now, though, but it’ll have to wait until tomorrow.
I’d like to take a moment to re-iterate that this diary is simply a way for me to focus while getting into the swing of things with Unreal Engine. What this diary isn’t is an examination of “why Unreal is better than X game development engine”. A tool is only ever as good as the people who use it, & in the end a shipped game in any tech is still a shipped game, & that beats the millions & millions of abandoned or half-baked ideas that barely get off the launching pad. Just as a side note: I still believe in Unity, it’s a fantastic tool, & if anyone should need any evidence I’d present Pillars of Eternity as a stellar example of what it can achieve. Heck, as of this writing more than half of the top 10 PC games on Metacritic were made in Unity…