Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Servant of the Lord

Member Since 24 Sep 2005
Online Last Active Today, 01:06 PM

#5205092 Problem with SDL

Posted by Servant of the Lord on 18 January 2015 - 11:52 AM

Thanks guys, I meant to link to the post here where I explain the underscores, so I wouldn't have to re-type it out. Apparently I failed to add it my post. ph34r.png 
 
The version of the standard I have on my computer says:

"Certain sets of names and function signatures are always reserved to the implementation:
Each name that contains a double underscore__ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace." - (17.6.4.3.2 in draft version N3376)

 

So:

  • Don't start any name with double underscores.
  • If it's in the global namespace, never start names (variable / class / function / macro names) with an underscore.
  • If it's in a class or function or elsewhere, you can start with a single underscore as long as you don't follow it with an uppercase letter.

These three rules can be simplified and generalized as, "don't start variable names (or class names) with underscores".
The OP is technically safe, but unless he knows why he is safe, he's basically walking on a rickety bridge without knowing it.
I had intended to link to the fuller explanation - but I must've accidentally deleted that when I deleted my griping about explicit void parameters. laugh.png
 
Even if you violate the actual rules, 99.99% of the time you won't encounter any problems. I used underscore prefixes with uppercase letters for a long time before I found out it wasn't allowed.
It's just that compilers can potentially generate extra hidden variables and macroes in your classes and functions to help implement or optimize the generated code. If the compiler does this, and if it happens that you accidentally used a variable name that they are trying to use, you can run into problems. Most likely, you'll just get funky compiler-time errors about conflicting variable names (while only being able to see one variable in your code), but even so it's important to be aware of the possibility, as unlikely as it is.
 

im not quite familiar with passing reference, can you show me the code on on both your suggestion? thanks


Are you familiar with pointers? Pointers and references are almost identical in concept.
If I do:

int myVariableA;
int myVariableB;

Both these variables are different variables, holding different data. They are independent of each other. Even if I name them the same, they aren't actually the same.

But you can create a "reference" variable. A reference variable is creating a dummy variable that actually modifies the variable it is refering to. If I do this:

int &myReference = myVariableA; //The '&' sign means it's a reference variable.

This makes 'myReference' point at and represent 'myVariableA'. It is a second way to access myVariableA's data.
Any time you modify 'myReference', you're actually modifying the variable that it is refering to (in this case, 'myVariableA').

When you read myReference's value, it actually reads from 'myVariableA'. References are not copies of the variable, they are another way to access the same variable. References don't hold their own data, they read and write the data of the variable they are referring to.

If it is a const reference, then it can only read, but not modify, the variable they refer to. You may want to learn more about const variables and const member-functions - but I don't want to pile on too much information at once, so below I'll use regular (non-const) references.

To solve your current issue, you don't want two different texture managers holding different textures and not sharing information. Instead, you want one texture manager, and you want to give other classes access to that one texture manager. In this case, we can give other classes references to the real texture manager, and they can access the one texture manager through their references to it.

So Game can have the real texture manager as a member. Player (and other classes) can then take a reference to it in their constructors, like this:

class Player
{
    Player(TextureManager &_textureManager); //We'll pass the variable into the constructor by reference also.
    
    //...etc....

    private:
    TextureManager &_textureManager; //The '&' sign means it's a reference variable, so we'll own a reference instead of a copy.
}

And the constructor's definition can look like this:

Player::Player(TextureManager &textureManager) 
	: _textureManager(textureManager) //Assign 'textureManager' parameter to the '_textureManager' member-variable.
{
    
}

I know that looks kinda funny, because we have to introduce another feature here: member-initializer lists.
It's a special way of writing code that only applies to class constructors, allowing you to initialize the class's member variables before the constructor runs. I only bring it up because references (unlike pointers) must always be initialized when they are created, and can't be initialized after creation.

Game's constructor can now pass in a reference to Game's TextureManager to Player, when Game constructs 'Player'.

Game::Game()
    : _player(_textureManager) //Pass _player our _textureManager, so _player can store a reference to it.
{
   //...etc...
}

Now anytime _player uses its TextureManager reference, it'll really be using the TextureManager that it is referring to (in this case, Game's TextureManager). Player isn't creating an independent TextureManager, it isn't creating a copy either. It is creating a second representation of the same variable data.

 

Even though you use pointers, if you don't yet understand them, pointers and references are basically different ways of doing the same thing. Pointers can be changed to point to different variables later, but once a reference is assigned you never can to reassign them. Pointers can also be null (pointing to nothing) but references must always point to something.

 

There's one other issue I need to mention... (dry.png) Because Player is storing a reference to Game's TextureManager, you have to be absolutely positive that Game's TextureManager is constructed before Player's reference to it (otherwise you'll be referencing something that doesn't yet exist!), and you have to be absolutely positive that Game's TextureManager isn't destroyed before Player's reference is destroyed (otherwise you'll be referencing something that has ceased to exist!).

 

In this case, since Game owns TextureManager and Player, it can control what order they get constructed in.

In C++, classes construct their member variables from top to bottom. So here:

class Game
{
public:
	//...etc...

private:
        //...etc...

	TextureManager _textureManager; //_textureManager gets constructed first.
	Player _player; //And then _player gets constructed.

        //...etc...
};

That's something you need to remember if you reorder your member variables. Because '_player' depends on '_textureManager', '_textureManager' must be higher up the class declaration than '_player' is.

 

That's alot of information to absorb at one time. tongue.png

 

I glossed over and simplified some rules (just like I simplify the underscore rule), but note that everywhere I say "must", "never", "always", then those are code-words that mean that there are times where it is valid to break the "rules" that I mentioned, as you learn more about how C++ actually works, and that the "rules" are merely safe guidelines for the 99% of normal usage.

 

In C++, "never" and "always" are mere suggestions. wink.png

There are always cornercases where you can step outside the rules, for good or bad.




#5205015 Problem with SDL

Posted by Servant of the Lord on 17 January 2015 - 10:39 PM

First minor issue: You shouldn't start your variable names with an underscore. Variable names starting with underscores are reserved for the compiler.

 

Your real issue: You have two separate TextureManagers. smile.png

 

If I create:

int MyIntA;
int MyIntB;

...then those are two separate integers. Even if I give them the same name, that doesn't make them the same instance

 

The TextureManager called Game::_textureManager is not the same as the TextureManager called Player::_textureManager. Even if you name them the same, that doesn't make them the same. 

 

What you need to do is make the Player's TextureManager be a reference to the real texturemanager. Either you can pass Player a reference to the real texturemanager using the Player class's constructor, or you can pass in the reference to the texturemanager into the draw() function, like you do with the SDL_Renderer.




#5204865 What are the possible ways of making a level editor?

Posted by Servant of the Lord on 16 January 2015 - 10:35 PM

Would it be possible to make an image and let the program interpret that from a file

I've done that before, but using MS Paint to make maps for my game was a very annoying process, as it was hard to remember what the different colors meant when I had more than five or six.

or should I make a level editor in game? Is there any other way to make a level editor?

You can use a pre-existing one from the internet (and figure out how to import that editor's map files), create your own polished GUI editor (which can take many months or even years which could otherwise be spent on your game), or you can embed simple editing features in your game directly.

Imagine hitting a button like F12 to go into "editing mode". Then use the mouse to place objects, right-click to remove objects, and use keyboard keys or the mouse wheel to switch the object that you are currently placing.


#5204660 30k concurrent players on a (private) MMO server...is this possible ?

Posted by Servant of the Lord on 16 January 2015 - 02:35 AM

My initial plan was to use a smallish ( 50X50 ? ) maps for each 16-32 people or so, but wondering if I can manage a unified map (500x500 ? 1000x1000?) with a good implementation.

 

I used to be part of a hobbyist team for a small ORPG where we had >10 people on a map at a time (maps being 21x21), all spamming text as fast as possible as part of minigames. I wasn't the programmer, but I'd guess the code wasn't very optimized as we had more pressing priorities. And the server was at times even running off of a weak laptop over WiFi on a home internet connection. ('course we lagged like crazy when the lead developer and host of the game would be streaming live football games at the same time as hosting the server laugh.png)

 

This was 9 years ago. With better and more modern hardware, and intentional and calculated optimizations, I wouldn't be surprised if you could get 50+ players in a single screen without lag.




#5204655 Best First Project?

Posted by Servant of the Lord on 16 January 2015 - 01:41 AM

I am thinking that maybe I should practice a bit but maybe not. I am not a pro so I seek advice from those who know what they are doing. Should I practice by working on a fanmade game (yeah I know this is a very sensitive style of game design the only legal ones I see thus far to be openly distributed is touhou which is not an issue for me I like the art style) or jump right into my own series with no experience possibly wrecking any potential for story and plot and making a bad game.

 

RPGs in general (action or turn based) are not good choices for a first project. Much smaller games like Tetris, Asteroids, Pong, Breakout and other similar small are better games for learning the basics. I strongly recommend this.

 

That being said, whether you work on your own game using your own creatively artistic ideas, or a illegally steal the intellectual property of a money-focused corporation with teams of lawyers on retainer (tongue.png), the theme itself won't change the complexity of the game (n general), only the game design implementing the theme will change the development complexity. 

 

If you are worried about "wrecking" your own intellectual property (but for some reason you think a corporation will be happy with you wrecking theirs? huh.png), but still don't want to do the smart thing and work on smaller more reasonable projects for practice, you can create a "throw-away" creative idea for a standalone game, instead of immediately pursing your primary series right off the bat. Consider it practice in programming and game design, and use the knowledge you gain to refine your design for your eventual real series.

 

Also, polls aren't the best way to make important life choices. We're providing knowledge, but it's your job to transform knowledge into concrete intelligent decisions.




#5204136 Code appearance, is it really important?

Posted by Servant of the Lord on 13 January 2015 - 10:25 PM

Writing clean code is very important.

 

In my opinion, clean code is:

 - Easier for me to read in the future, when working on longer multi-year projects. I'm nearing year 5 of my current game project. The clean code really helps.

 - Easier for other people to read, if they are working on the same project, if I'm sharing code to help others, or if I'm asking for help.

 - Less likely to contain bugs, and easier for me to find and fix the bugs it does contain.

 - Likely to already be faster, and easier to optimize further if needed. I can always make clean code fast, but I can't always make fast code clean without rewriting it from scratch.

 - Doesn't really slow down my development time; most of my time is spent thinking what to time. The actual typing, and whether it takes more or less characters, is not my bottleneck.

 

It took some self-discipline (but not much!) for me to develop the habit of writing clean(er) code, but it has paid off greatly.

I don't always write clean code, and not every function is clean, but I have greatly improved the average quality of my code over the years. Even my worst code today is cleaner than my best code from before I made a conscious intention to become a skilled programmer.

 

Programmers are often taught that you can usually trade between the following: Speed and Memory

They are less often taught that you can also often trade Code Cleanliness, Stability, Development time with Speed and Memory as well.

 

One famous indie developer says, "Optimize for developer lifespan, not speed."

 

I'd tweak this around a bit to say that our goal should be something more like: Completing the project, with the desired polish and stability, while minimizing the frustrations, and reducing the development time.

 

Writing messy code is detrimental to all four of those, with the possible exception of the final objective.

Completing the project - Messy code can become so unwieldy that programmers can end up axing projects because it's too unmaintainable, and ruin professional games' financial success (because they are too buggy - though this is a result from already short development schedules).

Polish - Polish includes the desired framerate (and graphical/gameplay enhancements that require more frametime). Clean code is easier to optimize, and usually already faster. Messy code does not equal fast code - infact, usually the opposite is true. That being said, if you write a clean function, you can easily and consciously trade some cleanliness for intelligent speed improvements, when needed.

Stability - Messy code is often unstable code, hiding logic errors that can be hard to trick down, despite it "looking right" (because it's hard to see the messy mistake within the messy non-mistakes). 

Minimizing frustrations - Messy code often stabs you in the back months or years down the road. Don't trade today's ten minutes of laziness for next year's ten hours of labor.

Reducing development time - Clean code only helps here insofar as it helps track down bugs, creates less bugs, reduces mental complexity of the project, and so on. It only indirectly helps development time.

 

Mind you, this is my personal observations and speculation from my own hobbyist projects; not the result of scientific studies. I'm not a AAA developer working in the industry, nor do I have a PHD in computer science.

 
That being said, "messy code" doesn't necessarily mean the same thing in all contexts. "Mess" has different definitions in different situations.
Further, it is ultimately more important to actually finish projects. If clean code somehow gets in the way of you actually completing and releasing your work, then clean code takes a lower priority. However, most of the time, I don't think writing clean code actually hinders development. Some times, it might - but don't let the "sometime" be an excuse to not make skillful programming your default mode of operation, and your guidelines. Don't make the guidelines into unbreakable rules, but don't let their not being rules be an excuse to not follow any guidelines you yourself choose to put in place.
 
(About comments: Well-written code is self-commenting about what it does. Additional comments provide the details about why it does it. Alot of my code is commented, but not overly commented. When my code is clean, I feel there is a less need to comment it, except to document at a higher level what it's for. Clean code is not the same thing as "messy code with comments added to it").



#5204107 Calling static member functions on objects

Posted by Servant of the Lord on 13 January 2015 - 07:10 PM

Once again, I fell for the mistake of doing this, assuming that the function is mutating the object, when really it is just returning a result.

object.staticFunc(blah);

 

(It was third-party code, so I wasn't using my own function naming convention)

 

I know C++ permits this calling convention, but I'm not sure why. What's an example where this is useful?

Templates is the only thing I can think off. Something like:

template<typename Factory>
Blah DoSomething()
{
     return Factory().staticFunc();
}

 

My second question is, is there a GCC flag to make that an error? laugh.png




#5204080 When you realize how dumb a bug is...

Posted by Servant of the Lord on 13 January 2015 - 06:04 PM

Bullet::Bullet(..., Spritesheet *spritesheet, ...){
	this->spritesheet = spritesheet;
}

Spent a few hours on that. I wouldn't say the bug was dumb but more I that think I am too smart to do such errors. smile.png

 

Where's the bug here? I'm not seeing it. Sure, it should've used the member-initializer list, but even so this should still work. 'spritesheet' is local to the function,

and thus gets priority, and then 'this->spritesheet' is explicitly specified, so it should compile correctly to: (class-member)spritesheet = (func-local)spritesheet;

 

What went wrong?




#5202761 I have a game idea but..!?

Posted by Servant of the Lord on 08 January 2015 - 01:21 AM

Know my question is, will anyone buy this game?

 

Did people buy Dear Esther, Antichambers, and Gone Home? (Yes, they very much did)

 

Nobody can tell you whether your game will be successful or not. All we know is that other games weren't successful, and some games were.

 

You can increase the chance of success by making a really polished game. But "increase the chances" doesn't mean it'll be successful.

You can increase the chance of success by making the game unique and original. But that also doesn't guarantee success.

 

Is this a game you yourself would buy?

 

Also, I wouldn't price it at a $0.99. Either the game is worth paying for or its not worth paying for. If you sell it for a dollar, not only are you saying, "I think my own game is crap, but I'm charging you for that crap anyway". If you were competing on iOS or Android, you have to stay competitive with the market. However, on Steam and PC, prices have actually gone UP over the last two years, and this is actually good for the videogame market. Games like Dear Esther, Gone Home, and Antichamber now launch for between $15 and $25 - though they have frequent sales as well. These higher starting prices, coupled with sales at much lower prices, is actually a price-point that is economically viable for games (in my opinion).

 

Even if you just charge $5 for a game, that'd be better than $1. People who'll open their wallet for $1 are also likely to open it for $5, so you won't get that much more sales by pricing it at $1, but you'll need to sell five times more copies to make the same amount of money.

 

I'd make a quality game, and give it a reasonable price. $5 minimum, ideally $10 or $15. But it has to be worth it to the consumer. I don't want to sell them junk, even if it's $1 junk. Selling $1 junk is not just a waste of their $1, but it's also a waste of two or three hours of their life. I suggest you either make a project for learning, and release it for free, or you make a project that's actually worth gamers playing the game, and you sell it at a price actually worth your time in making the game.




#5202748 Decelerate a sprite

Posted by Servant of the Lord on 07 January 2015 - 11:26 PM

The graph is just for visualization. You store the point in time you are along the graph (the 'x' axis), but the speed (the 'y' axis) is calculated from the 'x' using the ease equation.

  • Suppose your entity travels at a max speed of 15 units a second.
  • Suppose your entity requires 2 seconds to go from fully stopped to max speed.
  • Suppose your entity needs 10 units of space to fully decelerate (i.e. it starts decelerating when it is within 10 units of its goal).

 

Entity begins moving:

//"Constants":
MaxSpeed = 15 units
TimeRequiredToSpeedUp = 2 seconds
DistanceBeforeSlowdown = 10 units

//Stored variables:
currentSpeed = 0 units-per-second
elapsedMovementTime = 0.0f

.

On update:

elapsedMovementTime += elapsedTime; //Add the new time that has elapsed.

//If we are in range of our goal, continue slowing down.
if(distanceFromGoal < DistanceBeforeSlowdown)
{
     //We'll use the distance to calculate our speed.
     float easeDelta = (distanceFromGoal / DistanceBeforeSlowdown)

     //Ease formula. Calculates the current [speed/transparency/whatever] from the easeDelta (0.0 to 1.0) using the formula.
     Var newSpeed = Ease(your_chosen_slow_down_ease_formula, easeDelta, 0, MaxMovementSpeed)

     //Just incase we didn't have enough space to reach full-speed:
     currentSpeed = std::min(currentSpeed, newSpeed)
}
//Otherwise, while we haven't yet reached full speed, continue speeding up.
else if(currentSpeed < MaxMovementSpeed)
{
     //We'll use our elapsed movement-time to calculate our speed:
     float easeDelta = (elapsedMovementTime / TimeRequiredToSpeedUp)

     //Ease formula. Calculates the current [speed/transparency/whatever] from the easeDelta (0.0 to 1.0) using the formula.
     currentSpeed = Ease(your_chosen_speed_up_ease_formula, easeDelta, 0.0, MaxMovementSpeed) 
}
/*else if(state = fullSpeed) //Not actually needed.
{
    currentSpeed = MaxSpeed
}*/

.

Something like that.




#5202431 Anyone know what API and library Pokemon games are built with?

Posted by Servant of the Lord on 06 January 2015 - 05:53 PM

I have intermediate knowledge of C++ and just began learning SDL because that's the most popular library I found on google wiht the most tutorials. Specifically, I am thinking of starting with a point and click game after learning SDL. The problem is I have no game development experience. Is SDL too low level of a method or should I go for higher level environments for basic 2D games, like point and click, such as the SDKs you suggested? I am doing this as a hobby for the moment. Also I have heard good things about pygame, is that worth looking into?

 

SDL or SFML are both great C++ libraries. They are low level, but not too low of a level, abstracting platform-specific code instead of higher-level game logic.

For 2D games with C++, I recommend sticking with SDL or SFML.




#5202344 Anyone know what API and library Pokemon games are built with?

Posted by Servant of the Lord on 06 January 2015 - 01:49 PM

Anyone know what API and library Pokemon games are built with? I am interested in making a game like pokemon, but I was wondering if they used API's or libraries that are publicly available.

 

APIs are used for things like physics, playing sounds, creating windows, receiving input, networking, and displaying graphics.

 

Most APIs typically don't contain game logic and game design. You can use entirely different APIs and make the same game, or you can use exactly the same APIs and make entirely different games.

 

Engines and SDKs like RPG Maker, Game Maker, and Construct (beginner friendly) or Unity, Unreal, and Source (more advanced), often contain more game logic than basic APIs. But even so, you still have to make the game - the SDK that Nintendo uses is only available to licensed Nintendo developers and costs serious money. Usually a requirement is that you have a secure corporate office so nobody can break in and steal the SDK. As for the engine that Pokemon uses, that's probably only available to the Pokemon developers themselves (GameFreak).

 

What's your goal? To play around as a hobby, or to make a commercial game to sell?

 

If you are trying to go commercial, you'll probably need to learn computer programming, which is a longer journey taking several years. You have to choose a language, invest work into learning that language (sticking with it for at least two years), while making smaller projects for learning purposes along the way before achieving your actual goal.

If you are just wanting to play around, try RPG Maker, Game Maker or Construct 2




#5202159 Copyrights to guns, vehicles etc

Posted by Servant of the Lord on 06 January 2015 - 12:02 AM

It's a weird issue of legal murkiness. Fictional books can mention specific brand names of weapons and cars just fine, so it's weird that games cannot.

 

While it may ultimately be proven fair use by higher courts, currently you need to pay licensing fees. EA tried with helicopters, and lost the lawsuit.

 

With the helicopters, EA settled. Seeing that EA deliberately invited the lawsuit to try win the freedom from not having to pay for those licenses, and seeing as EA has decently deep pockets and could withstand a long drawn out lawsuit, it is highly likely they only settled because they knew they were losing the case, and didn't want a permanent "No" on the court record (a "settled" lawsuit means the judge doesn't actually make a decision that becomes law, because both parties came to their own agreement).

 

Regardless of the greyness of the law, what's not ambiguous is whether or not you'll get sued. You will. The tank/helicopter/jet/car manufacturers have shown themselves to be willing to go after bigger developers in court to keep their licensing fees flowing. Likely, they won't bat an eye sending a lawyer after the small guys too, because while it costs you alot to get sued, they have their lawyers on retainer, and if they turn a blind eye to you it risks, over time, strengthening the case of the big guys once EA is ready for Round 2 against the gun manufacturers.




#5201404 Tiled map designer ?

Posted by Servant of the Lord on 02 January 2015 - 04:48 PM

For those kinds of maps, sometimes its easier to add map-making support to your game directly. By hitting a key combination, you go into "editing mode", and you use the mouse to place tiles. You can either have fancy buttons for selecting what tile to place, but you might end up wasting more time designing your editor than you do your game. Instead, you can use the arrowkeys to select what tile to place, and the mouse to place them where you want.




#5201088 First Game Guidance

Posted by Servant of the Lord on 31 December 2014 - 10:45 PM

Since you have already learned the basics of the language, I suggest jumping in and making a simple clone-game (Tetris), and then making a small custom game using one of your game ideas. Alternatively, making a basic "prototype" of your game idea, with the bare minimum of features and without much focus on graphics, with the intention that after three months you'll scrap it and rebuild it from scratch even better with more features and more polish using what you've already learned.






PARTNERS