Messages

1

General / Re: Game resolution dilemma

« on: February 01, 2015, 06:57:53 pm »

Why aren't you resizing it on the Resize event like your main view? Also your asking AFS for follow-up advice et you didn't even follow his advice from his previous post.

Have you tried debugging? Print out your numbers to see where things are going wrong, this way you can make an accurate assumption.

ex. If windowView.getViewport() is giving you the wrong numbers, you know where to start your fix.

2

General / Re: Game resolution dilemma

« on: January 29, 2015, 09:10:47 pm »

I may be wrong, but I believe he's refering to this post:

https://github.com/SFML/SFML/wiki/Source:-Letterbox-effect-using-a-view

3

General / Re: Smooth Movement

« on: November 10, 2014, 02:40:24 am »

As your game loop grows, the dt is going to get bigger and bigger, fluctuating a lot. You need to Fix your time step  http://gafferongames.com/game-physics/fix-your-timestep/

4

General / Re: laser event not working

« on: November 03, 2014, 02:54:28 am »

Have you tried putting it through a debugger and going step by step through the space press? Learn to debug, it'll save you time, and a lot of it.

My guess would be: if (isPlayerLaserActive [playerLaserChecker]==0) These never get reset back to 0 after a space press?

5

General discussions / Re: SFML tutorial video

« on: August 31, 2014, 02:13:42 am »

I got as far as noticing that you used:

#include "SFML/Graphics.hpp"

and then my mind exploded.

Don't you know, all the cool kids include everything nowadays, even if it's not even remotely touched. I deal with this at work on a daily basis... it makes me want to strangle someone.

6

SFML projects / Re: Vagante is now on Kickstarter!

« on: August 29, 2014, 02:12:09 am »

Awesome guys! This looks really fun. I'm also hoping to see more and more titles start to get pushed out there using SFML. Best of luck on your journey!

7

SFML projects / Re: BFF: a tale of two best friends against the world. [Update #4]

« on: August 27, 2014, 06:43:30 pm »

Another week and another few lines of code completed. Was a rather slow week due to prepping for my kiddos first days in school so not a whole lot of fun features were completed, but I'll give a rundown anyhow.

With the setup of some basic AI and collision completed I decided it was time to set up a proper entity manager and hierarchy system to manage the lifetimes of all my entities in each level. Entities consist of all persistent objects hanging around in the level. So far these only include characters, enemies, neutrals and summons, but later on I plan to add support for smashables/throwables as well.

With the basic setup now complete, going forward should be a breeze and it brings me one step closer to having a working demo of the first level complete. This actually leads me into some more design I hadn't planned for. How do I handle levels?

There are number of ways to I've considered doing this, although I havn't landed on one single decision yet.

-I've thought about using just massive levels, they tend to be simple, easy on the art and very easy to script. Player only goes forward and handles each event as they come. Also this tends to be much more resource heavy as I need to account for the entire level. (Think turtles in time, battletoads, etc)

-On the more dynamic side, I thought of doing each level as a series of 'rooms'. Although this does break immersion on outdoor levels, this greatly reduces the need for resources in memory as I can switch out what I need when loading that specific room. Also when it comes to scripting it would be a bit more difficult then massive levels, but still fairly easy.

-Of course there's always the idea of taking the previous two and mashing them together. Make it so outside is one long level and have branching rooms the player can go down. Increases complexity in almost every direction but adds more variety for the player.

-Branch away from only having a forward moving game, could I make the levels open explorable? Allow the player to walk back and forth, exploring their surroundings and looking for any secrets/alternative routes? At this point am I going too far down the road of scope creep and expecting too much for this game?

I still have a lot to decide, if you have any comments or ideas, don't be afraid to share. I always love hearing new ideas!



Meet two more new enemies for the first level. The SJW (Social Justice Warrior) and the White Knight!
Watch out! While they look relatively weak and harmless, these buggers tend to travel in packs and work in numbers. 1-2 might be no problem for any hero to handle, but should they call on for more help from supporters, their numbers can quickly escalate to unmanageable amounts.

8

Window / Re: Event KeyPressed and KeyReleased on KeyPress [Solved]

« on: August 26, 2014, 12:34:43 pm »

I always use a debugger, I stepped through the code, but for some reason my brain didn't pick it up. Sometimes you just need the second pair of eyes I guess.

9

Window / Re: Event KeyPressed and KeyReleased on KeyPress

« on: August 26, 2014, 03:47:15 am »

Holy... crap. Well that's what I get for over analyzing. Thanks for the quick reply! I knew it had to be something relatively stupid (I might be burning the candle at both ends)

10

Window / Event KeyPressed and KeyReleased on KeyPress [Solved]

« on: August 26, 2014, 03:29:59 am »

Hey guys, wondering if you guys could help me test something real quick. With the following code whenever I issue a keyboard keyPress, the key fires off both a key press and a key release:

(click to show/hide)

#include <SFML/Window.hpp>
#include <iostream>

int main()
{
    sf::Window window(sf::VideoMode(800, 600), "My window");
        window.setKeyRepeatEnabled(false);
    // run the program as long as the window is open
    while (window.isOpen())
    {
        // check all the window's events that were triggered since the last iteration of the loop
        sf::Event event;
        while (window.pollEvent(event))
        {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();

                        switch(event.type)
                        {
                                case sf::Event::KeyPressed:
                                {
                                        if(event.key.code == sf::Keyboard::W)
                                        {
                                                std::cout << "\n\nKeyPressed";
                                        }
                                }
                                case sf::Event::KeyReleased:
                                {
                                        if(event.key.code == sf::Keyboard::W)
                                        {
                                                //window.close();
                                                //break;
                                                std::cout << "\nKeyReleased";
                                        }
                                }
                        }
        }
    }

    return 0;
}
 

You can view my test results here:


Just the output from the code above, as you can see, every keypress fires off a KeyPressed and a keyReleased

This is keyboard only as joystick works fine.

currently on commit: d73418261b5aed44861ea66faaa4ef3d2589fc6a (exploiters nightly, visual studio 2012 32 bit June 20th 2014)

Any info would be greatly appreciated. Thanks!

11

SFML projects / Re: Circle Patterns

« on: August 25, 2014, 03:57:54 am »

the fill colors make it look that much cooler. Very nicely done.

12

SFML projects / Re: Circle Patterns

« on: August 22, 2014, 04:44:29 am »

gah, every time I get pulled in by the pattern, you clear it!

Pretty cool though, any plans for this?

13

SFML projects / Re: Bouncing Thingy v1.9

« on: August 21, 2014, 07:14:33 am »

Congrats on getting a working game, it's the first step of many to greatness.

As for your questions, is your code messy? sure, but is it stupid? Nah, I don't believe any functioning code is stupid, maybe less optimal, but never stupid.

Take a look into some proper design and read up on using classes and Object Oriented Programming. I believe proper design is the key to making a great game without wanting to throw your computer out the window. It'll save you hours of frustrations in the future.

best of luck! and also I like your menu text, looks awesome.

14

SFML projects / Re: BFF: a tale of two best friends against the world. [Update #4]

« on: August 21, 2014, 07:06:00 am »

Update #4 here (a day late, but it made it none the less)

So it was another AI week, and boy oh boy do I love AI. I've always had a passion for figuring out what makes the baddies tick, the mentality behind mobs and swarms and how to push the boundaries of making entities in games feel more real.

So far I've been using state machine for all my AI and animation needs, stack based FSM's to be exact and they've been working quite well. So I'm not too sure why, maybe it was the countless articles that were popping up on reddit on BT's, but I thought about switching it up to BTs to control my mob behavior. So I spent a few days and did my research and surprisingly there's quite a bit a good information out there.

BT's are actually quite cool and they certainly have a lot of merits, but in the end I decided to not go with them. What I realized is they serve a more specialized role and are amazing if you need to really conserve memory, but ultimately my stack based FSM system will allow me some excellent control over behaviors and debugging, albeit being much more verbose.

So while I wouldn't say the week was wasted, it was definitely much more relaxed. At the end of the week I decided to pick up the pace by beginning to work on the first boss in the game. I really enjoy working on the 'Corrupted Thug' named Todd - he's just that perfect level of douchebag mixed with badass and I feel the look is just right for the game.

A little info about Todd:
-Being the first boss, I wanted to make him challenging, yet simplistic in comparison to the rest of the challenges to come in the game. I decided to go with a Big, dumb, slow and a very strong boss. In the picture below you can see the size comparison to one of the main characters and he just towers over you. Feels intimidating and I love it.

-Todd's attacks will hurt.. a lot. This boss is about massive hits that are all meant to be avoided. With the starter characters, anywhere from 3-5 hits at full health will take you out.

Attacks will include:
    A ground slam (most basic attack) that hits directly in front of him.
    A Leap assault, watch his shadow to dodge the attack - aims for a random character
    Summon henchman - summons 1-3 henchman, based on total life left
    Tornado Attack - with outstretched arms, Todd will spin in circles and bounce around the screen, attempting to hit the players. His fastest attack (although not very fast)
    Charge - Charges at a player to attempt to grab them and deal a massive amount of dmg. Has a long charge to warn the player.

I might include more behaviors based on health remaining at a later date, but these are my initial goals I want for the Boss.



Thanks for reading once again, until next week.

15

General discussions / Re: Did you know that

« on: August 20, 2014, 04:01:12 am »

Took a look at the source code on the first video, he's only drawing 1 million particles, not sure where his math for 1 billion, but 100,000 x 10 = 1,000,000.

#define CHUNK_NB 10 // separating particles in smaller chunks to avoid having HUGE arrays (1 billion particles) : else we might face stack overflow or framerate drops. To understand the code faster, you can think that CHUNK_NB = 1
#define VERTEX_CHUNK 100000 // how much particles are in each chunk

for(int j(0) ; j < CHUNK_NB ; j++) // we convert Vector2f positions to the OpenGL's way of storing positions : static arrays of floats
{
        for(int i(0) ; i < VERTEX_CHUNK ; i++)
        {
 

I'll give it a try later, but I imagine trying to do 1 billion will cause a crash.