Sunday, February 28, 2010

Progress on the Cricket game [post nr 3]

Hello! Long time no see, eh?
In the last few days I've been concentrating more on the artsy side of me, this was fortified with Chiustream. "What is chiustream?" You may ask. Well, chiustream is a video stream every friday at 22:00 GMT created by the awesome artist Bobby Chiu.
For those that don't know who he is: he was one of the three character designers on Alice in the Wonderland directed by Tim Burton, along with Kei Acedera and Michael Kusche. The stream is basically a 1 hour contest at the beginning of which Bobby Chiu gives a theme and you must draw it.

But enough about art, you're here for my game updates right?.... right?

So in the last post I wrote that I've already finished all the three things planned for this update: Camera scrolling, Particle effects when you sing and allowing walls that won't let you grip them, From that time I didn't do much more as I've been busy with art practice.
Anyway, here's a screen of the latest build:

As usual here's the update of my game:
Of course you must have all the previous updates downloaded which you can download here:
and here:
Yes, you do have to download them all and extract to the same folder, remember to extract them in the reverse order of appearance. Sorry for this inconvenience but I don't want to waste too much Benhem's space.

That's all for today, I hope you liked this update, I'm off!

Thursday, February 25, 2010

Artsy fartsy

Hello! As promised This post will be about my experiments with the art style for my game. Even though I did already draw and paint my main character and I do plan to keep him a bit cartoonish, that drawing isn't his final design. My main concern right now isn't about the design of the character but the art style in general. My Achilles Heel are the backgrounds and level art so before I do anything about the characters I'll try to find a fitting style for the levels themselves.
Here are some of my most recent takes on the level pieces:

My first try:

This one in practically the same style but added a bit of soft shadows:

In this one I tried a bit different way of doing the dirt on top, I also decided to not add the soft shadows made by blurring near the edges. This one is one of my favourite styles so far.

This one started interesting but the turned kinda crap. I wanted to elaborate on the previous one by making the dirt look like some kind of dense liquid, but later I wrecked it with badly placed blur shadows and adding an unnecessary texture.

The following two are in completely distinct style I tried just to see how it would work.
In fact these are my favorites.
The problem lies withe the fact that I don't know if they fit the general game theme. As these simple styles are good to show an ambient devoid of humans meanwhile I'll have to make quite a few levels dealing with machinery,human houses and rockets and shit.

In the last one I especially like how the layering worked out, I think it's gonna be quite easy to add this to my engine but still I'll have to elaborate on them and see if I can fit in the machinery and human made products into that style. Still The kind of gameplay the first one shows is calm and friendly, meanwhile I'm hoping for a bit of action mixed with puzzles and platforming.

I would like to hear input from all of you who are reading this blog. Anyone can comment, no signup or capcha needed.

Hope you liked this post, the next one will be a progress update as I completed all the stuff I promissed in the last update post (camera scrolling, walls you can't latch onto and particle notes when you sing).

I'll see you tomorrow!

Tuesday, February 23, 2010

No net no updates

Yeah, pretty much what the title says. I've been without net for the last few days at my condo and no one apparently is doing anything to fix this.
I have some nice things going on right now when it comes to my game. First I finally thought of a map saving and loading format that is easy to read by eye and modify (it's a xml looking type thingy, with objects and arrays and whatnots).
I've been also experimenting a bit with the art style for my game, it's actually pretty difficult to come up with something that isn't a complete ripoff either of World of Goo deliciousness or Patapon simplicity. I don't really have my style that I'm happy with so I'm reduced to using other peoples styles and experimenting with them. Unfortunately I don't have the artistic skill and training in making backgrounds/level art to actually make something that looks good and this means I'm gonna have to make a lot of drawings/paintings in photoshop or inkscape before I'll do some actual in-game art.
I'm gonna post some of the experimental art here and check the reactions it gets. This means this blog's gonna be updated with random blurts of art and only occasionally with actual new game mechanics, at least until I figure a good art style.

...ok, I'm gonna stop rambling now

Thursday, February 18, 2010

Progress on the Cricket game [post nr 2]

So things are going quite faster than I expected them to do. It's a shame I'll have to put the my cricket game aside for the miniLD this weekend.

Anyway, here's what's new:
I finally added jumping, proper jumping with raytracing to make sure you don't fly off the map no matter how fast you go (although you can still get pushed outside with the normal collision tests I make after the movement has been done. I'm still indecisive whether I should add walking/scurrying into my game for the player since if I did that for normal ground walking I would also have to do it for wallwalking/ceilwalking and it would be a hassle. So far you can still move a little, but if you want to travel it's mostly by jumping.

Here's a new screen:
Those blue things at the edges are walls I have added so you wouldn't fall off if you miss a jump.
I also finally disabled the rotating background! It was giving me headaches when testing.

Having made a lineart concept from the "I'm probably not meant to be a game designer" post I decided to color it. It might sound simple but being Deuteranope (I have shifted green spectrum a bit) I usually use weird looking color combinations when dealing with green, so I decided to try something crafty:
Paint the little guy in blue, setting appropriate hues and saturations and all that jazz,and then change the hue to green. It definitely looks a lot better than if I did it with green right away (at least to me), so here's a little tip for all you deuteranopes out there: Paint in the color you're comfortable first and only then change the hue to the color you have shifted! (however unless I get a confirmation from a person without shifted spectrums I can't put my money where my mouth is).

Anyway! Here's the final version of the main character:

Of course this wouldn't be much of a progress post if I didn't give you an updated version of my game to try out the new jumping feature so here it is:
It's only the exe without the DLL's but to save on Benhem's storage space I decided it would be best to only give updates instead of the full thing every time.
You can get the previous working version here:
And then just put the exe inside there

The controls:
Space- to show the sing menu/GUI and mouse over the circles to sing.
WSAD- for additional control in flight
AD-to walk on the floor (or on the ceiling in this version)
RMB- hold longer to jump faster release to jump

My plans for the next update:
-add a little particle effect of notes when singing
-add camera scrolling to follow the player and thus make the world bigger
-add walls/solids you can't latch yourself onto

So this is it! I hope I didn't bore you,and see you next time!

Wednesday, February 17, 2010

Progress on the Cricket game [post nr 1]

An average programmer can write an entire program in a week. Unfortunately I'm not an average programmer and I take incredibly long amounts of time to write the simplest things. Main reason for the slow progress is not having much motivation therefore I decided to get more graphic.
From now on every few days I'm gonna update this blog with the progress of my game and I'll post when there is something new you can actually see. I'll try to do it as often as I can. Hopefully having something to show for will motivate me to work more and procrastinate less, having said that here's my first progress update:

I finally added one of the key gameplay features: Singing.
Practically I've spent today's entire day adding Fmod support to my game and I'm happy to announce I now can have sounds! Of course having ability to play sounds would be nothing without the sounds themselves so I added the singing feature, mentioned in the "I'm probably not meant to be a game designer" post, suggested by Thedaian.
The singing works just like it did in Aquaria, you mouse over the notes arranged in a circle and compose short melody with them, if it matches any melody known to you will give you certain power or do something interesting. So far you can only play a fixed-size melody of 6 notes and all it does is toggle between red and purple song layout.

Before Singing: After Singing:
Note that everything here is placeholder, and the background still rotates continuously because I'm just too lazy to change a certain variable to false.

Here's my work in progress if you want to see it in action:
My game's current build with necessary DLLs:
Just the game exe and the assets:

WSAD-moves you (the little blue square).
LMB-places one of the walls on the mouse position.
Space-press and hold to play the music you like.
Q-hints at the only music available.

So this is all for today, I hope I didn't bore you too much, see you next time!

Monday, February 15, 2010

Entity based C++ Game Save Tutorial with complete code

Ok, so maybe I'm not meant to be a game designer but I want definitely to be a game programmer. I like doing all that low level code and I've got an enormous help from tutorials all over the internet and from the "Game Programming Gems Vol 3" book. I hope you find this tutorial useful, and if not then at least I hope you like the save system I wrote for you. If you've been following my blog you are now aware that I have been developing a game engine for quite some time. I bet heavily on automation and allowing the programmer know as little of internal workings as he wishes. My current iteration of my engine has been influenced heavily by the Source engine structure. But enough about this, if you're here it means you got interested in the a tutorial on how to save entities.
Now, before we begin I'll be mostly talking theory, if you want you can download the entire source code as well as a sample program showing it works in a link I'll provide at the end of this page. This tutorial won't explain on how to implement the saving system I'm describing, but it will tell you a lot of theory to build your own based on Shells or use the code I wrote. If you don't find this tutorial that much helpful since you would like to know the implementation then look at the code in the linked file at the bottom of this post, not only it has everything setup so you can use my code in your project right away, but it has a very good readme file that explains everything from how it works to what every separate thing does, to how to integrate it with existing systems.

Part 1: the start
So you've just created a good entity system or are about to and you think to yourself "gee, if I only had implemented the ability to save entities to a file or a buffer!". Many times beginner programmers let the saving system to the end. Although it's not a bad thing since it's one of the last thing you need you have to prepare a fertile ground for saving. One of the mistakes people do is keeping references to other entities in game as pointers in your object. This practice leads to many problems when you start to make the saving system so here's a word of advice: Don't do it. If you want having references to other entities like to an owner or the nearest enemy keep them as handles. A Handle is a combination of an ID and a index, most probably you'll either keep your entities on a static sized array so you don't have to reallocate the entire collection every time you add or remove an entity. A handle is basically an ID, it works great if it's just the index of the object on the entity array since you're gonna need that anyway. By passing the handle/ID to the entityManager he should be able to give you a pointer to the entity you want or NULL if no such entity exist (the best thing about handles is that you don't have to worry that if you erase your entity if it leaves dangling pointers on other entities). Having all entities inheriting from one common ancestor is also usually a requirement of loading systems.

Part2: the Theory
In an ideal saving system you would be able to just call LoadEntities(char* buf) and the entire system would just do everything you expect it to do. Luckily it is possible, unfortunately you have to implement all that code yourself, or use someone else's code.
Let's start at where we began: we have a collection of objects that don't have any saving implemented and you want to save them. What a bummer! you have to write so much code for every single variable just to save it! You're lucky you've got me, and I'll teach you how to reduce your workload using Shells and Macros (yes, remember my last rant about them? well you'll see them in full action this time!). I'll just quickly state that by using macros instead of rewriting/copying and replacing about a hundred lines of code for every class you'll only write two short lines, and then one very short line of code for every variable you want to save.

What is a shell?
The theory behind shells is the following: you create a small object specialized for every entity you want to save in your game that holds which variables will be saved and loaded. It'll work as our intermediary between the entity to save and the buffer: [entity]<--->[shell]<--->[buffer] The Ideal would be to be able to write something like this:
FooShell {
  • x[float]
  • y[float]
  • name[string]
...and then just call the shell's saveObject(object,buffer) and loadObject(object,Buffer). To achieve this we must create a system that:
  • allows passing of a variable as a parameter
  • allows passing the type of the variable
The difficulty lies that Shell and the entity we want to save are separate classes. By joining them into one we would lose the abstraction we have right now. So what do we do? We use a nasty little trick and instead of getting the variables themselves we get their offsets and sizes in bytes. What do I mean by that? Let's say we have an object with three float variables x,y,z and we want to save two of them, let's say y and z. This is how our object would look in memory:
  v-object start
where each [ ] represents a byte. to save y we need to get it's offset from the start of the object. for that we must handle some nasty pointer calculations. in theory you grab the address of y and then subtract from it the address of the object which is also the object start. In our case the offset of y would be 4 and it's size would be sizeof(float) which is also 4. Would you look at that! We already have a format for our variable storage entry in c++ it would look like this:
struct varEntry
 unsigned int size;
 unsigned int offset
our Shell class would look like the following
struct Shell
  virtual void fillEntityFromBuffer(baseClass* ent,char* buffer);
  virtual void fillBufferFromEntity(baseClass* ent,char* buffer);
  virtual unsigned int getMinBufferSize();
  static varEntry* variableList();
The member function variableList should return an array of statically allocated varEntry-s holding information about the offset and size of every variable to be saved/loaded for the specific entity that Shell was made for, to add simplicity that array should end with a special entry, you could chose an varEntry with size0 and offset 0 or size=0xffffffff and offset=0xffffffff (you can get this by casting a -1 to unsigned integer).

3. How the system works
In a Shell based saving system to save all the entities you'd do either one of these things: every instance of every class would need to have a member function that gives us the shell assigned to it. This works great for saving but problems appear when you are loading entities, and don't know which constructor to use. My favorite mode of overcoming this problem would be to write a singleton factory class for every entity that could not only spawn the entity instance we want, but that could also give us a singleton shell object specific to that entity. On the save system side you'd have one shell for every entity in game and one base shell corresponding to the one entity/class that is the common ancestor from which every other are descendant. An advantage of such system is that if combined with Macros you'll end up writing a little bit more code on the implementation but it'll save you literally thousands of lines of code throughout the project.
The workflow of this method is separated into two phases:
The Implementation phase is the most difficult and takes the longest to complete as you have to write a generic loading code for variables, however thanks to this initial stretch the Use phase, which is when you're actually assigning saving capabilities to every entity you want/need will take a lot less time and a lot less code.
    So the things you'll need are:
  • One common ancestor to all entities in game
  • A Shell class, that's gonna be rewritten a lot (or not at all with macros), built for saving and loading the variables from a buffer.
  • A variable storage entry with a specific format.

if done right with macros you'll end up with having something like this after every entity you want to save:
So that would be all! I hope you liked this tutorial/article/whatever and found it useful, even if not, you can still download my code here: [Shell Based Entity Save System]

Wednesday, February 3, 2010

I'm probably not meant to be a game designer (will update this post with your Ideas)

Full of enthusiasm I have reached a point in which my engine is good enough to make a simple game. Collisions work, rendering works, it's easily scalable, you can add new objects into the game without any hassle and everything is just peachy.
It also means that at this points I lose all the Ideas for a game since I don't want to make a clone nor an uninspired game. A miniLD competition would work out great since right at this moment I have just finished the engine to such a state that I don't have any "illegal" code and it's still easy to make a game in it.
Yesterday when I was talking on IRC complaining about this to people who were there (and couldn't escape my complaints if they wanted to talk to other people on that channel) I had a wonderful Idea (yes, the I is capital for purpose):
You play as a cricket.
What an extraordinary Idea it is! It only lacks something minor to complete it but the foundations are already there! One of the participants in the conversation (whose name I won't mention for his own safety and not because I forgot it) told me: "what if he played musics to get magical powers or change the terrain?". Now that's what I call inspiration! The game idea still lacks something though but so far we got this:

Main character:
  -The Cricket
What he does:
  -he can jump (oh yeah, this Idea was all mine, I'm that clever)
  -plays music to get magic powers (that guy's Idea)

yeah... just a few minuscule thing are missing but I guess I can make a game out of this. Still, small details can destroy huge buildings! So I'm asking help from You, the reader, to fill in those little things like the story, setting, enemies, and the rest of the gameplay that you would want to see in this marvelous masterpiece.

I'm gonna update this space with your awesome Ideas (yes, this I is also capitalized for purpose)

To those that would want to help me here's a concept drawing of the main characters. Those that don't want to help me please don't look at it.

The Cricket:
I know he may look innocent but he's a deadly killing death machine.(I'll probably make him look more deadly in future revisions)

The Ki-Dan-Shoo:
His wrath at humankind was so powerful it opened a third eye with his hate-chakra. Also he has a scar on his eye which hints that he is evil.

What we've got so far:
Game Name:
Main character:
  -The cricket - Loyal servant of the Ki-Dan-Shoo, also he needs a name.
Secondary Characters:
  -The Ki-Dan-Shoo - a sentient blade of grass with three eyes, the third one being his chakra-eye(PsySal's Idea)
What he does:
  -he can jump (oh yeah, this Idea was all mine, I'm that clever)
  -plays music to get magic powers (Thedaian's Idea (aka That guy))
Story:(contributors: PsySal, Demize, Anonymous)
  -His master, the Ki-Dan-Shoo, who seeks revenge on humankind has ordered our main character to kill all humans. His wrath goes all the way back to his early days when he kept the crickets as pets. He raised them from eggs taking care of them every day. As he lived on he had too many crickets, so he he gave many away hoping that they would find a better place, for his horror he discovered that those unfortunate souls were used as food for Human pets. His blood boiled inside him wanting vengance! Through incredible stunts, plot twists and awesome action the fate of the humankind will be decided In Space!