Messages

1

SFML projects / Re: [Minigame] GoPlanets

« on: August 19, 2013, 09:42:34 pm »

Played it a little: really nice game :-)
I like how we can order several planets in the same time by just hovering them with the cursor. Tried it with 4 AIs with a lot of planets and I was completely destroyed in a few minutes, so I think I have to progress.

I imagine a lot of people already told you this, but multiplayer in this kind of game would make it really nice :-) But that also seems really tricky to do right...

2

SFML projects / Re: Nekoculus: a cat, a bullet and movement prediction

« on: August 19, 2013, 09:19:19 pm »

That was the surprise for adventurous gamers that went past 1024 in score :-)

The issue you describe is interesting... How did you compile it?
Normally, you should use:

Code: [Select]

.../Nekoculus$ cd Sources
.../Nekoculus/Sources$ make
.../Nekoculus/Sources$../Nekoculus
I can imagine that something went wrong if you built it yourself. There is an horrible hack in the code to find the resources directory (Resources/) and the game is expecting its executable to be called "Nekoculus" (Nekoculus.exe on windows) and to be in the same directory as the Resources/ folder. If it is not the case, it will not be able to find its resources. Next time I should probably think of a better way to find the resources directory :-)

3

Graphics / Re: I have a question regarding the best way to draw shapes

« on: August 18, 2013, 06:22:07 pm »

I took eXpl0it3r's advice and put together a terrible little test program.  Assuming I didn't make any mistakes, it should draw a bunch of tiny 10x10 rectangles on an 800x600 screen.  This one in release mode gives me 1,200 FPS, so I'm thinking I must have done something wrong in the original program.

I get 1200 FPS in debug and 1800 FPS in release mode.

Anyways you should not delete and recreate the whole vertex array every frame. sf::VertexArray uses a std::vector, thus whenever you call clear() it will also call clear() on the vector. So you're basically allocating and deallocating memory in every frame iteration, which is not the fastes operation and should be reduced to a minimum as much as possible. In fact you'll most likely even run into the issue, where the vector gets moved around in memory multiple times, because it's size gets too big, to hold all the data. Such a movement takes linear time, which will add up very quickly, especially if you do it every frame iteration.

According to the documentation, it does not deallocate the memory, so I don't think this can be problematic.

Still, if the vertices' positions never change, it may indeed be a good idea to create them only once and update the color when needed.

4

Graphics / Re: I have a question regarding the best way to draw shapes

« on: August 17, 2013, 11:42:52 pm »

I don't know if such FPS drop is expected (having to render a lot of rectangle should indeed make the FPS drop, but only 230fps is really surprising in my opinion). However, are you creating a new VertexArray every frame?
I think you should rather create your VertexArray once and for all before your main loop and just use VertexArray.clear() each time you want to reset it. That way, you won't reallocate memory for it each frame.

To summarize, I imagine what you are doing right now is:

Code: [Select]

while(true)
{
sf::VertexArray vertices(sf::Quads);
for(...)
vertices.append(vertex);
...
window.display();
}
... which could probably get slightly optimized if you switch to this:

Code: [Select]

sf::VertexArray vertices(sf::Quads);
while(true)
{
vertices.clear();
for(...)
vertices.append(vertex);
...
window.display();
}

5

Graphics / Re: Different behavior of sf::Text with SFML 2.0 and SFML 2.1

« on: August 17, 2013, 07:42:59 pm »

Just tested the fix: it works

6

Graphics / Re: Different behavior of sf::Text with SFML 2.0 and SFML 2.1

« on: August 17, 2013, 06:04:09 pm »

Ok, thank you

7

SFML projects / Re: Nekoculus: a cat, a bullet and movement prediction

« on: August 17, 2013, 05:08:26 pm »

Was doing pretty good for a while till the the bullet split to two and I freaked out (2745's my best atm btw)

Very interesting idea, as well as the implementation you mentioned above. Questions though... I presume the 67s is due to the 4096 cycle limit and that it's getting harder to calculate the orientation per cycle, yes? Then how do the game differentiate from a certain cycle repeated in the future? Say, I move constant left for 256 cycle early and turn up, then kept repeating it later on but instead of up this time I went down. Do you take the most recent, latest, or simply random? would be interested to find out (it'll also be beneficial in setting a new high score )

The probability of you doing twice the exact same cycle is extremely small (a human being is, in general, not able to achieve 1-frame precision on a 60fps game :-)). Still, if that were to happen, by looking at my old code, I would say the first one.
But, in real life, there will always be a small differences between several move cycles ; the game will then choose the one which matches better the one you just did. With your example, instead of having precisely several cycles of 256 'Up' followed by 'Left', you would have several cycles with something between 240 and 280 cycles of 'Up' followed by 'Left' for 2-10 cycles.

And also, do you ever consider dumping old cycle infos once the 4096 limit's reached? Kinda make it loop back to the beginning so new datas replace the oldest ones. It'll cause the overall prediction quality after 67s to be sub-optimal, but it should be sufficient to extend the game time.

When I started working on this, that is what was done. Each time I accessed memorized information, I did a modulo operation so it would loop. However, that increased code complexity everywhere and was a bit slower. As 67s is already long enough as it is, I just dropped it :-) But, I agree it would be better for a game that lasts more than one minute.

Lastly, why the eye? Freaked me out the first time

I love eyes, sorry

Again, amazing game!

Thank you!

EDIT: updated windows version, with mouse coordinates & mouse cursor in fullscreen fixed

8

Graphics / Different behavior of sf::Text with SFML 2.0 and SFML 2.1

« on: August 17, 2013, 04:36:37 pm »

Hello,

When compiling a game I wrote with SFML 2.1 instead of SFML 2.0, I noticed that text alignment was messed up. I then ran an experiment with a simple program :

#include <stdio.h>
#include "SFML/Window.hpp"
#include "SFML/Graphics.hpp"

int main(int argc, char *argv[])
{
        sf::RenderWindow window;
        window.create(sf::VideoMode(640, 480), "Manger");
        sf::Font font;
        font.loadFromFile("font.ttf");
        sf::Text text("Manger", font);
        text.setColor(sf::Color(255, 255, 255));
        text.setCharacterSize(60);
        sf::FloatRect bounds = text.getLocalBounds();
        sf::RectangleShape rectangle(sf::Vector2f(bounds.width, bounds.height));
        rectangle.setOrigin((int)(bounds.width/2), (int)(bounds.height/2));
        rectangle.setFillColor(sf::Color(0, 0, 0, 0));
        rectangle.setOutlineColor(sf::Color(255, 0, 0));
        rectangle.setOutlineThickness(1.0f);
        text.setOrigin((int)(bounds.left+bounds.width/2), (int)(bounds.top+bounds.height/2));
        text.setPosition(320, 240);
        rectangle.setPosition(320, 240);

        while(true)
        {
                window.clear();
                window.draw(rectangle);
                window.draw(text);
                window.display();
                sf::sleep(sf::milliseconds(100));
        }
        return 0;
}
 

Here is what I have with SFML 2.0:


And with SFML 2.1:


Am I missing something?
I never really understood bounding boxes with text, so I may be doing something wrong...
The rectangle is supposed to represent the bounding box of the text (and, hopefully, is precisely at the center of the window). With SFML 2.1, the bottom of the 'g' is cropped, and there is a small whitespace on the left of the 'M'.

I am using the SFML 2.1 precompiled binaries for Visual C++ 11 (32 bits)

EDIT: tested on Linux with git version versus 2.0 ; same problem.

9

SFML projects / Re: Nekoculus: a cat, a bullet and movement prediction

« on: August 16, 2013, 09:15:32 pm »

Very nice game
From 0 to about 2000 until the blue ball comes it's quite easy then it's challenging and at about 3000 it gets kind of impossible, because of 4 round AI's haha

Everything in the game sort of has to be in there, the 67 seconds, the eye, the cat, I like it, if things are a bit random

One "bug" I noticed: If you toggle fullscreen the cursor is visible again, which is not a big deal, but still not wanted I guess.
Thx for sharing

Thank you
I fixed the fullscreen cursor bug in the source tree. I can imagine that it is disturbing, especially when the native resolution of the game is 640x480, making the cursor horribly big.

So you're computing a discrete convolution of the current pattern and all past patterns. This is a signal processing problem; the convolution can be represented as (the inverse transform of) a product of fourier transforms in frequency domain, and using FFT you get a better time complexity. Furthermore, there seems to be a constrained algorithm which is even faster and simpler.

Just in case you're interested in how this could be optimized

Not really a convolution ; more precisely, I am computing Sum((AttenuationFactor ** k) * Distance(Memory[i+k], Memory[k]), k=0..255), which would be a convolution if Distance(x, y) was x*y and if AttenuationFactor was 1.
However, assuming x and y are angles corresponding to the directions the player took, I use Distance(x, y) = Sqrt((cos(x)-cos(y))**2+(sin(x)-sin(y))**2) = Magnitude(exp(ix)-exp(iy)). (but since I only have 8 possible angles, I have everything already computed in an array).

The advantage of doing so is that, if the player moves up then left, I will put more weight on a solution in the past with (Up, Up-Left) than on a solution with (Up, Down).

But, if I have Distance(x, y)=(x-y)**2, or if I just try to max the autocorrelation, then I can make use of this and I should still have a decent result. I will keep that in mind if I use the same kind of prediction method again, thank you :-)

10

SFML projects / Re: Nekoculus: a cat, a bullet and movement prediction

« on: August 15, 2013, 03:35:56 pm »

Thank you for your comments

It freaked me out a bit after a while of just running in circle it took me down super easily.
Very 'it reads my mind'/'it knows the future' feeling with 'I must think and do random things to confuse it' element to it.
Very fun thing to do for few minutes.

In the first few seconds, the ball is just plain stupid and is basically following you so you make a few moves so it can start learning your movements. Passed that, the real thing begins.
I could make it a little less dumb (make it assume in the beginning that you will continue in your current trajectory), but that would make the beginning of the game much harder, which would be really discouraging. It is better to let the player hope things will be easy for a few seconds

Interesting gameplay... How does the AI work? Did you implement the learning from scratch or did you employ established AI techniques?

I don't know if it's an established technique. Basically, I have an enum "Orientation" storing all possible movements (nothing, up, up-left, up-right, left, down-left, down, ...) and an array Orientation [4096]. Each game cycle I store the player's current movement in the table.
Then, in order to predict, I just take the player's last 256 orientations and try to match them with some other 256 contiguous orientations in the past (recorded in the array). Once I find the best match, the idea is just to assume that what you will do next is what you did next in the past after doing nearly the same moves. I wrote some documentation in french here, but I don't think it is clearer.
It works well, but it is extremely computation-extensive (complexity O(256 * Number of cycles spent in game)). In fact, the main reason the game will only last for 67s is because on my netbook (reference low-end machine), more will make the game start frameskipping. Second reason is because I think 67s really is enough for this kind of game

The source code is kinda messy. I consider this game as finished so I will only work on bugfixes, but if I had to redo it a lot of things would be different.

The eye animation when losing is also nice
By the way, you should probably forbid resizing the window, or map the mouse input correctly when resizing. And document that F enables fullscreen

Nice catch for the window resize I corrected it in the repository (and, in the same time, added a small README documenting the F key).

11

SFML projects / Nekoculus: a cat, a bullet and movement prediction

« on: August 15, 2013, 12:48:08 pm »

Hello,

A little while ago, I made a small game in C++ using SFML: Nekoculus. The goal is simple: you are a cat trying to escape a bullet and you must survive 67 seconds. You can move with the arrow keys. The bullet is slightly slower than you, but will remember every movement you make in order to predict what your next moves will be. To avoid collision, you will have to continually imagine new paths to confuse the AI.







Windows version is available here : https://www.dropbox.com/s/kmo1uz2co3u27xw/Nekoculus_R4.zip (4.5Mb). The game is using SFML 2.0, as text positioning seems to mess up when I use SFML 2.1.

Only problem is that I never managed to finish it (reached a 3500 score out of 4096), but this kind of game is more about always trying to improve the score than finishing it. But I believe it is theoretically possible to finish it :-)

This game is written in C++ and uses SFML for basically everything. The windows version is statically linked.

As it is quite simple, I now believe it would probably have been better to use something much higher-level, as 90% of the time I spent working on this game has just been for finishing touches (buttons (I had to write my own class for a rectangle with rounded corners), win/lose screen (especially the lose screen, if you reach 1024 score :-)), and making it run on Windows (I did it back when SFML 2 was in beta ; had to recompile SFML for windows under linux as I did not manage to do it in Windows...)). However, as the prediction algorithm is really computation-expensive, maybe it wouldn't have worked well.