Doing what i like

I suck at blogging.
It's fact. I'm lazy, and i rather spend time playing a game, or trying to come up with a solution to a problem for my own games. I'm not sure what I'd need to do to really get into the mindset of writing something every so often. I guess my first idea when i started was to write about progress in making a game, but that stops every time i take a break from it, either because I'm dealing with a hard to solve problem, or I'm not making enough visual progress to show, or a new game came out on Steam that I'm obsessed with for a month of two.

So this is my attempt to write a progress report. After several months of nothing. We'll see if it continues. :D

So, the game I'm working on right now is a Crimsonland type game, a top-down shooter. I decided to make my own version because of a few issues the original game has, where the second player was gimped because some perks weren't working for him (like [greater] regeneration, which would have been a life saver for player2, if it worked).

Crimsonland was a very serious game, containing real blood (if you count on red pixels representing realism), aliens, spiders, zombies and similar serious-ish things. I decided to make a not-serious version, where you'll be fighting fairies, unicorns, flowers and similar not-serious creatures that drop rainbow colored blood. The idea is to make a game that doesn't take itself seriously. So i named it Rainbowland.

So the way i started was basically with what any programmer would start with: I drew rectangles. I gave the rectangles some numbers. I made lines. The goal was to try and make the base of the game as quickly as possible, and within a few days, i had this:

Good enough progress. Then i started adding more stuff, like orientation, and the best way to see where everything was oriented towards was to make everything a circle. And give them a nose.

I also added some powerups in the form of collectible rectangles, which also had numbers in them so i can see how long they last. Progress was pretty good.
I decided i wanted to separate this game from Crimsonland as much as i can, all the while keeping the basic gameplay there. The perk system will stay, 4 player single screen multiplayer will be there, pickup powerups will be there, weapon drops will be there, so how do i differentiate it from Crimsonland?

Character classes. Totally best idea ever.

On a more serious note, i decided to add classes purely because i wanted to give the players more tactical options when fighting the endless waves of flowers and unicorns. And because i think it might be fun to try adding them :D

So after a while, i decide I'm sick and tired of looking at the grey background, and the circles with the noses, and i decide to put some test graphics in. A friend showed me a site with textures, CGTextures, so i hop there, find the most normal looking texture of grass (i ended using a texture with moss, but grass, moss, what's the difference, right?), and put it in.
Then i hop onto google and search for "top-down shooter guy". Not the best search keywords, but i have no idea how to look for this stuff. Finally i find a couple of great looking sci-fi shooter guys on opengameart.org, plop it in the game, and voila, I'm no longer looking at a red circle shooting black circles on a grey background. This almost looks like a game :O

So that's what I've been up to. I've given myself a deadline of sort, within which i hope to make the rest of the basic stuff to be able to show the game publicly in a student club where i was a member during my student days. The idea is to add as much stuff to make this a sort-of good alpha version, and then use the public test to work out the installation bugs, and have some multiplayer testing, and getting as much feedback as i can.

I made a list of stuff that i want to do by then, sorted by priority.

• Monster AI: the monster just move towards a random player at a constant speed, which is boring.
• Sounds: what's a game without sounds? No music, but just general sfx is the goal for now.
• Proper multiple players support: I can have two players in, but most of the game is hard coded against a single player being in, so i have to make some changes in the code to have controls and events reference the correct player, in case one of them dies.
• Perk chooser for MP: right now only one player gets to choose perks for himself, and the goal is to have each player choose his own perks on level up.
• Aim reticule for gamepad players: only the keyboard+mouse player has a aim indication, which is the position of the mouse itself, so this is something i definitely need asap.
• Blast damage type: right now i only have bullets, so i need to add AoE damage types.
• Weapon types: only physical bullet weapons now, so i have to add different graphics for different bullets/weapon types.
• Monster types: I only have one type of monsters, which is something i want to change.
• Drop mechanics: right now all the drops are random between bonuses and weapons, and i want to change it so there's only <num_players> weapons on the ground at any given time, with a minimum amount of time between weapon drops. Similar for bonuses.
• Key bindings: kind of part of the proper multiple players support, i want to be able to change keys used for various actions.
• Menus: right now i just pop into the main gameplay thing, and for this deadline i want to at least make a bad looking main menu, class chooser and player count setup.
• Difficulty scaling over time: monsters are easier at the beginning of the round, and get harder and harder as time passes, the players gain experience, and level up.
• Boss fights: there's gonna be a HAM in the game. (huge ass monster)
• Tweak leveling progression: have to decide on the leveling speed, make a formula for next_level_experience_requirement.
• The rest of my list is adding more perks, weapons, monsters, skills, bonuses, and a proper GUI for gameplay.

So.... a ton of stuff to work on. I've got around 3 weeks to do this. I hope i can manage.

I'll hopefully write another post after the deadline passes, to make my success or failure be written in history.

Developing a game: Harold the Hedgehog

Harold the Hedgehog

No, his name is not really Harold, but for the purposes of this post/blog, i'll refer to him as Harold.

This is Harold.

He came to exist some time in 2014. i think, created by his artistically talented mother.

This is also Harold.

Harold is walking in this photo of him. He's really photogenic.

Harold also knows how to jump.

You might ask yourself, why i am telling you things about Harold.
You see, Harold is currently the main actor in a game, and is therefore receiving some media coverage, being a young star and all.
It's really hard, the life of Harold the hedgehog. The gravity of his world is sometimes very strange, which causes problems for Harold.
You see, he is, unfortunately, scared of heights, which makes him all twitchy.

This is Harold's little abode. Forgive the crude look of the trees, they were made by Harold's artistically retarded father.

He passes his time by collecting apples from the trees using his inexplicable ability to jump one more time in midair. He says it's a gift from his dad.
He has infinitely deep pockets, so he just keeps track of the number of collected apples.

"Collected" apples.

Technicalities

The majority of the current "game" is written entirely in Lua scripts.
The core is written in C++, the bigger parts being the graphics system (using DX11), animation system, the windowing system which includes input support, and the core game definitions.

The Lua scripts contain code for the animation state machine, which helps Harold transition from sitting on his ass into moving and then jumping and back. They contain the entire movement code, to make him go left and right, which is tied to reading the keyboard inputs to make all that happen in the first place. There's also a basic output console for debugging purposes.

I also made a small objective to collect 10 apples as fast as possible, with a timer that records and shows the best time.

The most helpful feature in the entire code base is definitely the fact i can change resource files (scripts, textures, shaders, data definitions, etc) while the game is running, and upon saving said files, the game picks up on the change, and promptly reloads them, which makes the rest of the code use the changed data.

This has helped me make, test and debug the code for collision detection so Harold can collect his apples properly, and tune the strength of gravity and the strength of his jump. It also helped fix some spacing problems with the font, and i expect it to be very useful in the future when i start coding some real behaviour Harold will be expected to exhibit.

A word from the author

I'll be keeping track of the progress about Harold as time goes by. The format of this blog post seems fun for now, so expect to see more similar posts.
Stay tuned!

The long overdue post

As the title says, this post is long overdue.
Several years overdue, to be perfectly honest, but i was stupid and overly confident. So let's say that i should have written this a month ago, when i actually realized what i've gotten myself into.

My grand idea of making an engine that would cater to my every need before i needed or even knew what i'd need is just dumb. I'm just one man working on this, and here i was, dreaming i could make a simple engine that could make any game, without making a game. Such contradiction. Much dumb.

So after a smallish amount of time (around 5 years) i finally dropped the engine project.
It's for the best, really. I was too focused on making an overly complex system for making entities without actually using it in any meaningful way. The component based entity systems are great, and i definitely see myself doing them at one point, but not now.
Not for simple games.
Not for games that have only 4 unique objects on the screen.
Not for games that are so simple that it takes one source code file to write them (802 lines long and written absolutely horrible, but still...).

So now i'm making games instead, and letting an engine grow from them. I'm not running in blindly though, the last 5 years have been extremely helpful, as i've learned a lot to help me make the right decisions about the structure of code. I made Pong from scratch using this knowledge, and scraping bits and pieces of my previous code so wouldn't have to write it again, and i've done it in a month, laying down the foundation for any next game.

I made a simple graphics system which allows me to draw lines, color filled or textured rectangles, and the latter also helped to make a simple font engine (Direct3D11 API doesn't have a premade easy-to-use font drawing capabilities, which sucks big time).
I made a simple windowing system, which also has the capability to monitor a certain directory for any file changes, and promptly notifies the game in such an event, so for instance, assets (textures, sounds, models, etc) can be reloaded while the game is running.
I made a simple scripting interface around Lua, and used toLua++ library to automatically generate bindings so i don't have to write them manually (it gets really tedious). I used the scripting interface to implement the AI for the right paddle, which was really fun, finding the right logic to make it track the ball in a non-twitchy way.
I added the Box2D physics library to make my life easier.

All in all, a lot of stuff is now there to help making the next game much easier and faster. I still have one thing to add to Pong, which is sounds, but that's almost a no-brainer since i already have FMod downloaded and ready to go, i just need to give it a home somewhere in my code.

That's all for now. I'll try getting back to weekly posts again, to help track progress, which should now be more... obvious?

Components and Actions

In my last post, i talked about implementing the input system. Apparently, i it's much more work than i thought. However, i now have a working input system, which works as expected.

The whole system is implemented using several concepts: a device, which maps OS events into an Event structure, a key binding system, which maps an Event structure into an Intent structure, and the IntentSystem, which acts like a message dispatcher for Intents, which is poll based (hey mr. intent system, do you by any chance have a JUMP intent that i could use?).
At the top of the food chain, there's an IntentHandler action, which can have any number of entities registered into it, and they are set as targets of every output Intent. Then, at least one other action will poll for each Intent, and execute some logic for it.

Sounds pretty simple, but took me over a month to finally implement it. Though, to be fair, i was returning from my business trip from Sweden, had a 5k puzzle to finish, see a bunch of people, and was kinda lazy. :)

My next step is going to be designing the actions so they have clearly defined inputs and outputs as far as components are concerned. For instance, right now i'm thinking about how to make the physics simulation Box2D gives me work together with the components. An obvious one is that the output of the Physics2d action is the new position after Box2D has updated all bodies. The position is later used by the Render action to draw sprites at the right places on the screen. However, i'm discussing with myself (who else) about what  should be the input components. The input components should contain data required by the action to do its per frame update logic. Something like, in the case of Physics2d, read the Velocity2d component, and give the body a push in the right direction so that after the simulation, the velocity of the body within Box2D is the same as the one in the Velocity2d component. This is easily done by using impulses every frame, the faster the body is going, the smaller the impulse strength needs to be. Also, acceleration is done by providing the body with a force. If i'd want the body to have a specific acceleration, the formula given in physics classes is F=m*a, so i would just multiply the wanted acceleration with the body mass, and apply the given force to the body each frame.

The same goes for pretty much all actions, but the Physics2d is the most interesting one because a lot of the game depends on the simulation (collision detection and response being the biggest factor), so i need to be careful here.
Also, i think i'm gonna need a better way of handling intents, as right now each intent needs to be handled in three ways, either as a one time action (jumping, opening doors), a continuous action (running left, shooting an automatic weapon) or a range based action (moving the mouse around the screen, panning the camera). Any of these three actions could in theory be applied to any intent, like moving the entity based on the range a mouse movement causes, or having a jump that peeks only after you've held down your button for 2 seconds, making you able to do small jumps or large jumps.

Hope i'll make it for next weeks post. :)

The Input System

Two weeks went by without a post, and i've been busy.

I've been busy playing Borderlands 2, and brainstorming and implementing my Input System.

I've been thinking on how to implement this system in a way to allow more than two types of devices (mouse and keyboard). There was a good question somewhere on the web that made me think about this: "What if i decided to support a gamepad? How would that change my code?"

So i set to work, and after some google-fu sessions decided on the following approach.

I changed the code a bit to allow the Window to accept listeners which want to listen to all OS messages. Then i registered my InputEngine to the Window, so it gets the messages.

When a message is received, this invokes handle() on the InputEngine, which in turn calls handle() for every device that has been created.

The devices are a way to translate the OS specific messages to my own, device specific, events. MouseDevice, KeyboardDevice, GamepadDevice, TouchscreenDevice, etc, are very platform specific in how they work. Each device has a chance to translate the OS message to a specific event, and in theory, only one device should be able to do that. If the event is successfully mapped, the event is stored in an event queue for later use.

So now that i have a sequence of device specific events, i need to translate them to game specific events. Think of this as "When the user presses <some key>, his character should run forward". So basically, i need to translate the device specific event into an intent (which in this case would be a RUN intent). When it's time to handle input in the game loop, the InputEngine goes through all of the device specific events, and gives them to a context dependent intent generator (name taken from this SO thread).

The intent generator is a sequence of sets of functions that try to map the events to intents, with a specific priority. For instance, in Assassins Creed games, when the player presses and holds the right mouse button, the context changes so all of the buttons map to High Profile actions. When RMB is let go, the context is popped off, and the buttons map back to low profile actions.

So when all device events are processed, the result is a list/sequence of intents (if there was anything mapped to those device specific events) which is returned to the Input Action (my whole engine is based on these actions). The Input Action then traverses all entities that are marked as input controllable, and gives them a chance to execute every intent. If any entity is not capable of executing some intent, it simply doesn't, and the loop goes on.

So this is my input system. I still haven't fully implemented it (i'm currently working on the intent generator), and it took me a while to reach a consensus with myself on how to do it. I tried a couple of different approaches, but they weren't as flexible and/or layered as this one.

Polishing my Pong

It's been a while since my last post. I took a week off to spend time with a friend who came to visit me for a week here in Stockholm, which should explain the absence of my standard monday post. But it felt good to take a week off from work after work. :)

But now i'm here, and i can show the progress i've made 2 weeks ago.
The first piece of progress has been my finalization of the Entity Component System. It probably has places which could be made better (and i have an idea on how), but that will have to wait for a later time. I need to see how much i can do with the current implementation before i start pushing changes. Again. :)

In my previous post, i talked about the small-ish problem of having no control over the destruction of more complex data the Entity holds. I solved it by registering a callback to my Entity Pool class which is invoked on destruction of an Entity instance, and which then seeks the complex data and does it's magic. Using this concept, i made the Physics logic class register the appropriate lambda to the pool, so everything is cleaned up properly.

Then i started doing some work on actually getting Pong to a playable state. I haven't finished with that, but i have managed to get the foundation for it set up.

Right now, the paddles are there, the ball is set with a starting impulse in a specific direction, and the walls and goals are there. There's more work to be done here, and thankfully, i'm able to make a TODO list of what's left:
1. get input working so the paddles can be moved up and down
2. set up a random direction for the ball when it starts moving from the center of the field
3. get collision working between the paddles and the walls
4. make the goals sensors, which reset the ball back to the center of the screen, and increase the score
5. get the ball to bounce with a bigger angle when it hits the sides of the paddle
6. add awesome smashing next-gen graphics which will make this sell a ton of copies
7. add GUI element for score
8. make the ball increase it's speed with one of two possibilities:
8.a. as a function of time
8.b. as a function of the number of times it collided with anything

Most of these should be self-explanatory, but number 3. bears (rawr) a bit more explanation.
The way Box2D is setup, there are 3 types of objects: static (cannot move), dynamic (move and collide with everything) and kinematic (exactly like static, but can move). In order to detect a collision, at least one of the bodies needs to be a dynamic body. The above screenshot has the paddles as kinematic bodies, however, in my first setup, the paddles were also dynamic bodies, and when the ball hit a paddle, the paddle would suddenly fly away because of the collision, which is funny to see.

You can see the left paddle down in the corner, and the right paddle being hit and having collision way off.
One way i could solve this is by having the ball density really low, and the paddle density really high. That way the paddles will be almost immune to any forces being applied as a result of the collision, and the ball will behave as expected. And now, after putting this on paper, it seems as a very obvious solution, which i'll implement. :)

And that's it for this week. Tune in next monday to (hopefully) see a finished Pong game in my framework. :)

Thanks for reading.

Let there be collision!

I had a lot of fun last week, and not just by getting drunk on friday.

It took me a bit more time than i would have liked, but i managed to get my physics and collision library (Box2D) to draw it's debug data to the screen.

To do so i hacked up a small class called Polygon, which has a couple of parameters to control whether the polygon is solid or not (aka, filled or just the outlines), it's color and a few others, and to set up its shape. For now i implemented functions to make it a square, ellipse, circle (which is a special case of an ellipse), line and a triangle, plus the extra function to pass in your own data about the shape (so you could make any shape you wanted).
This is my first class that is able to draw itself on the screen, and i used it to draw all of the shapes that Box2D is able to draw.

Box2D is (as its name implies) a 2D library for physics and collision. There are a bunch of other libraries out there to handle just that, but this one seemed easy enough to learn, and i didn't want to spend too much time researching different physics libraries and comparing them.

Box2D works by first making an instance of a b2World object (it's, well, the world where box2d bodies live in), and asking it to create bodies. When a body is created, you tell it to create a fixture, which is something that gives the body a shape and physical properties like mass, velocity etc. And if you want to kill a body, you have to give it back to the world, so it knows which of the many possible bodies to kill. More on this a bit later.

Then on each game update you tell the world to simulate by solving movement and collisions.

The result is something like this:

This is super simple for now, it's just two boxes, one of them being a static body, the other one dynamic (can you guess which is which?). What this opens up now is the ability to at least get something more interesting done, and having it draw on the screen.

My next step is to finish off my Entity structure, so when entities die, they are cleaned up properly. This is a small problem for me right now, because of the way i setup my entities.

My Entity class is more or less just a container of States, where a state is any set of variables grouped together in a logical manner. For instance, there might be a state which holds the amount of gold, silver and copper a person has, or it might be a simple flag on whether the person can do a double jump. The problem lies in the way states are destroyed. The entity knows absolutely nothing about the states it contains, because they are (for the sake of simplicity) just unique IDs.
Since an entity has absolutely no idea about what states it has, it becomes a problem when they are destroyed. I wanted to keep them simple, to i made them hold just the data they should have, and removed any piece of logic from them.
So how do you delete a state which holds a box2d body? If you don't return the body to b2World, it just stays in there forever, because nobody knows it exists anymore (except the world, but it doesn't decide when to destroy the bodies unless it's dying as well).

The first solution i'm going to try out will be callbacks on entity destruction, by using lambdas.
A lambda is a concept from functional languages, which is basically an anonymous function which does some work, and it's results can be passed to other lambdas, etc. By using a lamed for the callbacks, i can register a function to happen in case an entity is deleted, and it will auto-magically return the body to the b2World (if the body exists on the entity being destroyed).