Messages

211

SFML projects / Re: Native Blocks Game (Download Available)

« on: February 26, 2015, 01:04:23 am »

Sorry to keep bumping my thread, but after taking a short break I came back and made some updates. The new major additions include:

• A sound and music system. Most of the sounds being used right now are just ones I found various places on the internet. I took a shot at composing the intro and gameplay music myself, though, which I've never done before. I'm not sure if I'm satisfied with the sounds and music yet, but at least I have the framework in place now.
• An updated AI system. I've made it much more flexible so that I can make more varied types of AI personalities. More importantly, it is now easier to make beatable AIs  . For this build I have created a Beginner AI, which the video below shows me playing against.
• Various minor bug fixes and improvements

Here is a video showing some of the progress. Not a whole lot has changed visually since the last video, so it might not be super interesting, but you can at least hear the sounds and see the new Beginner AI. Note that my screen recording software shows my mouse slightly lower than where it really is, so it looks like I'm not clicking buttons when I really am.



This time I didn't package up the new updates to distribute. I decided to wait and only do it if anyone is interested in trying it out, so the links I provided in previous posts are not up to date.

212

General / Re: Can't get SFML to work or install

« on: February 18, 2015, 11:26:28 pm »

Which tutorial did you follow? Was it this one?

 http://www.sfml-dev.org/tutorials/2.2/start-vc.php

You shouldn't need to install anything as long as the libraries are somewhere on your computer. It looks like that tutorial explains how to set up your visual studio project so that it can find where you put the libraries and includes.  What exactly isn't working? Compile errors, linker errors, something else?

213

General / Re: My window doesnt have a color

« on: February 18, 2015, 08:49:08 pm »

I'm not sure if this is directly related to your problem, but your gameloop seems a bit weird to me. Right now you are only clearing and displaying the window if an event happens. Perhaps you want something like this instead?

Code: [Select]

while(_mainWindow.pollEvent(currentEvent))
{
   if(currentEvent.type == sf::Event::Closed)
   {
      _gameState = exiting;
   }
}

switch(_gameState)
{
   case playing:
      _mainWindow.clear(sf::Color::Red);
      _mainWindow.display();
}


214

General / Re: Error with SFML game development book

« on: February 03, 2015, 06:57:08 pm »

Now i get a 2 duplicate symbols error with regards to category.o and command.o

This error means that you have something with the same name in two places. It is hard to say exactly what is causing that problem for you, but one of the ways this can happen is if you include the same header file twice. Make sure all of your header files have unique include guards so that they don't get included more than once. The book shows examples of this:

Code: [Select]

#ifndef UNIQUE_NAME_HPP
#define UNIQUE_NAME_HPP

// ...The rest of the header file

#endif

Also just make sure you didn't give 2 functions, classes, or variables the same name. Look through your code for any typos.

215

General / Re: Error with SFML game development book

« on: February 03, 2015, 04:54:03 pm »

I actually haven't ever read the book myself. I just followed the link in your first post and looked at some of the source files for chapter 4. I'm referring to line 18 in this Player.cpp:
https://github.com/SFML/SFML-Game-Development-Book/blob/master/04_Input/Source/Player.cpp

I was just thinking that if you typed the example source code manually into your own files you might have missed that. Though if you just copied and pasted the whole thing without modification then your problem might be elsewhere. Maybe someone who has read through the book will be able to help further.

216

General / Re: Error with SFML game development book

« on: February 03, 2015, 01:03:14 am »

This is just a guess based on your error message, but did you remember to make a call operator function in AircraftMover? If so, did you remember to make it const?

void operator() (Aircraft& aircraft, sf::Time) const

217

Graphics / Re: Bomberman's deplacement style

« on: January 29, 2015, 06:24:53 pm »

I think the language barrier here might be too large for us to really help you. This is my interpretation of your last post:

"If the player presses the Right key, the collision calculation uses the top right corner of where the player will be, which is more than they can actually move because the wall is in the way. Also, the player might press Down at the same time causing the bomberman to now be stuck on the wall...."

That's all I could understand, and I'm not even sure if it's accurate. What do you mean when you say you "replace him"? What you typed doesn't give us enough information to figure out why your bomberman is getting stuck on the wall.

Basically it sounds like you want to handle the case where the user presses Right and Down at the same time. All you need to do is handle those cases separately. Ask yourself "can the player move Right without colliding? if so move Right. Can the player move Down without colliding? if so, move Down."

Have you tried to understand Silderan's post from earlier? Maybe you could start by trying to explain why it doesn't answer your question.

218

Graphics / Re: Bomberman's deplacement style

« on: January 28, 2015, 06:06:48 pm »

if I'm not mistaken in bomberman the movement is aligned, i.e. the player will only stop walking on multiplies of X pixels.

This is likely true. I've only ever played one bomberman game before (Mega Bomberman), but in that game x is several times smaller than the size of the blocks. Meaning the player won't necessarily be perfectly lined up with the blocks (or openings) when releasing the movement button.

I think in bomberman if you collide with a wall it also moves him a bit on the other axis to fit to the opening right?

Yeah, if I'm understanding you correctly, that's what I was getting at in my previous post. If a player is trying to move into an opening, but is slightly not lined up with the opening, it will first move the player in the other axis until lined up. As you mentioned, giving the player a "bounding circle" and allowing the circle to slide around the corners of a wall is one solution to that problem.

Anyways, I've realized these aren't really the problems cChaD is experiencing. He is more focused on getting basic collision responses working, so I won't derail this thread any longer

219

Graphics / Re: Bomberman's deplacement style

« on: January 27, 2015, 05:25:21 pm »

I've worked on a Bomberman clone before and the movement can be pretty tricky.

 I don't know if you have run into this problem yet, but in the App Test screenshot you provided, what happens when the player presses left? The bottom of the player will clip the top of the wall and, without any extra logic in there, the player will not move anywhere. This can be a bad player experience because it can be really hard to line up the player with the hole so that you can move left. A more ideal solution would be if the player presses left and is barely hitting the edge of a wall like in your screenshot, you first make them move up until they line up with the hole, and then start actually moving left. This is what the real Bomberman game does.

However this introduces even more edge cases to think about. What if the player presses Left and Up at the same time? Do you make them go straight up or turn into the hole? I've found that I like prioritizing the change in direction (in this case Left) first such that the player can "zig-zag" though the level without the player getting frustrated with the controls. Again, this means you slide the player up a bit first such that it exactly lines up with the hole, then turn left instead of continuing on in the Up direction.

What happens in the player presses Left and Down? You need to recognize this case because you probably want to handle it different than the other cases I mentioned. You probably do not want to slide the player up first in this example. You probably want to go Down first.

And of course you need to also consider if you're clipping the bottom of a wall instead of the top. Also consider all 4 directions. Like I said, bomberman movement can be trickier than it first seems 

220

SFML projects / Re: [WIP] Native Blocks

« on: January 22, 2015, 07:13:01 am »

Windows 64-bit build now available! Download from the following link and launch NativeBlocks.exe to play (and see previous post for how to play)
Edit: Link removed due to being out of date.

I don't often develop on Windows, but needless to say it was... quite an adventure trying to get everything set up and building. When I finally got everything installed (mingw32, make, cmake, git, and who knows what else), I went through the process of learning how to build SFML, and all of my other dependencies. Luckily I eventually figured it out and got everything to compile and link! It was a (not very) fun surprise, however, to find that ming32w doesn't implement std::random_device on windows (well it's implemented, but it doesn't seem... well... very random  ). Anyways, long story short, I think I got all my Windows-specific problems worked out now. I guess it was a good learning experience.

I hope someone has a chance to test it out!

221

SFML projects / Re: [WIP] Native Blocks

« on: January 19, 2015, 03:25:17 am »

I finally got around uploading the game to dropbox so others can try it out  . Right now I only have a 64-bit Linux build, but my next goal is to get it compiled on Windows as well.

Anyway, You can download the 64-bit linux build from the following link: Edit: Link removed due to being out of date.

How to run
Extract the zip file and run NativeBlocks.sh within the Export folder. I don't know if this is the best way to distribute my game for now, but I included the SFML libraries inside the zip file so that computers without SFML installed can still run it. That bash script simply sets up the included library paths and then runs the game.

How to play
Right now the controls aren't configurable or explained anywhere in the game, so to navigate the menus simply use the mouse. When playing, use the arrow keys to move the blocks and 'z' or 'x' to rotate them.

I hope someone has the chance to test it out and let me know what you think  .  Let me know if you're able to beat any of the AIs  . Also let me know if you find any obvious bugs.

222

SFML projects / Re: Verboss game engine

« on: January 16, 2015, 07:28:57 am »

I downloaded the file from the Dropbox link and it had a log.txt file that had some.. well.. depraved things in it..

  Wow good catch. I'm thinking nurgle got his log files mixed up 

223

SFML projects / Re: [WIP] Native Blocks

« on: January 13, 2015, 04:59:32 pm »

This looks quite cool!

I wonder though, the Medium AI seems quite strong already, can it be still be beaten?

Thanks! Heh to be honest, even the Easy AI is a bit too hard. I've played the game tons of times while testing and I can only beat Easy every now and then. I plan on adding several more AI personalities, so I'll be sure make a least a few on the low end of the difficulty spectrum.

I do wonder, though, if the slow-down that occurs when the blocks split apart is intentional. It seems like it may distract slightly. Might just be me though

Thanks for the feedback! It actually is an intentional delay. It kind of felt weird to me without it, probably because the game I modeled this after also has that delay and I'm used to it. I plan on eventually making the blocks have a crumbling animation instead of simply disappearing, so maybe the delay due to the crumbling block animation will feel less distracting.

Edit: I originally thought Hapax was talking about when the blocks disappear, but I realized he might have been talking about when the blocks split due to one block falling further than the other. That is also intentional for similar reasons. It is due to the block transitioning from player control to gravity controlled.

224

SFML projects / Native Blocks - Finished!

« on: January 13, 2015, 08:24:46 am »

Hello everyone

I recently started working on my first game, and I think I've gotten it to a point where I can demo my progress so far! I'm not very creative with coming up with a good name, so I'm just calling it Native Blocks. It was inspired by the Puyo Puyo series of games, specifically the Sega Genesis game called "Dr. Robotnik's Mean Bean Machine". For those who aren't familiar with those games, the premise is that you have a playing area where blocks fall, similar to the style of Tetris, but only 2 blocks at a time. You try to make 4 blocks of the same color touch each other to make them disappear. This is a 2 player competitive game, so when you make blocks disappear, there is a good chance of a garbage grey block falling on the other player's side. The only way to get rid of the grey blocks on your side is by making a match that touches it. If you make a chain of more than 4 blocks then a larger number of grey blocks will fall on your opponent. If you make a combo, such that one chain disappearing causes the blocks to fall and make another chain disappear, it multiplies how many grey blocks get sent to your opponent.

Hopefully all of that made sense. Here is a video demoing it. Note that my screen capturing software makes the frame rate look worse than it really is:


I currently have 3 AIs implemented (easy, medium, and hard). You can either play against one of the AIs or you can simply watch the AIs play against each other, which is shown in the video. There are a lot more things I want to implement eventually, assuming I don't lose my motivation and move on to another project  .

Anyways hope you guys like it. Let me know what you think!

225

General / Re: [SFML 2.1] Sprite animation not playing

« on: December 09, 2014, 10:55:26 pm »

It isn't quite all I need to reproduce the issue. If it were, I would be able to copy it and compile it myself to see the problem. I'll make some assumptions to try and help you out further, though.

First I'll assume this code is actually inside of some loop and that currentx starts off as 4, and currenty starts off as 7 as you said in your edit earlier. The only way your sprite can move is if you make it into your if statement. So how do we get in that if statement...

Code: [Select]

bool less_x = animatedSprite.getPosition().x >= currentx*32.0;
bool great_x = animatedSprite.getPosition().x < (currentx*32.0)+32.0;
bool less_y =animatedSprite.getPosition().y >= currenty*32.0;
bool great_y =animatedSprite.getPosition().y < (currenty*32.0)+32.0;
That means animatedSprite.getPosition().x MUST be between 128 and 160 for the sprite to move, AND
animatedSprite.getPosition().y must be between 224 and 256. Is that true? Are ALL of those conditions met when you are trying to move x?

You didn't tell me what animatedSprite.getPosition() is, but I'll assume all of those conditions are met. Lets assume animatedSprite.getPosition() is (130, 255) and you are moving down.

Code: [Select]

animatedSprite.move(movement*frameTime.asSeconds());

What happens when movement*frameTime.asSeconds() is greater than one in this scenario? We'll overshoot the end of our tile at 256. Lets say it was equal to 2 so now we're at (130, 257). So far everything is OK because we moved the sprite like we wanted, but you'll see how overshooting is about to cause a problem.

Now lets say we want to move left by changing movement.y to 0 and movement.x to -1... UH OH we are not going to make it into the if statement because great_y will be false. we never changed currenty, so it is still 7. We're going to hit the else case this time. In the else case we'll decrement currentx forever but never touch currenty. The sprite will never move again.

Because you didn't post all of the code I have no way of knowing if you are protecting against a situation like that. But hopefully this thought experiment will help you debug further.