Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Noxil

Member Since 27 Sep 2010
Offline Last Active Private

#5167139 Code Review(?) C++ OpenGL

Posted by Noxil on 16 July 2014 - 06:22 AM

Out of curiosity, what is the benefit to doing it the other way. Is it for clarity, or is there another reason?

Id say for clarity.
It sure will make it easier to work with in the long run.

 

 

Use const for input parameters in functions that you know wont change.

Example "void UpdateWorld(const float deltaTime);"
For example in your planet constructor you have a int objtypes, thats a perfect case for where it should be const.
Const can be abit tricky to see the point of in the beginning. But for me, its really great. It makes the code more clean and it prevents mistakes.

 

 

That's not the best example though, since deltaTime is already copied by value (so const here might have some meaning to the programmer such as "there is no reason to ever modify the deltaTime variable inside UpdateWorld" and some people like to do it for this reason, while others think it's ridiculous, but it can't possibly affect the function's behaviour). There is no real consensus on this use of const.

 

You are correct Bacterius, it was a bad example. Thanks for clarifying.




#5167101 Code Review(?) C++ OpenGL

Posted by Noxil on 16 July 2014 - 03:04 AM

Hey great work, i just briefly looked over main.cpp and planet.cpp.
And what caught my attention from the get go was functions like, SoftCollide, HardCollide, ObjClicked etc etc. Instead of sending in the object you want to operate on you are sending in the index. I would recommend sending in the object directly. So it would look something like this "void SoftCollide(Planet * planet);"

 

And i would also like to point out the usage of const. I understand it might be a hot topic where each person have his/her own idea of whats best.

But id like to suggest to try it out.
Use const for input parameters in functions that you know wont change. 

Example "void UpdateWorld(const float deltaTime);"
For example in your planet constructor you have a int objtypes, thats a perfect case for where it should be const.
Const can be abit tricky to see the point of in the beginning. But for me, its really great. It makes the code more clean and it prevents mistakes.




#5089222 Making AI, Decisions for logic on 2d tiled map

Posted by Noxil on 26 August 2013 - 11:19 AM

Sure the game will take some performance hits if all units at all time is checking for food, water etc.

 

Im sure there are loads of interesting techniques to optimize ai for such behavior. But on simple thing

one could do to optimize if there are lots of ais in the game world.
Is to do something along the lines of this:

void Unit::updateTickPriority()
{
    float squaredDistanceToPlayer = player->getLocation().squareDistance(location);

    if(squaredDistanceToPlayer < squaredDoubleScreenRadius)
    {
        tickPriority = TICK_PRIORITY_HIGH;
    }
    else if(squaredDistanceToPlayer < squaredDoubleScreenRadius * 2.0f)
    {
        tickPriority = TICK_PRIORITY_MEDIUM;
    }
    else
    {
        tickPriority = TICK_PRIORITY_LOW;
    }
}

So the point of this function would be to set a tick priority.
Essentially saying, the  further away an ai is from the player, the less frequently it will receive tick calls.

This however can and will create some other problems depending on how you would like things to be and act.

Just to keep it simple, if a spider is really far away and gets the low priority. It would move really slow and wont cover as much land as someone close to the player would.

void World::tick(float deltaTime)
{
    // update all world units
    for(int i=0; i<units.size(); ++i)
    {
        if(units[i]->shouldTick())
        {
            units[i]->resetTickCount();
            units[i]->tick(deltaTime);
            units[i]->updateTickPriority();
        }
    }
}
bool Unit::shouldTick()
{    
    ++tickCount;

    switch(tickPriority)
    {        
        // always tick        
        case TICK_PRIORITY_HIGH:
            return true;
         
        case TICK_PRIORITY_MEDIUM:
            return tickCount > 10;

         case TICK_PRIORITY_LOW:
            return tickCount > 20;
    }
    return false;
}

Just to reiterate, its a very simple optimization.
It has it share of flaws depending on how you want ais who are far off screen to act.

But its easy to implement and its dynamic and will work for all ais who inherit from the same base class.

 

Im sure if you where to dig deeper into entity management and updating world entites you could find all sorts of interesting techniques and methods to handle large amount ais and what not.
But what i have presented here is a simple method to gain some performance (if the performance loss lies with to many units are getting updated that is),

 




#5088962 Making AI, Decisions for logic on 2d tiled map

Posted by Noxil on 25 August 2013 - 01:20 PM

Hello.

 

One thing that came to mind, its very simple but it will help.

Dont do all the checks every frame.

 

There are several different ways of doing this, either by creating some timer and callback system or by simply
using a counter.

The later being the easiest and fastest way to see if it will help boost performance.

In your unit class you could have something like:

void Unit::Tick(float deltaTime)
{
    if(frameCounter > updateRange)
    {
        frameCounter = 0;
        UpdateBehaviour();
    }
}

Where of course "UpdateBehaviour" would check the surroundings and decide what to do next.

As you can see its very simple, straight forward.
Instead of checking every frame you only check every X frame.

 

One thing to note here.
Lets say you have 100 units, they all use this type of code.

If they are all created on the same frame and they all start their frameCounter at 0.

Then every X frame you will get a spike in performance, since they will all call "UpdateBehaviour" at the same frame.

So, it would be nice to add an offset in the constructor: 

Unit::Unit()
{
    updateRange = 3;
    frameCounter = rand() % updateRange;
}

In this example i used 3. It may in fact be very low.

Lets say your game runs in 60 FPS.
That would mean that during one second your units would do 20 checks.
Perhaps 10 would be a better, that would equal to 6 checks every second.
To find what suits your needs best, you will have to do some trail and error smile.png

 

Hope it helps




#5084517 What's your opinion on Game Makers?

Posted by Noxil on 09 August 2013 - 04:28 PM

Like the posters before me have said.
Not everyone is a programmer...

 

But id like to put some focus on the whole drag and drop issue here...

Do not under estimate the work people put in with tools that is "simple" utilizing drag and drop functionality.

Taking Unreal Engine for example.

On one of the previous projects i worked on we had one person mostly dedicated to working in their Kismet.

Kismet is a tool used to setup logical chains of events in the game world. It basically functions by drag and drop.

As a spectator it may look easy.

But trust me, it takes dedication, skill and true cleverness to pull of some of the things you can do with these tools.

 

My opinion on game makers is that they are great.

If Game Maker for example can get someone curios about game development thats superb. 

Some people are perfectly happy to make smaller games and dont want to devote their time with programming. Perhaps they are more interested in the art side of game development, then Game Maker is a great choice.

And im sure that it have and continues to serve as a starting platform for people who wants to learn more on how to make games.




#5082188 Crashes while writing to file

Posted by Noxil on 01 August 2013 - 06:34 AM

Ah dang, thanks for the reply.
While i was trying to break it down it just poped out.

 

I forgot to check for a null pointer.

Damn... Been looking over the code so many times and overlooked it every single time.

 

Thanks! smile.png
It now works properly.




#5079540 Ambition, starting from ZERO

Posted by Noxil on 22 July 2013 - 05:08 AM

As the posters above have stated, crawl before you can walk smile.png
Start small and grow bigger.

 

Of course, you should aim high and have big dreams.

But since you are new to programming you really should start small.
 

This is how i started learning programming.

I had heard and read that the most popular language at the time for game development for the bigger games was C++.

So i decided that was the language for me.

Like loads of people my first idée for a project was a massive game, in this case a fps.

But as i started up Visual Studio 2008 (program used to compile (build) C++ applications) for the first time i quickly realized, this is gonna be hard.

 

I took to google, and started searching for "how to get started with Visual Studio 2008 C++". 
To my disappointment all tutorials on beginning with C++ was introductions to variables, functions and classes. I was expecting more in the terms of "how to make a rocket launcher" and such cool things smile.png

 

And that was when i realized that okey, i can have a dream project. It can be this massive fps game, but it will have to wait until i have acquired the knowledge to make such a game.

 

So, it dosnt really mater if you are going to use an existing game engine or if you are going to start from scratch.
Knowing the basics of your language of choice is invaluable, you wont be able to go far without knowing how the simple stuff really works.

 

So, i would recommend starting really simple.
Lets say you chose C++.

 

If you are on windows you can download Visual Stuido 2012 (scroll down until you find Visual Studio Express 2012 for Windows Desktop)

http://www.microsoft.com/visualstudio/eng/downloads

 

Then to get you started go through the tutorials on this site (or any other beginner site that you feel comfortable with)
http://www.cprogramming.com/tutorial.html

 

When you have done the basics at least once, try to make a text based game.
When you have experimented with text based games for a while i would recommend two things.

 

- Try to find out how to make a window and how to add buttons to this window.

- Try using a existing game engine

 

At this point, when your are giving these a try you will understand that no matter witch one of these you chose, its gonna require alot of work and alot of reading to understand how things work. But im certain that when you get to this point you will know what you need to do in order to move forward. It sorta comes just by itself.
For me it was, "how do i draw something on the screen", "how do i move towards a point", "how do i receive input from the keyboard" etc etc. You get the point smile.png

This is what worked for me, im not saying you should follow this to 100%, but it might be worth a try.

And also, be patient, learning programming will take time, dont give up if you get stuck. Take a break, ask questions and keep pushing forward. smile.png
 

 




PARTNERS