No, sorry, this is not the name of a horror game. This post intends to be a reflection about the nature of human beings. Actually, in the heading I'm using "Deadline-Driven" as a synonym of "Human". The goal of this post is to insist on the importance of setting hard deadlines for your projects. Don't underestimate this piece of advice, because psychology and project management theory have proven what I'm claiming here.
Just remember when you were in school or in college. When were you more productive? When did you study the most? I'm sure that the answers to both questions are the same: the day before the exam. Yes, you had four months to prepare the exam. Of course you could have been studying all along the semester. Sure you could have prepared the exam two or three weeks before the day of the exam. But you didn't, I didn't and almost no one did it (of course there might be rare exceptions over there).
It's sad but we can't fight our nature. As the name of an interesting film that I recently saw stated, we are what we are. And humans are deadline-driven.
Figure 1.- The deadline, even when it seems scary, it is a necessary and natural
part of the productivity life cycle (image taken from
I'm currently doing my PhD, and I know how the research area works. When would you say that I'm more productive? Yes, you're right, when a deadline for the submission to a conference is coming in a few days. Probably I could have prepared a nice work and then, a posteriori, check to which conference send the work. But things usually work in the other way around: you won't have anything substantial until you know where you want to send it, and until you see the deadline so close that you have no choice other than paying all your attention to that work.
And why making a game would be any different? You usually have many nifty ideas, you prototype new mechanics, cool!! But then procrastination dwells in your heart, and you figure out a new way to improve your original idea, and then a new even better idea replaces the previous one, until you're fed up with the original idea because you think of something completely different that is going to shake the market up with top-notch mechanics never seen before…Yes, yes, we all went through that road until we found an important stumbling block in the form of logical implications: no deadline -> no pressure -> no game.
This is also the reason why we (Manuela and me) decided to set up a deadline for the release of the game announced in the previous post: Chubby Buddy. We still have lots of work ahead, and we won't be able to address some cool ideas that we originally had. But otherwise I know that we would run the risk of never releasing the game, because we have so many other ideas, that it would be very tempting to blow this one off and to pursue a new one.
Game jams and reputable venues like the Independent Game Festival are excellent options to put a bit of pressure on yourself. Even telling your friends or your family that you're showing them something on a given day will probably give your productivity the required boost!
See you! (by next week hopefully… yes, I'm of course as deadline-driven as anyone else)
It's my pleasure to announce the release date of an amazingly super-great game for iOS: Chubby Buddy! On December, 20th, you'll be able to enjoy a very yummy puzzle game. In the following posts, I'll unveil some development issues about the game.
For now, I'd like to simply invite you to visit the just-created Facebook page.
Figure 1. This is our favourite chubby buddy. We'll have to help him
through levels full of sugar and unhealthy food temptations
I just wanted to share my first attempts to effectively use the Qt and SFML integration I showed you in the previous post. My goal is to build a simple, yet useful level editor for a 2d platform game I'm developing. As you will see, there's still much to do, but it's a beginning.
NOTE: the video seems to show buggy rendering, but it's just a matter of the screen capturer software. The renderer is completely clean and fluent (for the moment, at least :).
Today, I'm gonna show you my last fight and victory (for now :)). The goal: integrating SFML with Qt. Yeah, too many abbreviations... ok, let's go step by step.
SFML, as mentioned in earlier posts, is an efficient, easy to learn library that wraps OpenGL as a set of higher-level classes and methods. As its main purpose is to draw (or technically, render) things on the screen, it is usually referred as a renderer library. But it doesn't go beyond that: it's not a framework that manages the screen by screen graphs or trees, such as Ogre3D, for example. It is just a nicer entry point to OpenGL.
On the other hand, Qt (pronounced 'cute'), is a framework for developing Graphical User Interfaces (GUI) applications. As such, it provides an API to let developers create buttons, windows, labels, etc in an easy manner. Its (very) complete API also allows developers to render things on the windows.
The question is: why would it be a good idea to integrate these two libraries? Well, SFML is a very good renderer, but it lacks the capability to create complex GUIs, whereas Qt has the opposite pros and cons. Therefore, the integration yields the breeding ground for nice game tools development, for instance, a level editor. And this is actually the reason why I wanted this integration. I can take advantage of my current knowledge of SFML, and just need to learn some concrete parts of Qt, concretely, the parts for drawing windows stuff (toolbars, menus, etc) and for receiving interaction events from the user.
In addition, Qt brings a very complete IDE (Integrated Development Environment) for C++, which according to many people in forums, it is better if you want to work in C++ than XCode (the Mac OS default IDE), which is more fine-tuned to work with Objective-C. The Qt IDE is called Qt Creator.
First of all, the specification of the problem:
Operating System: Mac OS X 10.7.5
Qt: 5.5.1 (Clang 3.1, 64 bit) -> Clang is the name of the C++ compiler to be used and is installed automatically when you install Qt.
Qt Creator: 2.8.1
SFML: 2.0
Once you have downloaded everything you need (correct SFML and Qt packages), you must follow the following steps:
1) Open a new Qt Creator project. You have to let Qt Creator know where it can find the headers and libraries of SFML. You can copy the following lines and paste them in the .pro file of the Qt Creator project. IMPORTANT: Everything between '< >' must be set appropriately according to your installation settings.
### TO ALLOW SFML LIBRARY ###
CONFIG_APP_NAME = <Name of your application (in Qt Creator)>
INCLUDEPATH += <Path of installation of SFML>/SFML/include
DEPENDPATH += <Path of installation of SFML>/SFML/include
CONFIG(release, debug|release):
LIBS += -L/<Path build of SFML>/SFML-build/lib -lsfml-audio
Before macx, we're simply doing what I explained: more precisely, we are telling to the compiler where it can find the SFML headers, and to the linker where it can find the SFML libraries. The instructions after the macx (which are QMake instructions), make the following: first, it creates a directory called Framework under <Application path>.app/Contents/, and then, it copies the SFML libraries in this directory. Why? Because the Mac OS loader reads the binaries of these libraries from this location. As simple as that. If you want to avoid problems, I suggest you at this point disallowing 'Shadow build' in Qt Creator (more information here).
2) Once these configuration issues are solved, let's perform the actual integration. As explained here, Qt extensions are done by means of extending QWidget class. So, we have to create a new QWidget, which is the SFML RenderWindow. The code changes a bit with respect to the SFML 1.6 tutorial. I'm simply going to paste here the raw code you will need for the different files. For a proper explanation though, I suggest you to read the aforementioned tutorial.
#include "qsfmlcanvas.h" #ifdef Q_WS_X11 #include <Qt/qx11info_x11.h> #include <X11/Xlib.h> #endif #include <iostream> QSFMLCanvas::QSFMLCanvas(QWidget* Parent, const QPoint& Position, const QSize& Size, unsigned int FrameTime) : QWidget(Parent), myInitialized (false) { // Setup some states to allow direct rendering into the widget setAttribute(Qt::WA_PaintOnScreen); setAttribute(Qt::WA_OpaquePaintEvent); setAttribute(Qt::WA_NoSystemBackground); // Set strong focus to enable keyboard events to be received setFocusPolicy(Qt::StrongFocus); // Setup the widget geometry move(Position); resize(Size); // Setup the timer myTimer.setInterval(FrameTime); } QSFMLCanvas::~QSFMLCanvas() {} void QSFMLCanvas::showEvent(QShowEvent*) { if (!myInitialized) { // Under X11, we need to flush the commands sent to the server to ensure that // SFML will get an updated view of the windows #ifdef Q_WS_X11 //XFlush(QX11Info::display()); #endif // Create the SFML window with the widget handle RenderWindow::create((void *) winId()); // Let the derived class do its specific stuff OnInit(); // Setup the timer to trigger a refresh at specified framerate connect(&myTimer, SIGNAL(timeout()), this, SLOT(repaint())); myTimer.start(); myInitialized = true; } } QPaintEngine* QSFMLCanvas::paintEngine() const { return 0; } void QSFMLCanvas::paintEvent(QPaintEvent*) { // Let the derived class do its specific stuff OnUpdate(); // Display on screen RenderWindow::display(); } void QSFMLCanvas::OnInit() {} void QSFMLCanvas::OnUpdate() {}
main.cpp #include <QApplication>
#include "mycanvas.h"
#include <QFrame>
int main(int argc, char *argv[])
{
QApplication App(argc, argv);
// Create the main frame
QFrame* MainFrame = new QFrame;
MainFrame->setWindowTitle("Qt SFML");
MainFrame->resize(400, 400);
MainFrame->show();
// Create a SFML view inside the main frame
MyCanvas* SFMLView = new MyCanvas(MainFrame, QPoint(20, 20), QSize(360, 360));
SFMLView->show();
return App.exec();
}
There is an important consideration. Qt Creator uses a special way to declare the resources (e.g. images) that your application will use. It does so in order to comply with the cross-platform requirement, but it can be quite weird for someone who is not used to it. Basically, you would need to create a Resource file. However, SFML does not understand this, and when you try to execute loadFromFile in the MyCanvas::OnInit method by using this approach, SFML does not find the image. The solution, at least temporal and for testing purposes, is that you place you image inside the <Path application>.app/Contents/MacOS directory, and that you use the piece of code that I have provided above, which will search the image in that directory.
Figure 1. Output of the program. Basically, it's a Qt frame with a SFML renderer window inside the frame. It is showing the chef, which is a sprite (which as usual has been designed by Manuela) that I'm using for an iOS game that will come out very soon :).
I think that's all. If I forgot something or you need more explanations, just let me know and I'll update the post.
EDIT: Some people following this tutorial have encountered the following error: "error: invalid conversion from 'void*' to 'sf::WindowHandle {aka HWND__*}' [-fpermissive] RenderWindow::create((void *) winId());^". This error occurs in the line RenderWindow::create((void *) winId());
The solution, which was posted here, is to change the aforementioned line to this one: RenderWindow::create(reinterpret_cast<sf::WindowHandle>(winId())); (Thanks to delio and hyde for raising the problem and the fix)
These last days I have been reading quite a lot about scripting engines or systems and why they should be included yes or yes in any worthy game engine. When I first heard about this, I have to admit that I had a narrow vision on its possibilities, maybe because I didn't fully understand the idea behind having an embedded scripting engine. Now that I understand it better, I want to share some of my (limited) knowledge with you.
Ok, so first of all: what is a script? According to Wikipedia, scripts are 'programs written for a special run-time environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator'. Well, actually, the truth is that there is a fading boundary between a script and a 'traditional' program. Script languages are usually interpreted, which means that their instructions are executed on the fly by the interpreter, which usually is simply a virtual machine capable of understanding the high-level script instructions and of executing them on the target machine.
Traditionally, interpreted languages have not been considered a good choice for game programming, given the high performance requirements of this kind of software, which must run at a minimum of around 60 frames per second. However, as interpreted languages evolve and devices acquire more powerful processors, this is no longer completely this way.
Most game engines include scripting as part of their suite.
Well, it is true that the performance of a C or C++-written game will never (for the moment) equal the performance of the same game written in an interpreted language (or in other higher level languages like Java). But it is indeed possible to, let's say, outsource some functionalities to be implemented by these languages.
Let's go with a simple example. Let's suppose you're doing a side-scrolling game and you want that when the player reaches a certain position in the scenario, a particle system sparks off, e.g., an explosion goes off. Let's assume that you don't know anything about scripts, so you must hard-code this effect in the game logic, which would result in something like this:
void ParticleSystem::start(Position x, Position y) {
for (int i = 0; i < N_PARTICLES; i++) {
particles[i] -> start();
particles[i] -> setVelocity(...//random velocity for each particle);
The code is not difficult to follow. I have to check, in each update of the game for a specific level, if the player has reached the specified position. [NOTE: I simplified the code here; I think that an improved version should use the Observer pattern so that the player object itself notifies the particle system when it reaches the destination]. Then, the particle system initializes all the particles with a given image (particle.png) and sets a random velocity for each particle. So far so good.
However, when you run your game, you notice that setting the velocity to a random number does not provide a realistic explosion effect. Ok, you change the code, compile again, and run again. Ufff... the bitmap used for the particles is not that cool. Ok, let's create a new bitmap, compile again, and test it. And you can be repeating this process dozens of times until you end up happy with the result.
Now, let's assume that you implemented a scripting engine in your system. Let's see how the code in your game would look like (of course, this is no real code, just a simplification, as usual):
void ScriptingEngine::explosionEffect(Position x, Position y) {
initializeEngine(&sh); //sh stands for scripting handler
sh.pushParameters(x, y);
sh.executeFile("explosion.script");
}
void Level::update() { //update of all the objects if (player.position > X_EFFECT_POSITION) { ScriptingEngine::getInstance() -> explosionEffect(player.position.x, player.position.y); } }
And now, we create a .script file that will do exactly what the older code did:
//explosion.script//
Begin Script
player.position.x = popParameter(1);
player.position.y = popParamenter(2);
image = loadParticleImage("particle.png");
... //code that creates all the particles with random velocity
End Script
Basically, you communicate the required arguments (pushParameters) from the host language (e.g. C++) to the scripting system. Then, the scripting engine executes the explosion effect implemented in the file.
Now, you compile and execute. Mmmm... you're not happy with the particle bitmap or with the velocity of the particles. Let's change all that. Need to recompile again every time? No! Because the effect is completely loaded in the script, you only have to change the .script file and execute the game again. The game engine has outsourced the explosion effect to a scripting system, and this provides higher flexibility and effectiveness. The explosion effect is totally decoupled from the game logic, so any change in the effect doesn't alter the game logic and vice versa.
This is a really powerful feature that pushes the development experience forward. The possibilities of this approach are unlimited: faster testing and debugging, easy change of characters behaviour, improved extensibility of the game (capability of adding new features effortless), and much more!. And even better: you could provide a terminal with the game so that you can write script commands while the game is running, and you would see the changes immediately at runtime, without the need for restarting it.
From a design perspective, the biggest challenge is to know which parts of the game are worth this outsourcing. If you read enough about it, you'll get the following answer: delegate to the scripting system any aspect of the game that has no significant performance impact. In my opinion, this can be re-formulated as follows: do not call the script engine once per frame. Anything that needs to be executed once per frame should be implemented in the host language (e.g. C++). But any effect or event that does not occur every frame is a great candidate to be delegated to the scripting engine. The more you export (with unnoticeable performance degradation), the higher the productivity boost you will experience.
Regarding the scripting language to choose, there are lots of them out there, and the decision is likely to depend on the host language. For C++, for example, it's common to see bindings with Python and Lua, given that they are lightweight (specially the latter) and are implemented in C. I'm currently looking at Lua because I know that it's being used currently in many commercial games and the API seems to be simple enough. I'll let you know about my progress soon.
Hope this post was interesting, or at least that you learned something new from it. Don't hesitate to ask or comment anything you want.
This is the follow-up of a previous post about scrolling.
In this case, we are going to talk about parallax scrolling. This technique provides greater realism as it simulates some feeling of depth. To understand it, think when you're in a car and you look out the window. Obviously the closest objects (e.g. the stripes of the the road) move far much faster than the objects in the horizon (e.g. the mountains or clouds).
The way you can implement this is pretty straightforward. Look at Figure 1.
Figure 1.- Parallax Scrolling: layers and objects. The closest layer (the fastest one) is the one of the palms and floor. The furthest layer (i.e. the slowest one) is the one with the moon.
The idea is simply to create several layers or views and make the furthest layers to move slower than the closest layers. Therefore, in pseudo-code, you would have something like the following:
Level::createLevel() {
Mountain* m = new Mountain("mountain.png");
Cloud* farCloud = new Cloud("cloud.png");
Cloud* closeCloud = new Cloud("cloud.png");
Platform* p = new Platform("platform.png");
Layer* midLayer = new Layer(velocityMidLayer);
midLayer -> addObject(closeCloud);
Layer* closeLayer = new Layer(velocityCloseLayer);
closeLayer -> addObject(p);
}
Level::update() {
for (Layer *l: layersInLevel) {
l -> update();
}
}
Layer::update() {
for (Object *o: objectsInLayer) {
//Each object knows how to update itself in response to physics or input
o -> update();
}
//We move the layer too
this -> move (layerVelocity);
}
Layer::move(Vector &velocity) {
for (Object *o: objectsInLayer) {
o -> move (velocity);
}
}
I think that the code is more or less self-explanatory. A level is composed of layers, each of which has a different velocity. Each layer, in turn, is composed of objects. When you design a level, you first specify the number of layers and each layer velocity. Then, you associate each object to a level. When the level is updated, each layer is updated, which means that each object in the layer will be updated and moved according to the layer velocity.
Well, that's all for now. Hope you find this information useful. Don't hesitate to leave comments or suggestions or questions.
Today I want to talk to you about something that is a must-know in the world of game programming: the game loop.
The game loop is the sequence of actions that are run by the machine during the execution of the game and that are repeated until the game finishes. In C++-style, the game loop looks something like this:
while (!finished()) {
finished = getInput(&input);
update(input);
draw();
clearScreen();
}
The first thing the game does is to check the input provided by the player: keyboard presses/releases, screen touches, etc. Then, it updates, probably according to the input, the world: player, enemies, platforms, score and other variables, collisions, etc. Then, it draws (or more technically, it renders) the scene onto the screen, and then it clears out the screen to allow the rendering of the next loop execution, also known as frame.
I think that (almost) any game in the world can be organized by using this structure. How explicit this structure is from the viewpoint of the developer, is, however, another story, and it depends on the level of abstraction that the developer is using.
For example, in the game I'm developing for PC/Mac (that famous platform game I mentioned in earlier posts), I began almost from scratch. Therefore, all my class hierarchy and methods are set so as to follow the game loop structure, and the actual code for my main method matches almost perfectly the previous one.
However, I've recently started developing a small, puzzle game for iOS (more in future posts), and for this, I'm using the Cocos2D framework. When you use high-level libraries or frameworks, many of the gory details are hidden in order to abstract away unnecessary complexities and let the developer focus on the gameplay. In the case of frameworks, furthermore, it is usual the so-called inversion of control. This means that the framework takes the role of the main routine, and is the framework that is in charge of calling certain components/classes developed by the programmer, taking a leading role.
I'll give you a very simple concrete example: Cocos2D uses the notion of Node (CCNode class) and Layer (CCNode layer). Layers can contain nodes, and nodes can be rendered. Therefore you can write something like [layer addChild: node], which adds a node to a layer. Once you've added the node to a layer, the framework itself ensures that the draw method of the node is called every frame, so you cannot see the explicit call to this method because it is hidden inside the framework implementation and it's not exposed as an API (actually, you can override the draw method, but this is an advanced feature for more experienced developers).
The moral is this: even when you don't see the game loop, you must be aware that it's there, observing each of your movements... So be aware of it! Once you really understand the game loop and concept of frame, everything becomes nicer and easier.
I've been reading an excellent tutorial about how to make a 2d platform game and I wanted to share it with you. The tutorial is divided into three parts, and here you can access the first one (the rest is linked at the bottom of the post).
As a 2d platform game developer, I can assure that reading this tutorial is really worth it, as I've found many challenges and problems that the author discusses, even though I've dealt with some of them in different ways.
Yesterday I completed a great tutorial that guides you in a step-by-step basis to complete a simple iPhone game using Cocos2d. You can find the tutorial here.
Note that Cocos2d is not ARC-compliant (ARC stands for Automatic Reference Counting and you can check here for very interesting information about it), but in this post, it is explained how to make the Cocos2d Xcode templates ARC-compliant. Even when the library does not use ARC, you can of course develop any game using ARC-compliant code.
I've been curious for a long time about how to program for iPhone and iPad (in general, for iOS) and about Objective-C, the language under which to develop for this operating system, so I finally decided yesterday that it was time to delve a little bit into the details of this programming language.
If you can program in C/C++ and you know the fundamentals of Object-Oriented programming (knowing Java also helps), the leap to Objective-C seems pretty straightforward. I started reading the book Learning Objective-C 2.0: A Hands-on Guide to Objective-C for Mac and iOS by Robert Clair. I found this book very illustrative and well-written, so I can openly advice it.
Objective-C is an extension to plain C and very often it presents subtle differences with C++, such as the fact that you cannot create objects in the stack (i.e. you must always hold pointers to objects allocated in the heap), there's no syntax support for abstract classes, there are some new reserved keywords like nil (a pointer to no object) and id (a pointer to an object of any class), etc.
Possibly, the biggest change is that of the 'messaging system' used in place of function calls or method invocation. In Objective-C, you use the syntax [receiver message] where receiver is an object of a class and the message is the name of a method of that object. Technically, it seems another way of the same idea of method invocation, but the difference comes from the fact that this statement is not resolved at compile time but at run-time, adding more flexibility. Of course you can nest expressions and the result would be used in the next level (e.g. [[receiver message] message] would first evaluate the inner [receiver message] part and then the result would be used as the receiver of the outer [receiver message]).
The book also shows you how this messaging system (and other high level stuff) works under the hood (in the end, all is translated into plain C) and how to bypass the runtime (the runtime translates from Objective-C to plain C and fills in certain structures with class information) to gain efficiency when required, given that a function call, if very simple, is more than twice faster than the receiver-message scheme.
Regarding memory management, the language traditionally required the developer to manually take care of releasing allocated memory or retaining it, using manual reference counting. However, Apple included recently Automatic Reference Counting, which means that the runtime is in charge of doing this dirty work in an efficient way. In fact, Apple encourages developers to use this feature as it can give an important performance boost to applications and prevent memory leaks.
I've read more than half of the book and I'm enjoying it. My goal is to be able to develop games for iPhone and iPad, probably using existing and reputable frameworks such as Cocos2D. If your goal is the same, I highly advice you to learn the fundamentals of Objective-C and I think that this book is a perfect starting point.
If you have a game already developed or almost completed, you may be interested in participating in Ludum Dare competition. As I told you in an earlier post, this competition consists of creating a game (or several of them) as fast as possible. If you check their web page, you will see that there's a countdown that will reach zero in around seven hours. So what are you doing reading this post?? Hurry up!!
It's been a while since the last post, but I've been first busy and then on holidays. However, I'm back and I'm more eager than never to continue developing my game and sharing my experiences with you.
Don't miss the upcoming posts, which include further discussions on integration (see here and here for more information), parallax scrolling (see here) and some early images of the game I'm working on (check here and here), together with a general description of the small engine that supports the game.
Welcome to the last day at Gamepolis. If you missed the earlier posts, you can take a look at Friday and Saturday summaries.
Unfortunately, due to personal reasons, I couldn't turn up in the morning and I arrived by 2.00 p.m, and as usual, first thing I did was lining up to participate in the XBox 360 raffle. I promised you to tell you in this post if I'd won anything. I'll do it.
The first presentation was '3D Character Design: from Drafts to the Engine'. The speakers, Jesús del Pozo and Sergio Castro, started the talk by stating the greatest panic that every artist faces: 'the blank page'.
Once you, as an artist, are requested to perform a character design, first thing you must do is organizing all the information that is sent along with the request. This is a tough, boring task and nobody likes it, but it is necessary and you have to do it. Then, you should note down every idea (no matter how stupid turns out to be) because this process creates a snow ball effect where new ideas comes straight.
Figure 1.- Drafting many versions of kind robot.
Many people would sketch the physical characteristics of the character now, but they should be delayed until the end, because you, as an artist, want these characteristics to define the character rather than the character to define the characteristics. This is to assure that any pre-defined image of the character doesn't stand up against your creativity. For example, if you start sketching a pirate from the very beginning, it's natural that you'll end up drawing Jack Sparrow or similar, without adding a personal touch.
After noting down all your ideas, you should document yourself in order for the final character to have some 'traces of reality'. Then it's when the first drafts should be drawn and color tests (many of them) should be performed.
Figure 2.- Colouring the final chosen robot.
The modeler will then take that conceptual design (which should be precisely drawn in different angles) and will create a model using some modeling software such as Blender or 3DS Max. As a curiosity, it's important to model the character at different level of details, because depending on the proximity of the camera, different models will be used for performance reasons.
The next talk was actually a panel discussion named 'Women and the videogame', where the speakers, all of them women, discussed the status of videogames and their often sexist design orientation.
Miguel Ángel Carrillo, from Tragnarion Studios, gave the next talk: 'Tools for creating graphics resources and work pipelines'. The presentation began by giving a helicopter view of how an art department is organized: character design department, level design department, technical artists, illustrations department, etc. Of course, this organization depends on the size of the company. Something interesting that he pointed out is how important the figure of the technical artist has become in the last years. Technical artists are people that bridge the gap between artists and programmers, who know what each of them needs and can collaborate with them. So you know, if you have artistic skills and are good at programming, this is an interesting professional path to explore...
During the rest of the talk, Carrillo listed different tools for different processes: UV Mapping for texturing, shaders creation, etc. And during the round of questions, I asked him whether other tools were used in order to organize the work among people and departments. The answer was obviously yes. That's very important, as in a big company, you have to wait for some input that is provided by a colleague who you may not know, and vice versa.
Figure 3.- Graph that represents all the effects (shaders) that will be applied to a pixel prior to being drawn on screen. Artists obviously prefer these graphical tools so they don't have to program the shaders.
Last talk of the day was a presentation of a game called 'Embrion', a survival horror made by a new Andalusian studio that uses a sensor to measure the heart beating of the player in order to create more immersive environments and to influence on the gameplay. I think that the idea is brilliant and I can think of myriad of ways to exploit this idea so as to fill the player with authentic horror. I really wish them the very best of luck.
Final conclusions
It's amazing that Malaga has been the cot for a videogames event with such a great success, and I want to personally thank all the organization staff for the invested effort. There are some issues, however, that I'd like to comment as constructive criticism.
First, talks should be more controlled in time as all of them were too delayed. There should be a moderator who controls the time and who starts the round of questions. Second, there should be some more technical workshops or meetings where developers and artists could interact in order to open the possibilities of forming potential development teams. Third, next-gen consoles should be in any videogames conference, with some recent titles. Fourth, please, free WiFi! I would've loved to comment the talks on this blog with my laptop while being there, but I could only do it by Twitter using my data plan.
In any case, it's been a fantastic event that I've really enjoyed, and I'm looking forward to the next edition, the organization of which has already began!
See you!
P.S.: No, I didn't win anything... :( Let's try next year!!
Let's continue with the next day in Gamepolis. If you missed the earlier post about my Friday in this event, look it here.
The day started as usual: lining up to participate in the XBox 360 raffle (in the last post I'll tell you whether I won anything). And then, I went into the first conference, which consisted of the presentation of a game: Decadence, by Revolution System Games. The speakers, part of the development team, showed some images and videos, and explained that their main goal was to mix up several genres such as survival horror and RPG. This way we find quite dark, suffocating scenarios full with enemies and where characters can evolve. At the graphics level, the truth is that the result is pretty awesome if we consider that they developed the engine from scratch. Their main motivation for this is that they don't want to depend on external companies and want to decide on which platform to launch their games.
Figure 1 and 2.- The guys from RSG showing videos of their game Decadence.
Next talk was named 'Evolution of graphics in videogames', by Miguel Ángel Carrillo. At this point, the conference hall was completely full. I guess there was a high expectation for this talk, and I think that in general it didn't let the audience down. Beginning with Pong, and finishing with some of the most impressive last AAA's games, the speaker reviewed the most important milestones in graphics for videogames. Curiously, as the talk was coming to an end with the last games, I had an increasing feeling of seeing the same game once and once again, namely Call of Duty, BattleField or Medal of Honor. This is something that I had already reflected previously and was the motivation to ask the speaker during the minutes devoted to questions. My question was whether he had the same impression as me that, as the graphics improve, the gameplay usually gets worst. As I see it, the big firms in the industry are usually so competitive in the graphics corner that they forget putting the effort where this effort should actually be made: in the game experience, in the mechanics and the interaction with the player. I have the feeling that AAA's companies don't worry any more about creating original titles and gameplays, but they simply want to realistically reproduce how a building collapse in the middle of a battle. The speaker, in the end, admitted that this is true and that we must seek new ways of engaging the player. Fortunately, this is where indie developers have their piece of the cake.
Figure 3.- Graphics basically started with Pong.
I still remember how fun it was in spite of its simple mechanics!
Figure 4.- Mario's born in Donkey Kong. For those of you who don't know, this game was supposed to be based on Popeye's the Sailor, but they didn't get the license in the end and had to make up these characters. Thanks God they didn't get that license!!
Figure 5.- The audience burst into applauses when Doom arrived.
A great milestone in game graphics, no doubt!
Figure 6.- What can we say about Monkey Island? The speaker joked about how the movie
'Pirates of the Caribbean' should have been called...
Figure 7.- Very nice artistic work with Spanish stamp: Commandos 2, a tactical game that every person in love with strategy and tactics should try once in their life.
Figure 8.- Last games were in the direction of Call of Duty or this amazing Crysis:
graphics raised to their maximum power.
The next talk was 'Videogames graphics: art and profession' by Guillermo Tostón from U-Tad. I really liked this talk because the speaker gave the main idea that being an artist for a game only requires eagerness, motivation and, above all, getting down to work!
As the speaker said, you can decide whether you want to be part of this creation process or not, whether you prefer to stay in your place sleeping or going to a bar with your friends. Both are very valid options (and necessary from time to time). But in the end, you have to understand that becoming an artist for a videogame (or a programmer) requires making efforts and above all, enjoying the process rather than the result. This is a very important lesson: don't hope to enjoy the goal, but enjoy the path towards this goal. If you don't enjoy the path, if it only brings you suffering, then it's likely that you shouldn't be doing this. The speaker also made clear, in a funny tone, three things that every artist should include in his portfolio: a Dinosaur, an Audi and a terraced house. So you know... start by watching Jurassic Park again.
Figure 9.- 'A computer and a brush are the same thing'. The picture shows a beautiful analogy between a scene in the game Bioshock and the Sistine Chapel.
After this talk, I decided to walk around the place and visit some of the stands and shops that had been set up, where you could find some very nice and geeky table games, accessories, T-shirts, etc. The stands offered the possibility of playtesting some of the games presented during the event, such as Decadence.
The environment that you could breath was pretty interesting for any videogame lover: people gathering around players who participated in tournaments and enjoying the retro area. Regarding the tournaments, there were for different games: FIFA, NBA2K, League of Legends (LoL) or Call of Duty (CoD), to name just a few. As for the retro area, it was one of the most interesting area of the event, as you could play any of the old-time consoles, such as MSX, Amstrad, Amiga, etc.
Figure 10.- Gollum didn't want to miss the event in one of the shops.
Figure 11.- People could play some of the games presented during the event,
and talk to the developers while playing.
Figure 12 and 13.- The tournaments drew lots of attention from the audience.
Specially those of CoD (in the bottom picture) and LoL.
Figure 14, 15 and 16.- The retro area was amazing, with many old platforms that you could play with.
Precisely, the title of the next talk was: 'Daddy, why are we part of MSX?', a homage to this 8-bit system in its 30th anniversary. The speaker, Gaby López, talked about the history of this platform and conveyed a big passion in each of his words.
Next talk was a workshop on 'PixelArt', where the speakers, Toni Gálvez and Marco Antonio del Campo, explained what this technique was about and explained some software that was used in Spectrum times in order to design graphics. Pixel art is a technique to draw images in a pixel-by-pixel basis. Even when it's a very old technique, it's used nowadays by games to show a retro look, with some fantastic results as in the case of the highly acclaimed Fez. The end of the talk consisted of creating a floppy disk using the software Pro Motion, which also allows some basic animations.
Figure 17.- A floppy disk with Pixel Art.
Next talk was 'Artificial Intelligence Programming for Videogames', by Diego Garcés from Crocodile Entertainment. First part of the talk was devoted to explain how a game studio is organized and the different departments that exist in it: design, art, production, quality assurance, programming, etc. After that, the speaker explained that the role of the AI programmer is to create the behaviour of the Non-Playable Characters, and elaborated on how he must interact with other departments to achieve this goal: physics department for retrieving collision information, animation department to retrieve the characters animation, etc.
There are some important considerations to achieve a good AI: first, the player must always be able to win; second, the AI should be a fair challenge to the player, that is, the AI should never cheat (or at least, it should give that impression). As for the future, the speaker stated that something interesting would be to build player models in order to automatically test the game with different players profiles.
Among the techniques presented, we could briefly see that there were decision trees, A* for pathfinding or finite state machines. I will elaborate on some of these techniques in future posts, as I'll have to use them for the game I'm making.
After his talk, I made a question (yes, I made lots of questions during the event...). My question was about his opinion on the application of more academic AI research, such as Machine Learning or evolution algorithms, to the world of games. I also referred in this question to this earlier post on this blog, where I explained that the game Colin McRae Rally 2.0 used Neural Networks to train the enemies. His answer was that whereas they are interesting approaches, they're also dangerous because enemies can learn both good and bad things in terms of gameplay. However, he thinks we'll see more of these techniques in future games. As a curiosity, the speaker mentioned that the game Black and White used evolution algorithms.
The last talk of the day was given by Moritz Wundke, from Tragnarion Studios, and it was about 'Game analytics'. I really enjoyed this talk because I barely knew anything about this. The idea is that we can collect real-time information while the players are playing in order to improve the gameplay, correct design flaws and bugs or implement more precise matchmaking algorithms.
Figure 18.- The architecture of a Game Analytics system.
Technically, we basically introduce some instructions at some points in the game code in order to send certain data to a server. It's important this data to be raw, without any prior processing. The server will then process this data to extract some behaviour patterns of the players or for other purposes. Example of data are: number of items collected, number of deaths, the paths that players usually take in a particular scenario for producing heat maps, or whatever you want.
The speaker explained a particular case where thanks to these techniques a level design flaw was discovered. In the game Assassin's Creed, the player was supposed to follow a 2 hours path to climb up a tower and to use a zip-line before reaching the end of the level. However, analysing heatmaps of many testers, developers discovered that it was possible for one of them to use a shortcut and reach the end of the level in 5 minutes. This was due to a collision detection error in one of the walls.
The algorithms executed in the server side to classify and to make data significant are a bit more complex and they involve covariance matrices to detect correlations, Principal Component Analysis to reduce dimensionality and other maths mechanisms.
The talk finished by explaining how you could set up a free game analytics system by using open source software, such as Openshift to host servers in the Cloud and MongoDB as flexible database system, among others.
That's all for now. I want to finish with the following video where you'll be able to take a look at what I mentioned in this post.
I'll try to write the Sunday summary by this evening or by tomorrow. Hope you've enjoyed this long post and see you soon!
Edit: you can take a look at the Sunday summary here.
As I told you, this weekend I attended Gamepolis, a videogames event organized in Malaga, and I want to share my experiences during my presence there. In this post, I'll share my impression during the first day: Friday the 12th.
Figure 1. As soon as I arrived, I lined up to participate in a XBox 360 raffle
Even though the first presentations took place during the Friday morning, due to work I could only attend from 4.00 p.m. The first presentation was named 'Proprietary vs. Commercial Engines' by Gonzalo de Santos from Bravo Games Studio. The talk was basically an analysis of the pros and cons of using a proprietary, in-house made engine vs. using a commercial engine (e.g. Unity3D or UDK). This is an interesting issue and has to do with some stuff I already discussed in one of my first posts: how much abstraction do you need? I'll always advocate to use a high abstraction for those who are beginning or has a poor programming background. In these cases, going for a commercial, already-built engine seems to be the most reasonable approach. Creating a game engine from scratch is a daunting task that can keep people away from trying to make their first games, which is a very bad scenario. It can be a rich experience in terms of learning, but in general, I'd never suggest anyone to try it if there's no prior experience in making several games. Also, the level of abstraction that you may feel comfortable with might be different from the level of abstraction I feel comfortable with. You have to find the adequate balance. As I already commented in my case, I feel confident enough to go for a C++ programming environment even though I prefer to abstract away from lower-level technologies for the moment, such as OpenGL. This is why I use a multimedia library such as SFML. However, if you don't have programming experience, GameMaker will be a better (and as valid) idea for you to start off.
Coming back to the talk, a proprietary engine boosts the machine you're developing for, achieving the maximum possible optimization and performance for that specific platform. Also, you're in control as you don't depend on another company to fix bugs or to add new features. On the downside, as I just mentioned, it is a complex task where testing and debugging are specially hard, as you must make sure that any new feature added doesn't interfere with existing features. Also, one advantage of commercial engines is that they're usually well documented and have a community that supports it and willing to help you out.
The next talk was given by Paco Pérez, an experienced person in the industry, and the name of it was 'Games industry: present and future'. This talk was really nice, because the speaker yielded many objective and crossed numbers which provide insight on the workings of this industry. Among other issues, we saw with numbers that the biggest markets (with a huge difference) are EE.UU and Japan, and within the European ones, the UK. Also, the speaker envisions that the next-gen battle will be won by XBox One, as Microsoft has been growing faster than Sony in the console world thanks to XBox360, and also because Microsoft is a bigger and more consolidated company than Sony.
Figure 2. Games market data for different countries. C'mon Spain, you have to rise up!
More interesting data. The net income for every sold game for a company is around 18 € (out of 65 € that costs that game) if we subtract taxes, distributor discounts, platform royalties (what you have to pay to develop for a platform like PS4), and marketing costs. In his opinion, the business model is too expensive and must be changed.
Figure 3. More nice data about the evolution of each platform. XBox has been a great winner as it has grown really fast compared to PS3
The average player is 35 years old and can afford between two and three games a year. 55% of gamers are men, and there has been (especially thanks to Wii and NintendoDS) a growing market around women. In Europe, the countries where people play the most are UK, Sweden and Finland, whereas Spain and Portugal lead the countries with less players.
Relating this talk with previous one, Paco Pérez firmly stated how important is for a company to have a product, a technology (e.g. an engine), because this provides an added value that is highly appreciated, specially outside Spain.
The last talk I attended was called: 'Express Game Development', by two guys from Melee Studios (one of them is called Juan Francisco Campo; the other one I don't remember right now, sorry). They basically showed how quickly you can create a full-fledged 3D game using Unity3D, a game engine that provides support for most of the phases in the game creation: level editing, physics, audio and music, etc. Coming back to our initial discussion, it seems to be a promising option for those who are starting. However, if you want to create more interesting effects and gameplay, coding is still required. However, as I could see, the coding is made simple by means of scripts that are attached to each object in the screen. Basically, each object has an associated script with several methods you have to override, such as start() or update() methods that are called when the object is created and when is updated respectively.
The outcome of the talk, as you can see in Figure 4, was a quite fun 2 players war tank game.
Figure 4. A 2-players war tank game made in 1 hour more or less (yes, the assets such as the tank or the terrain were already built)
In this post I have summarized the first day in Gamepolis. I don't have more time right now, but in the next post I'll cover the rest of days of the event with more nice pictures.
