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?

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).

My cubicle...

Last week was a good week.

After some (well, a lot of) reading, i decided i'd go from D3D9 API to D3D11 API.
The decision is based on three things:
1. D3D11 APIs are cleaner and feel better designed.
2. D3D11 has ways to run on all hardware types (even those that don't support D3D11 features) by using feature levels.
3. The number of XP users that play games should be non-existent by the time a make a game that i'd want to sell.

So with that in mind, i decided to try my luck in D3D11 programming. I found a couple of web sites that have good explanations of the code they give in their tutorials, and have been following them to understand why something is used the way it is. So far so good.

In particular, the things i want to learn are:
- using vertex and index buffers ......... DONE
- using and writing shaders ......... half way there
- texture mapping ......... need to understand it a bit more
- alpha blending and transparency ......... TODO
- orthogonal projection ......... know the principle, but have yet to use it

As you can see, some things are easier than others. =D

Using vertex and index buffers differs slightly from D3D9 in the way they are created, and the method name for locking their GPU memory so you can copy your data into it, but the principles behind it are still valid. Same goes for index buffers. The difference between D3D9 and 11 is that in D3D11, all types of buffers are created in the exact same way with the exact same method, the only thing you change are the parameters of the struct that is passed to the method.

One change that i did not expect in the transfer was the need to write my own shaders, which is not optional. There are ten stages in the D3D11 graphics pipeline as can be seen on this page of the tutorial i'm reading (scroll down a small bit), and half of them are programmable by the user, and the other half is configurable by setting certain flags or values. The part that surprised me was the fact that if you don't write two of those five programmable shaders, you don't get any output on the screen (namely, the vertex and pixel shaders). Coming from D3D9 where you'd just shove vertex data to the GPU and it would render them on its own, this came as a bit of a shock at first, but later i figured how much flexible this system actually was. You get to control how things get done, like outputting the entire scene in grey scale instead of color =D

Going forward, the texture mapping seems a bit more complicated than what i thought it would be. It requires much more control than i thought it would, but (hopefully) most of it i related to just loading the texture. I still have some reading to do on how it actually works, and i need to try cutting out parts of the code down to see what are the bare essentials to get it done. I did, however, manage to get it working by setting the texture of my long lived test subject to my spinning cubes.

The orthogonal projection (aka, viewing the scene in 2D instead of perspective 3D) is a matter of calling the right function to set the projection matrix for the camera, so it shouldn't be much work (seeing as i already have the data i need to set the perspective projection).

Alpha blending and transparency is my next step, so by next week i should have it well under my belt. :)

Finally, to show that i am making some progress with it, here's a video which should explain the title of the post. The center cube is enlarged by a factor of 1.5 on all sides, and made to rotate on the Y and Z axis, while the outer cube is set to rotate around the Y in one direction, then translated away from the center (where the first cube is), then set to rotate in the other direction on the Y axis. Anyway, the video speaks more than words or pictures, so enjoy.