Multiplayer, multiprayer

Over the weekend, I finally got the time to delve into the multiplayer functionalities of the Unreal Engine from chapter 8 of my book. I was happy to discover that the general way of things is kind of similar to Unity's way, where server and client code are shared, but clearer in a way; instead of RPC calls, just add the keyword 'client' or 'server' in the function prototype and you're done, every call to it will be sent over the network.

For the variables it's even simpler; instead of having your network view tracking some component, you can just add the variables you want replicated in the 'replication' block and have them being automatically replicated under some conditions. Things get more complicated from there, but it's overall pretty logical.

It all looks nice and easy, but setting up the multiplayer was a bit of a pain for a first time user. Of course, there was the regular mistake of forgetting to call the parent class' version of functions in the reeimplementation (in this case, PostBeginPlay(), which is a pretty big deal since the server crashes at that point), which is still as frustrating as the first time ("How could I have been so dumb!"). Once that was done, my next 4 hours were dedicated to dig in the Unreal API and find out why my weapon wasn't firing. As it turns out, a function I had copied from the PhysicsGun class was not necessarily meant to be taken in a multiplayer setting, at least not the way I was doing it. Just changing its name (StartFire to ServerStartFire) did the trick.

Of course, after doing all this it looks *only* like what it did when it was single player. Which means there's no video this time. Still, I'm really happy. The biggest achievements are not necessarily the most visible ones.

Phun with Physics

Following up on my last post, I played around with the physics gun class. I also figured out how to add actors influenced by physics (KActors, thanks to the example map that helped me figure it out). Not too long after... voilà! I managed to use the physics gun class properly, as the picture here tries to show (but it kinda fails at it, a video would be better).

Box flying thanks to the awesome gun (I used the rocket launcher visuals)

Now I just have to customize the functionality to have the guns I need... and then I can move on to The Rest!

After GDC, attacking again!

Last week was crazy. GDC is as much a networking ground as it is an old friend's reunion and party place. That said, now is the time to go back to what makes it all worth it: making games!

After some consideration, I decided to ditch my first pass at a level altogether. A purely vertical level was presenting challenges that I wasn't sure I had the time to address; therefore, I opted for a horizontal disposition, as you can see in the following image.

View from above

My goal is to make a small 3D tic tac toe FPS with physics combat elements. Which means, instead of shooting each other in the face, the players will each have a gun each applying a different force on the target (one attractive, one repulsive). The goal for the players is same as in tic-tac-toe, but in order to place a symbol somewhere they will have to use their gun to manipulate it. Of course, you can also hinder the movements of the other player by shooting your gun at him/her, by blocking critical corridors...

To make it all happen, I've started digging around the API to see which classes I can extend and which functions I can use. I've found a physics gun class, which seems like it would be a good starting point.

After the storm

Hey there! Didn't see you in a while. One of my other projects finally caught up to me and I had to enter crunch mode, so I completely neglected this independent study.

It ends today.

I came back to Unreal today with renewed determination and started building what will be the first room of my first game. Pretty exciting to me :) however, since I plan on doing several really similar room, I'm going to try to look into how to copy/paste with BSP surfaces. It might be easy; I couldn't find it.

Here's what the room looks like:

From the outside

From the inside

There will be two different geometric shapes in the middle of each room: a sphere, as you can see, and some other shape (still to determine). Those shapes will be changeable depending on the players' actions. Also, the rooms are going to be disposed in a 3x3x3 layout.

Now the game of the day... from what I've said, can you guess which type of game I'm building?

Level building

In the list of things to learn, here's a pretty good one. Terrains and static meshes are one thing; but how do you build a level?

Introducing the BSP brush! This building brush comes with several preset shapes (primitives like planes, cube, spheres, but also straight stairs, curved stairs...); you just select the different sizes you want (by right-clicking on the shape - that sounds obvious, but I could only figure it out by reading the official doc), and then adding the surface (and since you can add, you can also substract - pretty interesting and offers good creative possibilities).

And that's not it! With this tool, you can also add special volumes: water volumes, physics blocking volumes, but also level streaming volumes, ladder, gravity... Overall a pretty easy to use and very powerful tool.

So far, the only problem I faced when using this tool was the fact that you have to drag the brush around to go where you want your volume/surface to be created. It sounds ok, but when you have a really big volume and you want to align the edges with some other surface, for instance, it gets pretty painful.

After several hours of slow progression, here's a screenshot of my first level with the BSP brush. There are regular surfaces, some with materials on them, a skybox (waaaa) and a water volume with a transparent plane on top featuring an animated water material (so pretty! also kinda inadapted to the scenery I was building but oh well ;)). And some stairs. I like stairs.

My dreamhouse

The editor: terrain, textures, meshes

Big undertaking, big problems, big discoveries.

I realized today (silly me) that in order to build a game with unreal engine, I didn't just need to know how to program it. I also need to know how to properly build it, as in, build the map(s) or level(s).

Grave underestimation.

The UDK editor comes with a huge set of features, each of which requires some learning to be able to use. My first challenge was to understand how to create a terrain and shape it. With the help of a couple of videos found on the official website, I managed to create my first terrain, and to even have different textures on it. Small step for mankind, giant leap for me.

Awesome! Now I can create kick-ass maps!
...and, er, what should I have in them? Next challenge please!

I have to admit, my experience in Unity didn't prepare me for dealing with Unreal. It's not that it's hard, it's just that the learning curve is steeper. But once you know what you need to know, everything's perfectly doable. And figuring out by myself (achievement unlocked!) how to add static meshes from a different package into the current map is a proof to show the world that it is kinda intuitive; once you learned one of the tools, the rest of them are used pretty similarly. I even figured out how to paint colors directly on the meshes. Yea, I painted the roof of the citadel into pink.

And now, what's left? Well... All the rest.

Where I'm at, visually

Just thought I'd share this. Here's what the book helped me do:

The code for generating the weapon upgrades (green cubes that the character picks up) is created through Kismet (you can see Kismet talking on the left). The enemies all have states, and change color when they change states (red for seeking, green for attacking, blue for fleeing). The big one at the end is the boss, in his first phase (10 < HP <= 30) he generates more minions, in his second phase (0 < HP <= 10) he just shoots rockets.

First thing on the to-do list: improve the aiming. Not knowing which way you're facing makes it really hard >_> Second thing, those smaller enemies that go really fast, well, they're really annoying... and sometimes too frequent (right now they have a 25% chance of being spawned). Tweaks to follow.

Some progress on the book

After a week a furious reading, I finally reached chapter 7 of the book. On the way, I learned a good amount of things.

The first of these things is lots of syntax for  inheritance relationships:

Class CustomActor extends Actor;

self.EatAPancake();

super.ClimbMountEverest();

who refer respectively to declaring an inheritance relationship, getting the reference to the instance calling the code, or calling the superclass' implementation of a function. No big surprises there.

There is also lots of specific syntax for variables themselves:

• local is used for declaring temporary variables while inside a function; note that you can only declare local variables at the beginning of the function, like in C.
• config which I previously talked about;
• const which is for constant variables, unsurprisingly and like many other languages out there

A LOT of specific syntax for functions:

• event for events (mostly, just functions called from the native C++ code);
• simulated, client, server, reliable, unreliable are all modifiers that are used for multiplayer functions;
• const, NoExport, latent, iterator for people who can use native C++ code with the engine (i.e. people who pay for the license. Other people can use the ones already created, but not declare new ones). Out of these, latent means a function only usable while in a state, and iterator is for subroutines.
• native is pretty straightforward, and obviously subject to the same limitations as before;
• singular to prevent the function from being recursively called and thus prevent potential crashes from infinite recursion;
• exec which is for functions that can be called from the console and for player input functions.

There might be more. I'm pretty sure I saw some final (non reeimplementable, I assume) and coerce (??? remember to check the doc for this one) laying around.

Also, there's a pretty cool implementation of states: by using the state keyword inside a function, one can define a set of functions usable only by this state. The state changing is as simple as calling GoToState('StateName'); and there are some useful BeginState and EndState functions. Of course, redefining a Tick function there is the obvious thing to do (it's the update function, same as Update in Unity). Having previously implemented a state machine in C# for the Barreleye project, I'm more than glad this is already there. Oh, and they can be "subclassed" :)

And finally, learning about Kismets has been pretty fun. Kismets are a sequence of events that can be created in the editor itself; it's visual programming for designers. With patience, one could probably write a game entirely in kismets; however, it would get complicated really fast, in addition to the kismets being run on a layer on top of UnrealScript which makes them slower. Also, kismets are valid only for the level they're created on.

Since Kismets only became clear after actually working with them, here's an image of a kismet I made with the book's help (note that it also includes a kismet created from UnrealScript code :)):

There. Only 3.5 chapters to go!

The theme is out!

...well, one could argue it's more gameplay than theme. Either way, it's going to be pretty interesting:

"No gravity, no friction"

Annnnd...go! Interestingly enough, it's a theme I considered before, because of a Donald Duck comic.

Other news, I'm done with the second chapter of the book. It wasn't much, really, especially if you already know programming languages. The one thing I learned is mostly syntax, and special keywords:

var int numberOfShoes;

is for regular variables, whereas

var() int numberOfShoes;

is for variables that need to be accessible within the editor. Also,

var config int numberOfShoes;

is for variables that are loaded from the config files. Note that the editor value takes precedence over the config value.

Here's the part where I'm wondering whether this blog will turn into a technical blog, to which I answer... I do what I want ;) but I'll definitely post stuff that I find interesting, whether it's programming or design, or anything.

Next time we'll talk about design!

isProjectSetup = true;

A lots of steps for amazon employees, a kinda big step for me: I received the book that should help me get started! It's called "Unreal Development Kit Game Programming with UnrealScript: Beginner's Guide" and it's written by Rachel Cordone.

So far, so good: I finished the first chapter, installed everything and created a new project with the UDK. I also created my first custom actor, added it to the example map, and made it print a nice Hello World message in the log. Traditions have been observed.

Well now! Time to delve deeper into UnrealScript, and concurrently, to start thinking about a game idea. I found some video game name or theme generators, some being more interesting than others:

http://videogamena.me/
http://dl.dropbox.com/u/9894614/ludumthemes/themegen.html
http://iq212.com/generator.php
http://www.generatorland.com/glgenerator.aspx?id=132&rlx=y

I might go with the second one, since the problem with the other ones is that they might be slightly too descriptive, and I want my creative freedom so I can do my own crap (which hopefully will get better as I practice ;) but I've seen and heard enough that I'm not expecting my first 10 or 100 designs to be awesome).

Getting Started

Hello there! Welcome to this blog.

The objective of this blog is to keep track of my project this semester while I dig into the Unreal Engine, learn how to use it, then start making games with it. I will have roughly three weeks to learn about it, then it's game-making time! A game every three weeks, for a total of 3 games, until the end of the semester (some gamejammers would say that three weeks is too much, but I have plenty of other work to do :)).

My first tasks: order a book about the Unreal engine, download the UDK, and find a random game name generator to help me pick themes.

This is going to be fun :)