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 - Gobbles

Pages: 1 [2] 3 4 ... 9
16
General / Re: Very High CPU Usage.
« on: August 19, 2014, 03:16:39 am »
you should try implementing a fixed timstep, link here for you: http://gafferongames.com/game-physics/fix-your-timestep/

with just a simple timestep implemented, I'm dropped to ~13% cpu in my own game (down from about 98%)

then I added window.setFramerateLimit(60); which dropped me to below 1% cpu.

17
General discussions / C++14!
« on: August 19, 2014, 01:52:50 am »
Thought I'd toss a link in here for everyone to see:
https://isocpp.org/blog/2014/08/we-have-cpp14

Exciting stuff, I'm interested to see if any of the new features will be making it into SFML 3.

Quick Edit: Thought I'd add this wikipedia page which has the New Features nicely summed up
https://en.wikipedia.org/wiki/C%2B%2B14#New_language_features

18
Another week, another update.

First the pictures to capture interest:



Quick rundown, first we have the thug, our generic bad guy in the first level. He's got a mean punch but fortunately all his muscles are in his body and not his brain.

Next we have a few quick concepts, A beefed up Thug and the Thug Boss. You might ask why he's all messed up.. but that's secret for now.

So onto the main blog post. I've been hard at work getting all the components into the game and setting everything up. I'm on track right now to have the first level demo-able by End of September. That's my goal as of right now and hopefully nothing gets in the way of that.

This past week has been spent on setting up for the enemies. As of today I have started working on the AI for at least some basic enemy behavior. I think I have a basic concept for the thugs which I'll break down here:
  • Prepare
  • Seek
  • Assault
  • Retreat
  • Stumble

So here we have some pretty basic states.

Prepare: This is the enemies most basic state. Almost akin to an idle, the enemy prepares to attack the enemy, waiting and maintaining a short distance from the player

Seek: The Enemy seeks out the player, rush in, leads to Assault

Assault: The Enemy takes a swing at the player, leads to Retreat

Retreat: Used after an Assault, the enemy backs out back into Prepare.

and finally,

Stumble: Special state for when the player lands an initial blow/staggering amount of damage on the enemy, will allow physical attacks to gap close easier and allow ranged players to interrupt Assaults and special attacks.

That's all for now, hopefully soon I'll have a video up of player vs enemy interactions, if even at the basic level.

I'm no expert on this stuff, so if you see something that would work better, just shout it out, I'm always open to suggestions! Until next week.


19
I read over this, a large part of the general consensus was not enough cross platform support and issues with the internal opengl calls being outdated. I think someone also mentioned the lack of support for VBO's too.

20
Window / Re: Windows gains focus only at borded
« on: August 07, 2014, 06:53:17 pm »
I assume (hope) that this comment is intended as a bad joke.
In my experience the SFML team is quite careful about what they commit to the master branch and it is generally quite stable. They most certainly don't just throw everything in there and hope for the best.

Yes, it was a joke. Really is a no humor zone around here isn't it.

21
Window / Re: Windows gains focus only at borded
« on: August 07, 2014, 03:48:49 pm »
Also I think your logic is a bit backwards. 'Hacks' require you putting in code to deal with the problem, but you never really know what other systems they might affect, hence why they are a hack. The nightlies are at least tested by a multitude of people before and after they are posted, so they are to a degree stable, unofficially anyways.

Or maybe the SFML Team just throws all the code in there and hopes for the best.. you never know with those guys.

22
Graphics / Re: Problem with stars
« on: August 05, 2014, 07:25:17 pm »
I just wanted to toss an idea at you. Instead of constantly removing and adding stars, look into the concept of object pooling. Can save you a lot of trouble come performance time.

23
New concept art add in, let me know what you guys are thinking!

24
Window / Re: Change viewport to keep aspect ratio of scene
« on: August 01, 2014, 05:44:30 am »
I must've misread your question, but what this does for me is as I alter one dimension of the screen, the other dimension adjusts to maintain a 4:3 aspect Ratio. Coupled with a sf::Style::Resize in the window, this allows me to drag the window to whatever size I'm most comfortable with. What exactly are you looking for?

25
Window / Re: Change viewport to keep aspect ratio of scene
« on: August 01, 2014, 02:15:41 am »
just put something together rather quick, wonder if it's the same kind of thing your trying to do.
void Game::MaintainAspectRatio()
{
        //first we check our new aspect width to see if it changed
        float newAspectWidth = window.getSize().x;
        float newAspectHeight = window.getSize().y;
        if(newAspectWidth != currentAspectWidth)
        {
                //width changed, maintain the aspect ratio and adjust the height
                currentAspectWidth = newAspectWidth;
                currentAspectHeight = currentAspectWidth / aspectRatio;
        }
        else if(newAspectHeight != currentAspectHeight)
        {
                //height changed, maintain aspect ratio and change the width
                currentAspectHeight = newAspectHeight;
                currentAspectWidth = currentAspectHeight * aspectRatio;
        }
        std::cout << "width: " << currentAspectWidth << " height: " << currentAspectHeight;
        window.setSize(sf::Vector2u(currentAspectWidth, currentAspectHeight));
}

Where aspectRatio is always 4:3.

Edit: I should also mention that this gets called whenever theres a Resize Event.

26
Graphics / Re: Laser Beam
« on: July 31, 2014, 01:53:38 am »
Lasers are pretty simple in design. if you take a look here: http://gradius.wikia.com/wiki/Gradius_NEO?file=Gradius_NEO_Mega_Laser.png
You can see the gradius lasers.very simple design, they have a head texture (the little curvature of the laser) then they repeat the same texture for the entire length of the pre-generated length. Now if it's a constant beam like gradius/earth defense force, then you'll need to calculate it's length every frame and adjust it's size accordingly.

27
General / Re: Question about 2d sidescroller design
« on: July 25, 2014, 02:31:15 pm »
Really it's all a personal preference. For a simple platformer the origin isn't going to matter much, if at all. As long as it's consistent and your collision code takes into consideration where it's at, you could even keep it in the told left corner for all it matters.

My recommendation though is to not worry about the animations so much and get the platforming physics down first. This will give you a better idea of how the game will feel. Once that's in, setting up the animations will be a whole lot easier.

28
SFML projects / Re: Xaniria - Defense of New Earth
« on: July 18, 2014, 03:40:33 am »
I'm also quite confused as to the effects of construction mode and how it affects gameplay. I think the issue is your video doesn't show any gameplay affected by construction, or if it does, I really didn't see it at all.

29
//============= Update #5 Is here! ===================//
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.

30
Graphics / Re: Mario Jumping
« on: May 23, 2014, 03:11:39 am »
I'm not gonna lie, this is one big ball of a mess. Maybe you should start by cleaning it up a bit and better identifying your issue?

Pages: 1 [2] 3 4 ... 9