Hitman 2016 – Colorado – Shittiest Episode Ever

I simply hated this one. The dreary level design was complemented by excessive numbers of guards that were no fun to subdue. I played it once and have never been back. I won’t even do the bookkeeper, because he’s there. The thing I didn’t like was the big reveal at the end of Colorado. Surprise: It’s his clone/brother/best friend trope who somehow magically took a different path and is all knowing, all seeing, and able to orchestrate the whole shebang. If it doesn’t turn out that there’s someone behind him I’ll be greatly disappointed. To be fair, this level of writing (B Movie Quality) is Oscar worthy in a game.

The dialogue and plot, for a game, is absolutely off the charts. Nevertheless, it would have been nice for them not to go “World Conspiracy”, it’s hard to find anywhere to go after that, except space aliens. Come to think of it, Agent 47, cryogenically frozen for hundreds of years, only to wake up in a highly technical future with space aliens? Fuck – I should write this down.

Posted in Game Reviews, Uncategorized | Leave a comment

Hitman 2016 – Sapienza


At first I didn’t like Sapienza as a level, it seemed on one hand too easy to kill and on the other too difficult to find anything. As long as you followed the simple assisted assassination plan everything went smoothly, but any deviation left you unsure how to proceed. The main issue I have is the dongle. It takes ages to get it, and destroying the virus any other way is difficult, or at least I’ve never managed it. The trick with Sapienza: You have to put in the time learning the level. Only when you have complete mastery of the town, mansion, and underground facility will unique opportunities show up. There are many ways to kill your targets. One obvious way is to give De Santis the DNA sample and then run up to the attic and drop a propane tank down the floo, but a less obvious one is to carry the propane tank down to her office and shoot it while she’s at her desk.

What I particularly loved about Sapienza were the opportunities of Silent Assassin. There are tons of non-standard ways to kill your targets, silently. Getting them alone is easy. Silvio with the tape, and De Santis with the golf pro.

The universal down side of Hitman 2016 is the time it takes. Get ready to spend hours playing this game. It really becomes addictive. Once you’re done with targets, you can move on to Escalations, or just plain Contracts. Sapienza has one of the most difficult to engineer escalations, the Lyndon Gyration, but once you grok the trick (involving a wrench and oil leaks), it becomes a walk in the park, but one that takes ages on account of extremely long NPC loops.

Posted in Game Reviews | Leave a comment

Hetzner.de CERT-Bund Abuse Warning, NetBIOS Nameservice – How to turn it off

You may have been the happy recipient of this warning from Hetzner: “We have received a security alert from the German Federal Office for Information Security (BSI).” In which case, you most likely have samba running, and need to turn it off:

try: service samba stop

To make it permanent, open up /etc/init.d/samba and put exit 0; after the shebang line.


Posted in Linux, Tutorials | Leave a comment

Game Designing

So Game Design and Programming has been something that has interested me for sometime now. One of my most popular articles was written years ago when I toyed with the idea of writing games in AS3/Flash. Flash was an interesting platform, but for some reason it really only lent itself to games that looked like flash games. The workaday world pulled me away and for awhile I was mostly engaged in Enterprise Integration. Then I got hired by a games company in Los Angeles and thought I would end up pursuing game programming, but then they switched from doing a classic MMORPG in C++ to doing facebook games in PHP, which is not at all very interesting.

Fast forward a few years and I decided to give Unity a shot, but I just couldn’t make any headway. The whole system was designed, from the bottom up, to be a bit of closed box. You basically had to have a Ph. D in Unity to be able to get anything other than the most basic side scroller rigged up. I also hated that they changed the API and system from release to release, so older tutorials just wouldn’t work with the latest platform. I firmly believe that an API is a promise, and people should be able to stick to a certain API for the life of their product. If they’re going to commit to using your platform, then you have an obligation to make sure old stuff works with no, or as few as possible, changes.

In the case with Unity, I want to make a game where the main character can swing off certain nodes in the environment, suffice it to say such a game is easy enough to make in Unity, just not make well. You need some extra bits of information. I think during the swing my character would suddenly jump to weird x,y coordinates or something. I asked around on some boards, and got stock game and player setup suggestions, but none of them panned out.

One thing I can tell you about frameworks and platform development kits, is they have a tendency to kill your programming desire when you hit a brick wall. One you can’t code around because the system insulates you from the naughty bits of the implementation. When it all comes down to finding the right checkbox (checkboxes randomly move in every Unity release), not being able to find it ends the adventure.

I then messed around a bit with SDL 1.2, and embedded a scheme interpreter and had a working game with sprites and everything, but then my personal life blew up and I abandoned it. After awhile I thought about dusting it off, but decided that I needed to move to SDL2, and that Scheme was a scary language for other people, and I wanted whatever I did to be useful to others, I started writing a new game framework in C, with Lua 5.1 (LuaJIT) embedded. I wanted it to be an incredibly thin wrapper around SDL at the lowest level, with users (namely me), being able to code right on top of the C layer if need be, otherwise, logic written in Lua would suffice.

The plan is to make it open source, at the very least as a study of how to games in C, how to embed Lua 5.1 and how to implement various game ideas.

Here is a sample of what a fully functioning SDL program looks like:

That’s just an example, but so far the framework features support for most of SDL Events, GameControllers (Haptic feedback doesn’t “Work” but SDL thinks it does, so maybe it’s my controller) but it has an API for Rumbling and Sine-ing the controller. It only supports .bmp (cause it’s lossless, and really, do you need everything else? I might add PNG support), and all of the sprites use SDL_Texture on the backend, even though the API looks very SDL 1.2, it’s actually SDL2. I intend to add in more support for raw SDL_* functions, and might even make it possible to micromanage SDL_Textures. The framework is currently made specifically for indy 2d games.

Breaking Down Game Development

I think so many people have developing games all backwards. The most important thing is to build the tools to build the game. How do you compose complex game objects? How do you load up predefined game objects? How do you define levels? How do you load those levels? How do you save and restore game state? How do you setup Audio and Controllers? How do you save and load user configurations? How do you create interactive menus? All of these things are what separate dinky “I made this with {insert-game-framework}” games from a fine tuned finished game product that’s actually worth money.

Most people get all hot and bothered by the “Game Engine” and the “Physics Engine”, but really most games only use basic physics and rigid body dynamics. Your character runs, jumps, and falls off cliffs. That hardly needs a physics engine. 3d physics a bit different. But we aren’t really talking 3d games here.

The Rendering Engine

How exactly do you decide what gets shown on the screen, and where? The rendering engine is incredibly important, it needs to be easy to use and flexible, but it also has to be fast because even in a simple game we could conceivably have hundreds or thousands of moving objects to render each frame. The more detailed and ‘alive’ your environment, the more ‘rendering’ will have to take place. Here rendering doesn’t mean just drawing, it means deciding how and what to draw. Everything on a computer takes time, so all the calculation can add up.

Some things to consider with a rendering engine is Composite and grouped objects, Relative positions (this child should be parent:x + x), and z Index. Yes, even in 2d games, to give a better illusion of depth, some things should have a differen z-order.

Currently, here’s the basic code for rendering that my system uses, it doesn’t yet take into account Frame Offsets (in reality players don’t move left and right, the world moves around them) but it gives you a general idea of a ‘render graph’ or ‘render tree’ and how it’s done.

Widgets with interaction

Drawing characters to the screen is easy, in fact, controlling your character is the least problematic part of your game, one thing that few people think about is basic interactive elements, like buttons, text inputs and sliders. What about scrollable windows?

Having these tools to hand makes building levels and gameobjects via a handy interface so much easier. But this basically means you need to write your own GUI toolkit library, which is what I am currently working on. So far basic interactive widgets are working and rendering, so some example code is forthcoming.

Posted in Computer Science | Tagged | Leave a comment