Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Arcade

Pages: 1 2 [3] 4 5 ... 16
31
General / Re: Several questions for a top-down/platformer hybrid.
« on: April 19, 2019, 07:46:24 pm »
Welcome to the forums  :). Though, in case you're not aware, the discussion on these forums tends to not be very geared toward general game design discussion. It's usually more focused towards discussing SFML itself. Like, how to use it, what are some good practices, etc. Specifically, you may have more luck asking about Box2D and how to implement destructible terrain elsewhere. I'll try to give some basic answers to some of your questions though.

1. It is hard to give an answer without knowing how complex your collisions and physics need to be. If you just need to check collisions between, say, the player and a wall, Box2D seems like overkill. SFML provides a basic way to see if one rectangle intersects with another. But, if you need your objects to do something like tumble through the air and collide in complex ways, then Box2D may be more appropriate.

2. I've never actually used it, but yes Box2D seems like a pretty popular choice when a game needs to incorporate advanced 2d physics.

3. Are you asking how to implement splitting your terrain into smaller squares, or if this is the best method to implement destructible terrain? I think splitting the terrain into smaller squares would be a fine start depending on your needs. You can then draw these squares with SFML's vertex arrays. Once you have something in place you can see what you do and don't like about it and then perhaps you'll have more specific questions you can come back with.

4. Can you be more specific with what you mean by "transitions" and "views" or provide an example of the effect your going for? If you mean you want to do something like a blur effect when switching between your top-down level and side-scrolling level, you could perhaps use a shader. I think there's an example of a pixelate shader that ships with the SFML sources. There was also someone on the forums recently that made a library that might help with what you want (though, I've never tried it).

32
SFML projects / Re: GunPoint Engine
« on: March 08, 2019, 03:51:39 pm »
What exactly are you needing help with?

If you're looking for someone to partner up with to help build your project from the ground up, you might not have much luck on these forums. I imagine many of the people that use these forums are already working on a project of their own. It may be hard to find someone interested in dedicating a lot of time to a large project outside of their control. You might have better luck on other forums more geared toward that type of thing.

However, after you get started, these forums would be a good place to come back to and ask about specific issues you're running into with SFML (or show off what you have so far  :) )

33
General / Re: Basic Joystick Help Needed
« on: February 22, 2019, 04:13:09 pm »
Several of these questions could be quickly cleared up by just giving it a try (assuming you own a joystick or gamepad of course  :) )

1.  The latter. "Joystick" is being used as a generic term for several types of devices, including the Xbox 360 controller you mention.

2. No they are not necessarily components of a single analog stick. As you can probably imagine, there are many types of joysticks/gamepads with various numbers of analog controls. Depending on your controller, yes some of them may go unused.

For example, the Xbox 360 controller has 2 analog sticks. Moving one of them left would probably correspond to a negative X axis value. Right might be positive X. Up might be positive Y. The other stick might use U and V instead of X and Y. The 2 "triggers" on the controller might also be considered analog, so might correspond to the negative and positive values of the Z axis.

3. There is no easy way to do this because the mappings are determined by the joystick's driver. Each joystick driver can assign logical buttons and axis numbers to whatever physical button or axis they want. Again, you can probably imagine many joysticks or gamepads that look quite different, so it would be hard for there to be a single standard for this. You will just need to test your particular gamepad and figure out what the mappings are. If you want to support more gamepads, the "simple" thing to do would be to allow the user to remap the controls themselves in a settings menu. Alternatively or you can get information about their joystick via sf::joystick::getIdentification() and try to incorporate a database in your game that already has the mappings for common brands of joystick.

34
SFML projects / American Football
« on: February 02, 2019, 08:24:49 pm »
A while back I posted in the Screenshot thread with a brief gif of an American football game I had started to work on. I've managed to continue working on it off and on since then so I decided to go ahead and make this thread where I can post some more detail for anyone interested. The game is far from done, but it feels like good timing since the real life football Superbowl Championship is this weekend.

The biggest challenge so far has been implementing the AI. The interesting thing about making a video game based on a real game is that there are pre-established rules that the AI needs to follow and they need to behave somewhat realistically. I don't want to fill up this thread with explanations of how American football works for those unfamiliar, but I'll try to give some brief descriptions of what my following gifs are showing.



A lot of these gifs are showing different game situations. The first one shows the offensive team on the left in white shirts throwing a quick pass to one of their receivers. The red lines show the routes that each receiver is going to run. The job of the thrower (quarterback) is to find an open receiver and throw them the ball.

Some of the players on the defense side in purple shirts have big yellow circles. These defenders are in a "zone" defense. The yellow circles represent the zone that they will try to prevent receivers from catching the ball in. The other defenders are either trying to tackle the quarterback while he still has the ball or are defending the receivers 1-on-1 in a "man" defense. In this case the receiver is able to catch the ball and gain 6 or 7 yards down the field before being tackled.

The small numbers above the players head and the small colored circles under their feet are just debugging information I have being displayed. They mostly represent the ID of the player and what behavior the AI is running.

(click to show/hide)

Part of my motivation for working on this game is that I've always wondered how sports games handle AI. I thought it would be a fun challenge to try and replicate it. The throwing aspect is one part that took me a while to get right. It's hard to calculate the direction angle, height angle, and speed the QB needs to throw the ball in order for the receiver to catch it on the run. The previous gif shows the QB just able to get the ball between 2 defenders so that the receiver can make a big catch. Sometimes the defense is able to crowd the receiver a little better resulting in an unsuccessful catch.

(click to show/hide)

There are also several kicking situations in American football, which I've been implementing. This next gif is a Field Goal kick where the team with the ball (in purple) tries to kick the ball between the goal posts for 3 points.

(click to show/hide)

In order to design these plays that I want each team to run, I've built an editor into the game. The next gif shows me designing the starting position and route I want a receiver to run. I then simulate the play which shows the receiver following the route, making a catch, and then juking the defenders for a big gain.
(click to show/hide)

The last thing I'll show off are some of the menu systems outside of the main game. These still need a lot more work aesthetically, but one of the important things you can do from here is set your "depth chart". This basically means setting which of your players you want playing at each position. Each player has different stats and abilities.

(click to show/hide)

The post is getting long, so I'll stop it here. The game still needs a lot of work, including a lot of planned AI improvements, but I hope to stick with it as I have time. The libraries I've been using to put this all together are just SFML (window, graphics, etc) and SQLite for the database backend to store information about each player.

35
General / Re: Storing Textures
« on: January 30, 2019, 04:09:08 pm »
sf::Sprite::getTexture() returns a pointer to a texture, not the texture itself. See the SFML documentation.

Also, you are masking your m_backgroundInit member variable by creating another variable with the same name in the constructor.

And your cpp file is using several variables that I don't see defined anywhere, like 'Background' and 'viewBox'. Are these defined as global variables elsewhere?

36
General / Re: How to make dialog boxes with sfml in a simple way?
« on: January 03, 2019, 05:53:21 pm »
The simplest way to recreate something like your attached screenshot would be to just use a sf::RectangleShape to draw the dialog box background, and then use sf::Text to draw the words on top of it.

If you need something more advanced than that you may need to be more specific with your question.

37
SFML provides functions to map between pixels and world coordinates.

sf::RenderTarget::mapPixelToCoords() and sf::RenderTarget::mapCoordsToPixel()

38
General / Re: How do I make a text box which only accepts numbers?
« on: December 07, 2018, 09:32:28 pm »
I may be misunderstanding your code, but why this
else if (regex_match(iNbr, isI))
 
instead of something like this?
else if (regex_match(e.text.unicode, isI))
 


Also, did you try out Laurent's suggestion for a simpler approach?

39
General / Re: How do I make a text box which only accepts numbers?
« on: December 05, 2018, 11:56:27 pm »
It isn't clear in your question whether or not your struggling to make a text box, or if you've solved that part but are now struggling to limit it to only accepting numbers. Can you provide more details on exactly what you're having trouble with and what you've tried?

To create a basic text box you'll probably want to draw a sf::RectangleShape to represent the box, sf::Text to show the text inside of the text box, and use events to know when the textbox has been clicked on (for focus) and to know when the user is typing something. You can specifically listen for the the sf::Event::TextEntered event and only process ones that contain a number.

Alternatively you could use an existing GUI library like Imgui, TGUI, or SFGUI.

40
General / Re: Smooth rotation of a sprite
« on: November 30, 2018, 06:43:09 pm »
Your code is changing the angle of the sprite in small steps between 0 and rotation+180 and then afterwards (presumably) drawing the sprite. You weren't very specific about what didn't work with your attempt, but my guess is that you aren't actually seeing the sprite move in small steps, but just seeing the final result. This is because you aren't drawing/displaying between steps. You are probably only drawing/displaying after the for loop when it has already completed the full rotation.

An example of what you probably want to do is:
1. Enter your game loop
2. Get the current angle of the sprite
3. Calculate the final angle you want the sprite to have
3. rotate the sprite a small amount towards the final angle (no for loop)
4. Draw the sprite
5. end your game loop

Each loop of your game loop will rotate your sprite a little bit and draw it

41
As the error mentions, you have not declared a 'myWindow' in the main function. In the main function you instead called your variable just 'window', so that's what you should be passing into windowHandler function.

The name of the variable you pass into a function doesn't have to be the same name as the that function's argument.

42
General / Re: Can't manage to have a clickable button.
« on: November 08, 2018, 04:53:39 pm »
Yes the mouse's position is a X/Y coordinate on the screen. That was my point. Why are you trying to cast it to a rectangle?

if (m_rect.getGlobalBound().contains(static_cast<sf::FloatRect>(sf::Mouse::getPosition())))

Also, the MouseButtonPressed event already contains the mouse's coordinates (as shown by your cout prints), so you don't really need to use sf::Mouse::getPosition(). Just use the coordinates that are given to you in the event.

43
General / Re: Can't manage to have a clickable button.
« on: November 08, 2018, 04:27:01 pm »
Why are you trying to cast the mouse's position to a FloatRect? The contains function accepts a point, not a rectangle.

44
General / Re: Problem with Event Keyboard Input
« on: November 08, 2018, 04:14:15 pm »
eXpl0it3r was referring to this loop

sf::Event event;
while (window.pollEvent(event))
{
   if (event.type == sf::Event::Closed)
   {
      window.close();
   }
}
 

You should be handling all of your events in here, not just sf::Event::Closed. Think about what would happen if multiple events came in at the same time (for example, keyboard press and mouse move). You will be looping through them and throwing all but the last one away. Only the last event will make it beyond this code.

Also think about what would happen if you didn't have any events come in since the last frame. event will be left uninitialized, but you are passing it along to your states anyway with whatever random data it contains.

I haven't gone through all of your code to see if this is directly causing your problems or not, but it would be worth fixing this.

---

Also
std::cout << "Pressed button: " << event.key.code << "\n";
 
Why not put this directly in the above event loop to see if you're ever receiving the Enter key event (don't forget to check type==sf::Event::KeyPressed first).

45
Graphics / Re: Problem with IntRect or setTextureRect
« on: October 24, 2018, 07:18:56 pm »
Ok, yeah your texture looks to be 319x424.

sf::IntRect rectSourceSprite(300, 0, 300, 400);
sf::Sprite sprite(texture, rectSourceSprite);
 

You're setting your sprite to be almost the same size as the whole texture.

Pages: 1 2 [3] 4 5 ... 16