LPC: The Game

I started development on the game for the liberated cup and so far it’s going well enough for me to be able to talk a bit about it.

The basic idea would be to have a battle for territory spiced up with some one on one combat. Therefore I started with the following setup:

Image

Basically I started with the idea of the battle of the opposites, nature represented here by water and grass and destruction represented by barren rocks and lava. Now if you try to imagine that the picture above would be filled with art from liberated pixel cup awesome tilesets instead of my prototype, this is basically a 10×10 grid where the two should battle it out.

Rules are simple:

  • Each player starts with 20 life points
  • Each turn a player can attack his opponent, cast a spell, or create territory
  • When you attack the other player loses 1 life and goes 2 tiles back
  • If there’s not enough room to go back, the opposite player loses one life for each tile it doesn’t move(1 tile = -2 life, 2 tiles = -3 life)
  • When you create territory you can only create 2×2 blocks at one time
  • Territory created can be either walkable or not walkable
  • You cannot place a territory if it blocks every path to the other player
  • If you are on your territory when you start the round and your health is < 20, you get 1 life point back
  • You have a limited amount of territory you can build (I’m still working on the specifics)

Spells are something I’m going to detail later because they’re a work in progress.

In any case, development has started off well and I’ve made up most of my spritesheet management stuff, so I should be able to post some actual gameplay soon. Also if you’re into that stuff, you can follow the development of this game on github at this address. I should start pushing pretty soon, after I receive some answers. Until then I’ll just leave this teaser here:

Image

Advertisements

LPC: The Tools

So I think two days should be more than enough to come up with an educated guess at what the best tools for making a quick game for the liberated pixel cup should be.

However, instead of just spewing out names, I’d like to take a more structured approach this time to showcase the entire process. That way if anyone stumbles across this post wanting a clarification on how to make a game, they could use it as a guideline.

First things first, let’s say that you already have a good idea about what you want to do and it’s either fairly documented somewhere or you have it very clear in your head, so coming up with ideas for making a game isn’t really a problem. At this point, you need to define the following:

  1. Platform (Mobile? Windows? Linux? Mac? All?)
  2. Environment ( IDE / Programming Language / Frameworks etc. )
  3. Graphic Design Tool(s)
  4. Audio Design Tool(s)

The Platform

This is the one that makes the most difference, this will be the one you will see and live with for the next few months so you should think about it very thoroughly. Every platform has its quirks and if you don’t know what you’re doing it’s going to be a hell developing for all of them at once, so usually what you will want to do is select one that you are most comfortable with and try to keep the door open for others. For the purposes of this competition, I will start off on Linux.

The Environment

So the platform is out of the way, now it’s time for the environment. Ideally you’ll do this on the same platform that you are developing for ( unless it’s mobile of course ) and let’s say for the sake of the argument that you do, the first thing you will need to research is what tools are there available for my platform that help me make a game. So in my case, I have to make a game for Linux, but keep my options open as well, what can I use ? well it boils down to this:

  • HTML 5
  • C/C++
  • Python
  • Cross-platform game makers

Now, I don’t have anything with game makers, but I wanted to do this in a language I am already familiar with so they fall from the start. Also this game should be finalized within a week more or less, so as much as I wanted to, I didn’t think I could do it in C++. This leaves of course Python and Javascript and seeing as the recent HTML5 hype has reached a peak right now, I figured I’d have more options to choose from if I went that way, not necessarily now, but in the future as well (as a side note, existing Python frameworks should be older and more stable/feature rich)

So up until now I want to make an HTML5 game on Linux. Theoretically this should be enough and I could start, but it’s not, because it would mean having to create my own engine from scratch which sounds intriguing indeed, but wouldn’t be an option in this timeframe, so the next logical step is to find a framework. After careful consideration, these are the ones I could come up with:

Entity looks better structured, but in the end I decided to go for LimeJS because it seemed to me that it has more features.

And so the platform, language and framework are decided, there’s just one last step and that is to choose a suitable IDE, but since it’s not like there’s a plethora of Javascript IDEs it was more or less about choosing the version of repurposed Eclipse IDE that felt the best, so in the end I went with Aptana Studio.

Therefore my environment looks like this now:

  • Linux ( Mint 12 )
  • HTML5 ( language )
  • LimeJS ( framework )
  • Aptana Studio ( IDE )

Which seems about right, so this is the end of this chapter.

Graphic Design Tools

The graphic style of this competition more or less dictates the usage of a raster based software and being on Linux, there’s no doubt about the supremacy of GIMP in this area ( the 2.10 version being a new kind of awesome ) so there wasn’t really much to think about here, but in case you are looking for some alternatives you might also want to check these out:

Sound Design Tools

Do not let the position in this post fool you, this is one of the most important parts in making a game, having nice graphics and lots of eye candy will go a long way for your game, but a lack of sound effects in your game can be a very big turn off. Luckily there’s a very neat tool that comes in handy here called sfxr that will help you with the audio creation and it’s perfect for this competition, so that’s what I’ll use.

So to sum it up, you want to make a game, think about: platform, language, framework, tools choose wisely and most importantly have fun.

See you at the competition.

Back in Business

So to speak, it’s been a while since I’ve made something enjoyable and with all the recent happenings I’ve more than enough time, I just needed some sense of scope.

Luckily for me, competitions are always a good source of inspiration and it seems nowadays they’re just popping around the corner and as always there’s bound to be one that lights that tiny spark in your eyes that reeks of creativity.

Therefore, without furthering the issue, I’m going to participate in the liberated pixel cup competition with a revamped version of an older idea baked a long time ago with fellow developer Zapakitul called Peons and hope that at least some people will enjoy it.

I’m not very sure about the toolchain I’ll be using, I’ll do some research first, but I’m pretty sure I’ll end up concluding that HTML5 would be best in this case. Everything will be hosted on github and available under GPL v3 if you feel like checking it out.

Other than that, if anyone else is planning on participating as well, shoot me a comment, I’m pretty sure I’ll be available over most conventional IM clients (but I’d really prefer skype or google hangout) if you need to bounce ideas or require help with implementing a feature.

TL;DR Awesome competition, count me in

A Dev Story: Functors

Picking up where we left off, the next logical step in building a parser would be to somehow define the interactions between data types. Now because this is 2012 and the olden days where procedural programming was the de facto standard are way behind us, we’d like for this script parser to support these minimum requirements:

  • Operators for every possible combination of Invariants ( +, – etc)
  • Function scope
  • Objects
  • Duck Typing

And we want to be able to do this in a reasonable amount of time, so of course hardcoding behavior on a per Invariant basis being a massive overkill from this point of view falls from the start. What we actually need here is a way to generate an abstractization of this behavior on which we can build when time comes.

Luckily here’s where we can take a lesson from the C++ architecture. You see, in C++ object orientedness is somewhat of an illusion propagated by the compiler, every member function you declare in a class is ultimately transformed into a procedural style function to which compiler passes the this pointer, which is why you can abuse the compiler and do stuff like the following:
//Foo.h

class Foo{

private:
 Foo();
public:
 int Bar();
};
 //Foo.cpp
#include"Foo.h"
int Foo::Bar(){
 return8;
} 
//main.cpp
#include "Foo.h" #include<cstdio> 
int main()
{
 Foo*foo=NULL;
 foo->Bar();
 return0;
}

without fear of a crash. Beyond the fact that this serves to prove that C++ can sometimes resemble the goatse of object oriented programming, we can take a mental note on implementing the architecture we want. So we need a way to store functions in a invariant object and pass the this pointer at runtime when we call a function that we previously added to an invariant.

The next thing C++ can teach is that we can think of operators as functions, which is indeed particularly interesting because having decided that we want objects, we can now store operators as one of the functions the object has and call it when  we encounter it in our parser. This also has the advantage that we can name it to match the operator it represents so that when the time comes to interpret the parse tree, when you encounter an operator node all you have to do is call the method that matches the operators’ string.

This is where Functors ( short for Function Objects ) come in. You know how we defined an interface for the Invariant, something that all invariants should have so that we could let them worry about managing the state of the underlying data so that we can use types interchangeably in our script. Well this is what we’re going to do with Functors:

class Functor{

public:
 InvUnknown* (*Func)(InvUnknown* args);
 Functor(InvUnknown* (*function)(InvUnknown* args)){
 Func = function;
 }
 virtual InvUnknown* apply(InvUnknown* args){return Func(args);}
};

So basically we took a function pointer and wrapped it in an object that has the apply method so that we can call this function at our convenience.

Now here is where it gets interesting because as you can see the Functor apply method takes a InvUnkown pointer as a argument and returns a InvUnknown pointer itself. Well because the Invariant was designed to abstract data and since we can pass any type of invariant to the function, this means that not only can we abuse the List invariant to pass as many arguments as we want to the function (not to mention return as many values as we want from the function), but this way we get the Duck Typing as well.

And last but not least the function scope can be implemented by adding a map to the Functor object so that we can store temporary objects.

Up until now all is good in theory, but a real world example wouldn’t hurt, so allow me to demonstrate this by implementing a push function for a list.

First of all we need to update the InvUnknown class to take advantage of these functors:

class InvUnknown{
public:
virtual bool inline is(inttype){returninv_type==type;}
virtual const string toString() = 0;
virtual void nativeCall(InvUnknown*param) = 0;
virtual InvUnknown* call(string& name,InvUnknown* params)
{
 Functor* method=methods[name];
 if(!method)printf("No method with name %s found",name.c_str());
   assert(params->is(LIST) && "Function parameters must be passed as LIST invariants");
 params->nativeCall(this);
 return method->apply(params);
}
protected:
 InvUnknown(int type){inv_type=type;} 
 map<string,Functor*>methods;
 void inline addMethod(string&name,InvUnknown* (*function)(InvUnknown*)){
 Functor* method = new Functor(function); 
 methods.insert(pair<string,Functor*>(name,method));
 }
private:
 int inv_type;
};

Now we have the means to store and access Functors from our Invariant. Notice the native call though. In my opinion this is a hack that is unfortunately needed because upcasting in a base class is a definite no go and because the push Functor needs to take a list of values as a parameter, so the list has to be full when we call push.

Of course another solution would be to overload the apply method to take a vector<InvUnknown*> instead and it would basically be the same thing seeing as our list is in fact a wrapper for a vector<InvUnknown*>, but that wouldn’t be fair because that way you create an opening for bad practices. If the API you have to use in your code is the same as the one you expose to the script, this ensures that you are actually using what you create and you eliminate furstrations as you use it. Having a separate API that gives you more flexibility and or power than whatever you expose to the script usually shows that something isn’t planned right.

Onto the list definition:

class List:public Invariant<vector<InvUnknown*>,LIST>
{
 public:
 List();
 virtual const string toString();
 void inline nativeCall(InvUnknown* elem){data.insert(data.begin(),elem);}
 static InvUnknown* push(InvUnknown* args); } 

And the implementation

List::List(){
stringpush_name="push";
addMethod(push_name,&push);
}
const string List::toString()
{
 stringstream buffer;
 string retval;
 buffer << "[";
 vector<InvUnknown*>::iterator paramIt = data.begin();
 for(;paramIt != data.end();++paramIt)
 {
 if((*paramIt) == this) buffer << "this";
 else buffer << (*paramIt)->toString();
 if(paramIt != data.end()-1) buffer << ",";
 }
 buffer << "]";
 buffer >> retval;
 return retval;
}
InvUnknown*List::push(InvUnknown*params)
{
assert(params->is(LIST) && " ALL function parameters need to be passed as LIST objects");
List* paramList = (List*)params;
vector<InvUnknown*>data = paramList->getData();
assert(data[0]->is(LIST) && "List function push called on non list");
List*parent=(List*)data[0];
for(unsigned int paramIt = 1;paramIt < data.size();++paramIt)
 parent->nativeCall(data[paramIt]);
 return parent;  
}

And last but not least the actual usage of the push function:

InvUnknown* l1 = new List();

InvUnknown* l3 = new List();
InvUnknown* l2 = new Primitive();
InvUnknown* args = new List();
string push_name = "push";
args->nativeCall(l3);
args->nativeCall(l2);
l3->call(push_name,args);
args->nativeCall(l1);
args->nativeCall(l1);
args->nativeCall(l2);
args->nativeCall(l2);
l1->call(push_name,args);
delete l1;
delete l2;
delete args;

Which produces the following output:

[this,0x227d858]
[[this,0x227d858],0x227d858,[this,0x227d858],this,this,0x227d858,0x227d858]

Which means that I can add Primitives (Invariant) and Lists and I can just as easily add just about any other Invariant I fancy, success.
Next time we talk a bit about scope.

A Dev Story: Invariants

Todays’ post is about a small hobby of mine of looking into the details of creating a fully featured dev environment, more precisely I’m going to talk about how to start designing your own scripting language. This series will revolve around C++ because of reasons, but if anyone should request it I can easily port it to any compatible language

Anyway hype words aside let’s say you want to start creating your own scripting language. The first thing that comes to mind is storing data.

Now like everybody knows, the whole idea behind a scripting language is to be able to forget about the burdens of having to use cryptic language features, or wasting time on the planning required for writing programs in statically typed languages, so it only feels natural that our scripting language will feature dynamic typing. In other words if I have a variable a and I do
a = 'b';
a = 10;
a +=100;
print(a)

It should work as expected and not complain about anything.

Well back in the real world we have two solutions for this, either use another language that already has this feature (but of course that would most likely have little to no sense) which leaves having to build this thing in a boilerplate code friendly environment.

So first of all we want to create a base on which to build this system. We don’t want to expose too much information here, just the bare minimum to get a context in case it’s needed. This is achieved via a class that will have a member variable to describe what it holds

class InvUnknown{
public:
 virtual bool inline is(int type){return inv_type == type;}
 virtual int inline getType(){return inv_type;}
protected:
 InvUnknown(int type){inv_type = type;}
private:
 int inv_type;
}; 

Now like we specified earlier, we want our invariant to be able to hold any type of data we might encounter in the script, ideally it would have to do this without grabbing every last bit of memory it can get its hands on and without having to force the construction of another invariant when we want to set the value, which is why we’ll be using unions.

 union Data{
 double doubleData;
 int integerData;
 float floatData;
 string *stringData;
 InvUnknown *invariantData;
};

We’d like to somehow limit the amount of datatypes we put into this union though because having a plethora of datatypes + data storage combinations would eventually become cumbersome, so we’ll have the union store only simple primitives and objects and if the need arrives to hold an array for instance we will just use an invariant.

And now that the base is set we define the invariant as such:

template <typenameT,intType>
class Invariant:public InvUnknown
{
public:
 Invariant():InvUnknown(Type){}
 Invariant(T&_data):InvUnknown(Type), data(_data){}
 virtual T inline getData(){return data;}
 virtual const string toString(){
 stringstream buffer;
 string retval;
 buffer << &data;
 buffer >> retval;
 return retval;
};
protected:
 T data;
}; 

And this is it, now all there is to do is to define the set of methods that can be applied given any type T you want to support and then particularize the invariant by deriving it like so:

class Primitive:public Invariant<Data,PRIMITIVE>{
};

Next time we’ll talk about applying the same principle to functions

Game Design: Cheating

Following up on my last post, it seems to work, but unfortunately having an idea is not enough, bringing it to life requires time to actually write it , but in any case I feel like talking about design again right now so here it goes.

Ask any game designer and he will tell you that cheating is bad, it;s something you want to prevent because it’s that type of behavior that will kill the enthusiasm you have when playing a game (more so in a multiplayer game where not only you ruin your fun, but you ruin other peoples’ fun too), it’s something that you’d normally want to discourage.

Well I say fight fire with fire, cheating is only bad if it enables someone to make an action you are actively trying to discourage, but what if you were to plan ahead to include behavior that would normally be associated with cheating to give the player the sense that he is in fact breaking the rules and add to the sense of achievement when you finish your task.

So for instance let’s say you have a physics game and a level built so that the obvious solution requires a minimum of 3 steps to complete. What I’m proposing is that you add some way of completing it in say 1 or 2 moves preferably by exploiting a side effect of a mechanic to make the person that finds it feel like he is smarter than you.

What do you think would it be a good idea ?

And yes this thing dawned on me while playing physics games, but I guess I can come up with a way to use this in other games as well.

Game Design: Chekpoints

Well I started tis blog to talk about design (system design, if you came here for art you’re in the wrong place) so I’m now going to pick up where I left off.

I was playing a lot of mass effect recently and what can I say, the game really stands out. Generally it is a model you can follow, but apart from the small collision glitches and the fact that the button that skips cutscenes doubles as the button that selects conversation options, that game has just one serious flaw: checkpoints.

I don’t know, maybe I’m a pretentious prick, but it just doesn’t seem normal to let the user redo more than let’s say 10 minutes worth of gameplay. What this means is not necessarily that the game engine should feature a timer that saves the game every 10 minutes, rather that at the beginning and the end of EVERY mission (yes, that includes side quests) there should be a checkpoint. Or even more general, let’s say you’re working at a game that doesn’t feature any sort of quest. If there is a sequence during which a player might fail his objectives and have to restart his progress, make a checkpoint before and one after that sequence.

What this means for the user is that he won’t have to redo the boring sequences in between missions like say for instance how I have to run around and talk to every NPC on Feros right now because I got killed when I was returning to the quest giver.

So to sum it up: Checkpoints are your friends, use them often.