building a game that reads your mind in 6 hours… OR the worlds first jump ‘n’ blink!

What happend before:

A few weeks ago, on the 17th of April I did attend to the first european neurogame jam which was an event about creating games utilizing the ability to read brainwaves through an off-the-shelve eeg neuro-headset such as the Emotive Epoc.

Sadly the timeframe that was set for that game jam (just a couple of hours) was way to short to actually build something, so we ended up having Jens and Iris do their presentations – which tought the rest of us about how the technology works, and the basics about the toolchain Iris created. After that we spend most of the time coming up with and discussing ideas and aspects of what one could do with this technology, while some of us did give the devices a spin, and we had some fun comparing brainwaves – but in the end we didn’t have the time to actually build something.

Also there is still a few problems with the technology – the two main points probably are:

  • While the machine learning that Iris build into the toolchain works extremly good, it has to learn all commands that can be used with in a game for every user, every time it is used (as taking off and putting it on again might already change what the device is picking up from you) – this means games build upon this would still have a ramp up time of 10+ minutes from “I want to play” to “I can play now”.
  • Latency is too high.

I left having had a good evening with some very interesting discussions, but I thought the next time that I’d hear about the technology would be in a few years when it is more ripe to work with it, and more devices are available.

So how did I end up building a game?

A few weeks later Iris contacted me, as she for the evaluation of her work still needed someone to implement something using her toolchain.

Now the catch: the toolchain is build for unity3d, which had very little experience with – but the invite was still standing, so last Monday I visited her at the teco and after a short refresh on what i had learned during the first european neurogame jam,  we set to build the game.

Knowing from the game jams that i’ve been to that time is extremly valuable, and knowing that not knowing unity would cost me some time, I set myself the following goals before thinking about an idea:

  • the game must be completely playable
  • as the game should have a quick “let me try that out” experience, doing a long learning-phase was a no-go.
  • asset creation? uhm.. not with less than 6 hours left

So i came up with a very very simple game – the character of the player is a simple ball which needs to get from the floor to the ceiling, using a set of steps – where some steps are white, and some steps are black. The ball would fall/jump through white steps, while it could stand/move on black steps.

Now the controls for movement would be regular keyboard commandos (to avoid frustration factors like learning phase for the user)

The twist? To get up to the ceiling the player needs to switch the colors of the steps. The control of changing the colors is linked to the game using Iris toolchain to watch the brainwaves of the player, and find the very distinctive pattern that happens when someone blinks. Whenever a blink is registered the game then changes the colors.

So to win the player needs to jump from step to step, blinking in the right moment, thus allowing him to reach the top.

The main problem building it was my unfamiliarity with unity, but since unity is using c#, at least i didn’t have to learn an unfamilliar language. (I think what took me the most time was actually trying to figure out how to color the objects. And what did also cost me some time was that changes done while the game is in “play” mode are forgotten afterwards).

Well in the end the game worked, and we had quite some fun trying it out – multiplayer (or extra-hard-mode) is when one does the jumping and the other the blinking ;)

So where can you see this game?
Well that is a bit of a problem at the moment, even if I’d provide a download, you would need the toolchain Iris build as well as an emotive epoc headset (which is quite expensive).

So the best I can offer is this video:

A few thoughts about composer and how people use it

A few thoughts about composer and how people use it

composer has changed the PHP ecosystem like no other tool introduced – almost everyone is using it today. Now, I have written about composer before, and have always been a big proponent of using it. However, as I have spend some time with looking more closely on a few things, there is a few problems (some with composer, some with how people (ab)use composer) that I would like to write about.

I’m pretty certain that my point of view is not the only valid one, and that some of you will disagree with what I say – use the comments if you want to add something or have questions, and if you blog a repsonse, please use a pingback so I’ll notice your post.

Please keep in mind: this is not a rant against composer. You should be using it.

Number 1 – composer gets slow and resource hungry

composer builds up quite huge dependency graphs to find out which packages to install, which means projects that depend on packages that have a lot of dependencies with history, and lax to no restraints on those 2nd level dependencies, will cause composer update to eat tons of ram, and take quite a while.

One option to “fix” that is to add your 2nd, 3rd etc. dependencies to your root composer.json, with tighter version contraints. While this actually limits the problem to some extend, its not a real fix though, as it means sooner or later you end up doing composers job manually yourself.

Another option is to turn of your memory limit, and keep supplying more memory to your machines, however I’ve been told that this breaks for windows users. Also it gets quite cumbersome when a composer update starts taking longer than a cigarette/coffee break.

Thats not the only thing that keeps it slow – composer is retrieving meta-data (and the contents) in a blocking manner, which means if one request is slow the whole process will be held up. Using something like reactphp could actually decrease the time composer needs for those tasks.

Number 2 – people are using composer as an installer

Something I did wrong myself when I started working with composer. Not only does composer make it easy to be abused in that manner, having the option to have composer check your php and your php extensions makes it seem like a logical step.

However, that is problematic for various reasons:

  • composer is a developer tool, as such it shouldn’t run on live machines
  • composer will fetch dependencies from a lot of sources, which means that your live systems would need to be able to fetch from there (ask your admin what he thinks about that), and to not get rate limited on github for example, you would need to put credentials on your live machine…
  • if you don’t backup your dependencies (and when using composer as an installer you don’t have an explicit step for that) you might get a bad surprise when someone decides to remove his project. Packagist only stores meta-data, if someone removes the git or the dist zip from github (or any other repository) you can only pray that you have cached it somewhere. I’ve seen a hand full of packages on packagist that are not available on github anymore.
  • your deployment becomes dependend on systems that are not under your control – if github gets ddosed again, or packagists provider fucks up routing again during deployment, you might end up with a much longer maintenance period that anticipated.

Let me from my perspective mention how I think composer should be used:

  1. developer initializes a new projekt using composer create-project
  2. developer adds requires as needed, he runs composer update to create the composer.lock file, which is added to the scm. this developer at this time is responsible to verify that the version(s) he updated to are working as required.
  3. when pulling a changed composer.lock from scm, each developer working on it will run composer install to have the correct setup.
  4. once a release is necessary the person who holds the release manager role will create a build of the project (it does not matter if he runs a build script or elevates a build in your build system, in the end someone is responsible to decide when something should be released). Most likely within this build there will be done something like composer install --prefer-dist --no-dev -o the result of this step should be a package (directory, zip, tarball, .deb, or whatever else your deployment system needs).
  5. the admin uses the result of 4. to install the release on a live machine

now obviously this does not cover all variants, for example if your release is a library that you want to publish on github, then step 4 is the process where you tag your version number and step 5 is not relevant. Or you have more processes inbetween (staging/QA etc) but this should illustrate how responsibilites should be separated, and it should prevent you from getting in a half-installed-live-system-situation.

Number 3 – people use their own paths

Now, I’m pretty sure this is one that quite a few people will disagree with me.

Composer offers the ability to use custom installers, and even provies the composer/installers package, which provides an easy way to install packages into other folders.

Quite a few Frameworks and CMS make use of this, usually for one or two of three reasons

  1. to install assets somewhere
  2. to keep an own directory structure (for legacy reasons)
  3. to distinguish various types of packages (regular depedencies, modules, themes, plugins…you name it)

where 3. seems to be the most common usecase.
Obviously its conveniant, by slapping those dependencies into different directories, you can have your module loaders etc, very easy detect a new module, or a new plugin.

So why am i listing this as a problem?
because:

  • own folders lower the interoperatbility of packages (ok, granted, this is bean counting, your blogs theme wouldn’t work with my forum anyways)
  • own folders lower the transparency (vendor code is in vendors, own code in the project),
  • and raise the learning curve (ok, if you only use one framework constantly, you probably can remember 5 paths)

as you see, the argument against it is actually a bit weak, however to me those are still valid arguments, and there are better solutions (puli, assetic (for assets), your installer managing a configuration file vs. using a dir to find all modules) available.

Number 4 – people don’t adhere semver

Semantic Versioning actually makes a lot of sense – the version contraints in composer follow the assumption that semantic versioning is used, still people choose not to. Why? i don’t know. But if you release bc breaking changes in a PATCH release, then there is a special place in hell for you.

Number 5 – people don’t tag their releases / don’t release

This goes hand in hand with Number 6 – I’ve seen packages that are on packagist, without ever having a version tagged. Thing is, the moment you put it on packagist, in theory, you should have a first version. If you don’t tag it, people can’t properly set their dependencies, meaning they shouldn’t be using it.

Don’t be scared of releasing, release often, and Majors if needed.

Also, as i’ve seen this lately, there are people who use branches instead of tags – well at least thats how it looks to me (maybe someone wants to enlighten me for the reason), which means you end up with versions like “2.3.x-dev, 2.2.x-dev, 2.1.x-dev”, which means you will always be on unstable versions.

Number 6 – people release packages with dependencies to unstable versions

Do I even need to say something about this? To my surprise it is not exactly uncommon, and quite often a result of number 5. Oh the joys on you requiring a package that has a stable version, but relies on a dev-package, that itself relies on a dev-package from a -develop branch.

Those who know composer a bit better might already have spotted the hidden evil in this combination. Your root packages composer.lock is the only composer.lock that is relevant. When you run composer update on your root package you might end up with a completely different version of dev-randompackage-develop than the developer who build the dev-otherrandompackage, and yet another one than the one who build stablepackage – which makes for nasty heisenbugs.

So, what now? / TL;DR

As you can see the things i listed are quite different aspects.

Number 1: to tackle this problem it probably requires a major rewrite of composer, and maybe even rethinking of how to use it

Number 2: one can get around a part of this problem using toran proxy or a local satis install but in the end the real solution might be if there was more tutorials on how to get the installing part right.

Number 3: i named some better options already

Number 4,5,6: Thats us, all of us who publish packages, work on opensource projects etc. We have to show more responsibility and discipline here – and clean up the chaos we are having right now.

Battle Among The Stars: Day 7

So, this time I guess I don’t have a fancy screenshot to show.

Most of the work on Day 7 was restructuring some more of the Blueprints I had already build (if you read the Day 6 post, you might see that this has become a common theme, which is due to me still learning the language & engine), as well as learning a bit more on how the unreal engine integrates c++, as I have found a few things that I’d like to do that don’t seem possible with Blueprint yet.

Also I seem to have a problem with the Engine not running the construct scripts of my ship-characters in “standalone” mode – while in editor and in a done build it works (so this is mostly just messing up testing for myself).

Besides that I’ve looked into how to do networking, for which I started building a networked pong (no, not going to release that) in the Unreal Engine, just to see how it works.

My next goal for this is to build an Asteroids-Level – basically the first playable release of something, so people who are interested can play (… asteroids), and give me feedback on how the controls work for them. (If you are interested, drop me a comment – it might still be a few weeks till that happens though).

 

not so fancy pong screenshot:

ppnetpong

So, what about Elite Dangerous?

December 2013 – Early Access / Alpha

I started playing with the first release that supported oculus rift – in fact the support for occulus was what got me to ignore common sense and buy the horrendously priced alpha access.

Just to learn that I had come a few days late, and while I paid as much as some quite highlevel backers, i wouldn’t get any of the benefits they where getting. Tough Luck.

However I hadn’t bought the game because of those benefits, I had bought it because I wanted some space game to go with my oculus rift – and, even though there where a few bugs in that first alpha, that only consisted of what today is the tutorial, I really enjoyed it.

Last Year – Alpha / Beta 

During Alpha and the Beta stages the game grew better and better – once there was a set of systems you could travel between it started feeling like the game I wanted it to be – I started having some awesome dog-fights with other players, and grinded through combat zones and navpoints to supply my pew pew habbits.

Last Year – Gamma / Release

When ED was released last year, I was rather disappointed. Shortly before the launch they had messed up the (reward) balancing, so a combat career didn’t seem feasible, and everyone was just playing “Eurotruck Simulator in Space” which I found rather boring.

You wanted to progress to one of the bigger ships? be prepared of hours of hauling goods.  Exploration, Combat, Resource Harvesting? All of them where do-able, but wouldn’t yield enough to get even to the mid-range ships in a reasonable amount of time.

I had spend most of the time in Alpha / Beta grinding to get to one of the bigger ships (and always come just a few hours of gametime short of it before the next wipe), so again being tied to fly Viper or Eagle (the affordable combat ships), or go space trucking, I decided not to play for a while, hoping for Frontier to actually fix the game and make it a “complete experience” – something ED at that time was not.

Today (Easter 2015)

So, what has changed?

Since the last time I’ve played there have been two free “updates” (1.1: Community Goals and 1.2: Wings), which added a hand full of new features to the game – the first adressing the huge outcry by some, after the launch, about the lack of content.

Community Goals are basically Events where players who get to the location, can join to the Event and then do missions (mostly the same stuff as regular missions), that contribute to the Goal of that event – and by that the players can influence the outcome.

Wings is basically adding “grouping” features as known of any other online game – you have a few friends, you want to fly together and have a shared chat channel, share bounties and sensor data? you can now create a Wing and do this.

You might already have guessed from my choice of words that I’m not totally overwhelmed of excitement about those updates. Well first of all – this is features that should have been in the game from the start, and people where telling ’em that, and second, I might still be a bit annoyed by this Interview where David Braben claims to have released a complete game – totally ignoring that those two updates as well as many features and things (complete ship lineup anyone?) spoken about where not in.

I could go on ranting about the rumours of them working on planetary interaction and walking in stations for the paid expansions now, but I’ll save my breath. Lets rather talk about the good things:

They “fixed” the combat reward balance (and I can’t find it in the Patch Notes).

The rewards for shooting pirates, combat bonds etc. it all feels at about the right amount right now. getting your eagle (the lowest tier of combat ship) from bought to fully-pimped is now rather a task for a day or two, and not several weeks anymore. You will still make credits on a slower rate than a trader in an Lakon 9, but at least it will no be completely ridiculous anymore.

Ok, Ok, there are more factors that improve combat gameplay:

A new ship in the combat lineup: The Vulture – priced at (now reachable) 4mio credits a big brother for the Eagle. This moves the gap between “payable ship” and “ridiculous overpriced ship” a bit further away from the new combat pilot, as he now has the option to go from viper (~300k), to vulture rather than the faction ships ( ~20m, + good standing with the faction) or the python (50m).

Also combat gameplay has improved by having the NPC follow a wing-logic too, which means you can now see a bit more on how many NPC will get angry with you and shoot at you if you go for their wing-buddy.

 

So basically those updates have made combat a playable path again, and by that it seems time to play again.

 

TL;DR:

Liked ED in Alpha/Beta, got bored with Euro-Truck-in-Space in Game/Release. Happy that last update made combat playable again, now playing again.

 

PS: I still think the game is incomplete, but FD is doing a good job with their progress on improving the game to the state where it will be complete, even if they don’t admit the incompleteness.

Battle Among The Stars, Day 6

Today I spend time on finally getting the turret rotation to work, and as it turned out I hadn’t really understood the problems that I faced during LD yet – I ended up having rotation wrong again. (It only worked last time i looked at the problem because I had my 2D playingfield in front of me instead of looking from the top at it.)

Now personally i think adding rotational turrets should be something rather easy, and I was a bit annoyed on how long it took me, but I think my excuses are good enough, after all I’m still spending most of the time I work on this figuring out how to use the Unreal Engine, and it shows that the Engine is build to build shooters, most tutorials focus on that, and creating a shooter level is probably easier than to build a game like this from scratch. I might have saved some time using one of the available game templates (two stick shooter), but I figure that would have limited the learning experience.

Anyways, I now have rotating turrets on my ship (it is actually implemented through a blueprint component, something new in UE 4.7), and that are working, and also I implemented a simple zoom in / zoom out control (in the old default distance it was hard to even see the the turrets, so I moved a bit closer (for now) and gave the option to use the mousewheel for zooming in/out. (Not sure how I should provide that for gamepad, probably you’ll need to hold a shift key for that).

Also, i replaced the static ship in the main menu with the same thats being used by the player – which allows for a small turret-rotation animation at the start of the menu.

After that I spend quite some time reorganizing the folders of my project to something a bit less of a mess.

Now, all in all I’m happy with how much I got done, also, at the end of the video there is one more thing I’ve been working on ;)

Also, last friday I showed the previous video to some friends of mine (who are working in game dev), an Martin pointed out something that I’m still thinking about. As you might have noticed, when the ship turns your movement vector won’t change at all, only if you apply thrust it will have effect on the vector. Martin said, that if I fire thrusters to the side, I could make it actually in more of a turning around movement. At that time I thought he meant that I should do the ships rotation by thrusters (which I’m avoiding on purpose at the moment, because that would mean rotation needs counter-thrust to stop, which might make the controls a bit too harsh). Apparently what he meant was, that when the ship goes into a curve, the lateral thrusters (which are not implemented yet, but will come for strafing) could fire, by that helping to change the vector faster.

He actually has a good point there, but I don’t want to automate this behaviour away. Once I’ve implemented it you will be able to manually fire those thrusters, mainly for strafing, but it will allow you to influence the vector as well. The thing is that as with the forward breaking thrusters, those are maneuvering thrusters, and by that they are a lot less powerfull than the main engines, which means that managing rotation and the main engine will still be a more efficient way to control the vector, while the lateral thrusters will be better suited to make small corrections.

This all will get more interesting once the fuel mechanics come into play as well.

Battle Among The Stars, Day 5

So, todays post is rather boring. I spend much more time than I wanted on figuring out how to get a camera which is moveable detached from the pawn controlled by the player.

I wasted a lot of time watching videos on how to use cameras and such, also spend quite some time reading up on answerhub, and in the end I realized, I don’t even need most of the stuff they where talking about (For example: someone suggested using 2 PlayerController instances, so two Pawns, one for the camera and one for the actual pawn can be possessed. Having two player controllers for each player just seemed plain wrong to me).

bats_day_5

So I had a closer look on what i actually need, and for now came up with a very simplistic variant to do camera movement. Probably I’ll iterate over it again once I’ve learned more about UE4 anyways. The good thing about all this is that I finally moved the controlls where they belong – to the PlayerController.

Also, if you ever end up using Unreal Engine 4, and you’ve set a PlayerController through Blueprint Icon on the top, but then end up with the packaged build (or stand alone game) not using that controller: Edit->Project Settings is where you have to set it so it is persistant, apparently the one through the icon is only for the current editor session.. not knowing this almost drove me crazy today.

Small video showing that the camera stuff is actually working:

 

Battle Among The Stars, Day 1 to Day 4

Basically this is a “what happened until now post” as kick-off for the battle among the stars devblog.

If you have me on facebook, you most likely will already have seen the screenshots from the first 4 days, so there won’t be much new in this post. In the future I plan to use this category of my Blog for my Dev-Diary.

 

Why am I doing this?

I didn’t blog about this, but last year in december i tried to take part in the Ludum Dare 31 – and I failed horribly, which is probably why i didn’t blog about it right away.

I failed because

  • i was hungover from the Xmas party of the company i work, which happened on the night before the Ludum Dare
  • I decided to go solo. Now that alone doesn’t make for a fail, as for the Ludum Dare 30 i wen’t solo too, but within such a short time frame this adds a lot of stress
  • I decided to use an engine, which I never used before: the Unreal Engine 4

Now even though I failed, I liked what I saw from the unreal engine during that time. So I decided to go ahead and build a game outside of a GameJam with it.

 

what is this game going to be like?

at this time I don’t want to go too much into detail, so I’ll just throw a few keywords out there:

Online, Multiplayer, 3D, top down, Spaceships, Shooting, Tactics, Resource Management, PvP.

what happend so far

Day 1 (February 1, 2015)

On day one I mostly spend my time learning a few more of the basics on how to work with UE4, as well as creating a first pretty rough frame for the game. At that time I hadn’t made a decision on using 3D graphics yet, I was spinning around the idea to use 2D graphics, but particles in 3d space for effects and such.

At the end of Day 1 I had a running application, which would display (and allow to move) a simple 2D ship actor.

bats_day_1

 

Day 2 (February 8, 2015)

On Day 2 I made two decisions:

  1. after trying out a few things the 2D + 3D effects thing turned out to be more trouble than fun, so its gone, I’m using proper 3D Models now
  2. While i can build a simple Model of a Spaceship, I’m no 3D artist, also I seem to be completely unable to come up with cool Textures. Also asset creation costs me a lot of time that I actually would prefer spending with things that I enjoy. So i bought a pack of simple Ship Models – for now they are good enough, and i expect to replace them at *some* point.

Besides toying around, and getting to those two conclusions I set myself to build a menu screen for the game.

bats_day_2

once I was happy with that, I actually created a git repository, as I reached the point where I didn’t want to start over again, if something goes wrong.

As long as I work alone on this, there won’t be much of a problem with git, but i learned that UE4 saves blueprints in a binary format, which has the downside that git won’t be able to do merges, and conflicts are solved by throwing away the changes of one of the two contributors. But I decided not to care about that for now, as I’m flying solo on this one.

Day 3 (February 14, 2015)

on day 3 I finally started making some good progress, i created the actual test-map that I’m using to try out the things that I’m building and then build a Ship actor, which is now moved around by applying thrust. Once that was working, I spend some time creating a particle system for the thrusters, which will give a nice visual indication of which thrusters are active.

However I cheated:

  • I was only using one thruster for forward/backward movement, by having the thruster (mounted at the rear of the actor) apply negative thrust for when the braking/forward-mounted thrusters should fire.
  • rotation is not done by thrusters yet – and I’m uncertain on if I will change this at some point. building it is easy enough, but controlling it might be rather annoying for the player (to stop your rotation you would need to apply counter thrust, so most players would at least keep a small amount of rotation constantly going)

At this stage I remembered something from last years global gamejam, where my team build a space-ship game aswell: If you don’t have a visual indicator on where your ship is going, then navigating (and stopping) gets quite hard. So I created a similar solution what we did back then, and added a direction guide.

At the end of day 3 I was quite happy with what i had achieved, and then I looked at my blueprint, which gave me the feeling of creating a big mess – the logic I had created shouldn’t be attached to the ship, and it seemed quite chaotic.

bats_day_3b

 

Day 4 (February 21, 2015)

Today I spend most of the time refactoring what I did during the other days, to get less chaos and a better basis for building upon.

I also removed one of the two cheats from Day 2, the braking-thrusters are now actually backed by an own physics thruster. Also the weight of the ship, and the amount of thrust applied by the thrusters is now much more realistic (than the 60kg that the ship had before ;).

However the screenshot of today is probably rather boring, as it simpy shows the refactored blueprint of what was a big mess in Day 3.

bats_day_4