Jump to content

  • Log In with Google      Sign In   
  • Create Account

DekuTree64

Member Since 29 Aug 2000
Offline Last Active Oct 03 2015 06:46 PM

Posts I've Made

In Topic: Breaking out of a nested loop

27 July 2015 - 12:20 PM

If you've got two for loops you're looking at O(n*n) execution times.I'd be tempted to refactor the code and eliminate the for loops if possible but that's just me...

In all seriousness, I'd be interested to see that.

for(int i = 0; i < 100; ++i)
{
    if(((i / 10) - 1) == ((i % 10) + 1))
        break;
}
at least 1 is gone and we only need a normal break tongue.png

And suddenly the code is more complicated and about 10-100x slower, because the divisions are taking many more cycles than the other simple operations.

for(int i=0,n=0; n<10; n += ((i+1)==10), i+=((i+1)==10)*-9+((i+1)!=10)){
}
look ma, no division or additional branching tongue.png


Anyone else who is going to stop using nested loops at all?


Help! How do I break out of nested quotes??

break;

If you want to see a real masterpiece, look at page 3 or 4 of the comments here https://derpibooru.org/883523

In Topic: How do you write this down?

17 July 2015 - 10:29 AM

Two more versions smile.png These are not precisely equivalent to the original, because of the x != 0 condition instead of < or >. But if x is guaranteed to start off in the direction that it will reach 0 without having to wrap around the long way, then they should work.
int inc = 1;
bool (*f1)() = doA;
bool (*f2)() = doB;

if (v <= 0)
    inc = -1, f1 = doB, f2 = doA;

while(x != 0)
{
    x += inc;
    y += x - inc;
    z += y + inc;
    if (f1())
        f2();
}
int inc = v > 0 ? 1 : -1;

while(x != 0)
{
    x += inc;
    y += x - inc;
    z += y + inc;
    if(v > 0) { if(doA()) doB(); }
    else      { if(doB()) doA(); }
}

In Topic: Has anyone got a feeling of this when you were starting as game developer?

15 July 2015 - 05:10 PM

I feel like I'm cheating by not refining my own silicon to grow into crystals to cut wafers and make microchips to program my games on.


In Topic: Has anyone got a feeling of this when you were starting as game developer?

15 July 2015 - 08:04 AM

Excellent post, n3Xus smile.png
 

5) You realize that for almost every new gameplay feature you want to add you need to write a entirely new part of the engine.

Exactly. This is what "make games, not engines" means. Trying to anticipate everything you'll need just ends up making a bunch of wasted functionality.
Do the bare minimum to get stuff moving on the screen, and then write only what you actually need for this specific game.
 

6) Eventually you create a simple prototype for your game and you realize that you hardly even wrote any gameplay code, you mostly just added engine functionality.

Yep, this is another big one. Gameplay code is hard to envision, and under-taught compared to engine code. Small games like Pong/Tetris are easy, because everything just does what it does until some condition happens and the game is over. But in an adventure or RPG type game, you need some way of defining where enemies/interactable things are on maps, some way to control what gets spawned when, and how to control the game progression. A lot of the time it can feel pretty silly how simple it is... just place an object in front of a door, and when some variable is set, remove the object. But I would recommend starting early on this aspect of the game, to be sure that all the gameplay code you write can interact properly with the level data and game progression.
 

12) You stop working on your game because you lose motivation.

The nearly inevitable end to all amateur games tongue.png Anticipate it, and prepare yourself emotionally to muscle through it. IME, games tend to go in this progression:
1) Yay! Everything is clean and new, the possibilities are endless!
2) It's starting to get cluttered and it doesn't really do anything yet.
3) Miserable, endless code. More and more and more, for months on end, and it just looks like a random collection of features, not a functioning game.
4) All the main features are more or less done. Running out of time. Bugs everywhere. Fix bugs. More bugs. Why does it still not look like a game?
5) Wait a second, it looks like a game now? It's done? Yay!
6) If you have any time left, go beyond simply making it function. Add little finishing touches to make it really special.

 

...and that's if you have other people making all the artwork/level design for you.


In Topic: Outside simulator help for giant ping pong game!

14 July 2015 - 10:41 PM

Thanks Deku, it will be pretty cool cool.png

Like I said we are still in the spec stage where we try to figure out the best approach. An infrared LED would be a cool way to accomplish... do you think there will be any problems with range? Or signals dropping out?

At least if I'm understanding correctly, won't the players be staying within a set space? I think it would be pretty reliable, provided your lights are bright enough. Also if you go with belts, you'll have to account for arms going in front of them and blocking some percentage of the LEDs from the camera's view.

 

I'm not so sure about having the players wear electronics that might break when dropped or lose connection to their battery. Especially if they are to run around to get to the ball, looking at a screen instead of where they are running. I'd rather give them a helmet, stick some retroreflective tape on it and put a high power IR spot next to the cameras.

I don't think the players will typically be running into things or rolling on the ground or anything. Just running back and forth in an open space. But your idea of reflection is good too. No batteries needed then. Hopefully it would be bright enough. The more surface area you can get covered in reflector, the better. Fully coated helmets with camera above would probably be most effective, but may be a bit gross to share if it will be something that people cycle through playing all day, sweating from running...


PARTNERS