Jump to content

  • Log In with Google      Sign In   
  • Create Account

Servant of the Lord

Member Since 24 Sep 2005
Offline Last Active Yesterday, 09:52 PM

#5271797 Best comment ever

Posted by Servant of the Lord on 19 January 2016 - 12:08 AM

PS: Sorry about necro'ing, I didn't see the date because it was tagged as "hot".

It's still active, so no worries. And if it wasn't hot enough already, your Mexican chili certainly does the job.

 

(I know, I know... that pun deserves a few downvotes, but it's worth it to hear your groans =P )




#5271792 Pathfinding and Databases

Posted by Servant of the Lord on 18 January 2016 - 11:01 PM

However, as I use a database as the source of all my game info storage,

Why?

Databases are a tradeoff. Does your game benefit from the pros of a database more than it suffers from the cons?
 

and my MUD has a huge number of rooms, storing all those nodes and edges and such in a database seems like such a HUGE amount of information

Have you calculated how much information it'll actually take?

i.e. How many rooms do you actually have? How many connections do you actually need per room? How much memory does each connection take?

Let's do some back-of-the-napkin estimates here.
I'm gonna guess you have less than a million rooms.
I'm gonna guess that each room has an average of 2.5 connections to other rooms.

I'm gonna assume you are giving each room a unique ID, and that that ID can fit into a 32 bit variable (maybe even 16 or 24 bits).
I'm gonna assume your 'connection' can be just be the ID of the room you are connecting to, and, maybe 32 bits of additional info (i.e. locked/unlocked, or whatever else). That's 8 bytes per connection.

(1 million rooms * 2.5 connects * 8 bytes per connection) = 20,000,000 bytes = 19,531~ KB = 19~ MB = not worth bothering about. You can keep that all in RAM, no problem. Is there some other consideration that makes this not an option?


#5271788 C++

Posted by Servant of the Lord on 18 January 2016 - 10:01 PM

I'm looking for some of the best online courses (paid of course) as well as books for learning C++ game programming. We are talking for a complete noob.
 
Any other efficient ways of learning are also appreciated.

 
I wouldn't pay for online courses. There's plenty of free resources online to supplement whatever books you pick up.

I'm very dubious about paid online courses. I see enough paid crap online that I tend to avoid the entire mess of it. Additionally, some major universities like MIT and Harvard put video-recordings of some of their full courses online for free.

Personally, I'd get two books: One heavy one to heavy textbook to read when sitting at the computer, and one more "fun" reference book to flip through while relaxing on the couch. I'd then supplement that with online tutorials and articles and by asking specific questions on these forums. As you grow (say, after six months or more), I'd pick up two more abstract books like Code Complete 2nd Edition and Pragmatic Programmer. But I wouldn't get those until after you finish you first two books.

This process worked well for me - in addition to actually programming, and lots of trial and error, and plenty of aggravation, and badgering this community for help. tongue.png

What two books you should get, I can't recommend, seeing that the books I used are now literally a decade out of date. All I can say is this: Any beginner C++ book you get really should be written within from within the past three years.

One thing you need to know now, different from when I started, is the difference between C++ in general, and "modern" C++. Modern C++ makes use of newer programming habits, and newer C++ features. You should be learning C++11 and later features (C++11, C++14, C++17), and be sure you are turning on those features in your compiler/IDE of choice.
There is alot of bad coding practices taught by older books that are just way out of date. Ofcourse, whatever code you learn, you'll write poor code for several years, and you'll get better gradually. Still, try to avoid getting poisoned by bad knowledge. I know this is hard, because you don't yet know what bad knowledge looks like. laugh.png
But by keeping to books written after 2011, that takes a great step forward in reducing your risk.


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

Posted by Servant of the Lord on 18 January 2016 - 09:46 PM

I actually didn't know Debug was supposed to do this, but in this case, it didn't.


It's not "supposed to", but sometimes Debug builds of various compilers do add features like initializing values to 0 or null to help detect bugs. Other times it accidentally hides bugs that are present in Release builds.


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

Posted by Servant of the Lord on 18 January 2016 - 11:10 AM

(I'm not sure how obvious it is what exactly happens here. I've only programmed using OpenGL and c++ on my own. Feel free to ask). 

 

m_VboID isn't initialized, so glGenBuffers(1, &m_VboID); might not get called, but since you were compiling in Debug mode, the compiler initialized it for you, hiding that the bug existed?




#5271498 C++ exceptions

Posted by Servant of the Lord on 16 January 2016 - 08:50 PM

4) the no-throw guarantee. No matter what, your function can never be involved in exceptional stack unwinding. This means that all the functions that you call must also provide this same guarantee (or they'll) infect your function. This one is hard to achieve in practice because there's no way to know if a 3rd party function may throw or not. Simply disabling exceptions at the compiler level magically bestows this guarantee on your entire code-base though smile.png

 

Including dynamically linked DLLs or system calls that were compiled with exceptions enabled?

 

What I mean is, even if you have exceptions disabled in your code, third party function calls can still throw exceptions and crash your program, right?

 

Take operator new, for example. People sometimes mistakenly think that disabling exceptions means that 'new' returns null on failure. In reality, even if you disable exceptions, operator new still throws exceptions on failure. Only if you explicitly use new (std::nothrow) does it return null.

 

And if you call third party code like an OS function call or a call from a DLL you're linking to, if that function throws, it'll still get thrown, not be caught by your application, and just be caught by the OS that launched your application, and pop up a generic dialog box saying something like "YourGame has stopped working".

 

So basically, if you disable exceptions, unless you only call third party (and OS) functions that are also Level 4, isn't your 'entire code base' only providing Level 1 guarantee?

 

</genuine questions>




#5271496 Responsive UI in compute-heavy games

Posted by Servant of the Lord on 16 January 2016 - 08:34 PM

Often in such games, the UI stalls while the game catches up. [...]
Why is that, and is there a way to avoid it?

Because it's the easiest to implement, and often is "good enough".
 

I know that your bog-standard desktop application, UI runs on its own thread and business logic runs on another (or several), with input being disclosed via events or some similar messaging construction.

As far as I'm aware, even with desktop applications, this isn't the case by default. You can make desktop applications multithreaded, but I don't believe they are by default.

I'm pretty sure both Win32 and Qt are singlethreaded unless you (as the programmer) choose to spawn more threads, but I might be mistaken about that.
 

Can this threading model be applied to games like the above?

Yep.

Actually, GUIs in games are usually alot simpler than desktop GUIs, and so where desktop GUIs cache alot of the rendering to avoid as much redrawing as possible, games usually just redraw everything every frame and only cache computationally-expensive things like text-rendering, because games usually have smaller (and simpler) widget hierarchies.
This isn't always the case, though. Take MMOs or larger RPGs for example: They have complex widget hierarchies that may need more caching then the average game.

If needed, you can multithread your UI in games as well. But (not being in the game industry myself) I'd guess, you'll just keep your UI on the same thread with the rest of your rendering, and instead spawn threads (or tasks running on worker threads) for whatever the "computationally expensive" thing that you're expecting to slow down the main thread. Slow AI and pathfinding and level geometry streaming can be handled on the separate threads, instead of the (relatively) fast UI code.




#5271324 Biggest game bundle sites?

Posted by Servant of the Lord on 15 January 2016 - 01:13 PM

I pretty much only buy from Steam, GoG.com and Humble Bundle

 

Steam and GoG aren't bundle sites, though.




#5271313 Use very large images, max texture size?

Posted by Servant of the Lord on 15 January 2016 - 12:03 PM

Is 2048x2048 size ok for most cards?

Yep.
 

Manually dividing into 1024x1024 would be a shore...

Use ImageMagick - it's a very widely used command-line tool that allows you to batch-process many complex image operations; I use it alot (in simple ways) for batch-processing my game's assets.
 
After installing ImageMagick on your computer, you want the 'convert' command, and want to use 'crop' (but without any specific position) to crop out each piece of your background into a seperate file.

 

I like to use ImageMagick in empty folders with only the image I'm working on, because it'll output dozens of new images from your background.

So create an empty folder, copy your background into it, shift+right-click on the folder in Windows Explorer and select "open command window here", paste in the below command, and hit enter.

convert MapBackground.jpg -crop 2048x2048 "MapBackgroundPiece.jpg"

Replace "MapBackground.jpg" with your background's filename. It can be .png or some other format if you want; and you can change the output filename ("MapBackroundPiece.jpg") to whatever you want - it'll have a number appended to the base filename for each piece that is generated.




#5271309 trying to think up a new way to level up

Posted by Servant of the Lord on 15 January 2016 - 11:44 AM

I wonder if a measure of not using an ability for an extended period of time would actually add to the experience. So you're not punished for using some skills often. But you are punished for not using other skills at all (after X days, for example).

That might be more enjoyable for players (or rather, less aggravating).

The reverse is sometimes also done. In some games, there are skills that the longer you go without using it, the more powerful it becomes. Usually it's more of a gimmick item and gets too powerful (i.e. you forget you had the ability, then when you use it you instantly take out half a boss's health), but I think both directions could be explored in more balanced ways as well.

Guardian's Crusade, for example of what I'd consider a 'gimick', had a skill that the more steps in-game you took, the more powerful it got, until you used the ability and it reset to 0.

Unrelated, but reminds me of 'Walk Armor' in Castlevania SOTN. The more of the game world you've visited (i.e. the more of the map you've uncovered), the more defense it got.


#5271216 trying to think up a new way to level up

Posted by Servant of the Lord on 14 January 2016 - 11:16 PM

The player gains points towards each primary stat, affecting secondary stats, while using skills affected by that primary stat, but loses points from other primary stats(something like I described earlier) causing the player to turn into a/an Agile/Strong/Intelligent/Balanced Character. So the players choose how they want to play the game and what role they will have in the game.


If you say that should make me better at bashing heads, sure I see the logic in that. But it doesn't sound very fun to become weaker at other abilities because of it.


Vagrant Story did something like that with their weapons. The more you use one weapon, the better you got at it, but then switching to another weapon (and sticking with it) gradually decreased your proficiency in everything else.

Or something like that - I haven't actually played the game myself. tongue.png

 

One thing I liked about Paper Mario was each time you got a new boot (happens ~3 times in the game), it changes your jump-attack action-test timings, throwing you off, and you (as a player) have to learn the new timings. This was great, because although the new boot significantly empowered you, it also gave you a little challenge (making regular battles more interesting) and slowed your full usage of that new power.




#5271167 sdl 1.2 class constructor doesn't work somehow

Posted by Servant of the Lord on 14 January 2016 - 05:07 PM

You are creating two different constructors:
Balloon::Balloon()
{
    velocityX = 1.2f;
    velocityY = 6;
    accelerationY = 0.1f;
    balloonWeight = 5.3f;
 
    //Set the collision foobox
    enemybox.w = BALLOON_WIDTH;
    enemybox.h = BALLOON_WIDTH;
}
 
Balloon::Balloon( int a, int b )
{
    enemybox.x = a;
    enemybox.y = b;
}
 
If you call Balloon(int a, int b), the other constructor Balloon() doesn't get called.
 
Balloon balloon1; //*only* calls Balloon() constructor.
Balloon balloon2(50,50); //*only* calls Balloon(int,int) constructor.
 
Instead, you should make your class look like this:
class Balloon
{
    private:
    //Its rate of movement
    float velocityX = 1.2f; //Or whatever a good default value is.
    float velocityY = 1.2f; //Or whatever a good default value is.
 
    float accelerationY = 0.1f;  //Or whatever a good default value is.
    float balloonWeight = 5.3f;  //Or whatever a good default value is.
 
    SDL_Rect enemybox = {0,0,BALLOON_WIDTH,BALLOON_WIDTH};
 
    public: 
    //etc...
};
 
Then create a single constructor that takes whatever parameters you want to give the balloon. Perhaps the position, weight, and velocity.
 
Also, make sure you give your function parameters, classes, functions, and variables, good names.
 
This is an example of bad function parameter names:
Balloon::Balloon( int a, int b ) // 'a' and 'b' don't make any sense. These should be named 'x' and 'y'.
Here's an example of bad class name:
//The foo
class Foo  //A 'foo' is a generic term that means "thing". Don't call your classes "thing", call them descriptive names like "Player".
 
Anyway, I'd make your class have a single constructor like:
Balloon::Balloon(int posX, int posY, float balloonWeight, float velocityX, float velocityY)
    : balloonWeight(balloonWeight), velocityX(velocityX), velocityY(velocityY)
{
    enemybox.x = posX;
    enemybox.y = posY;
}
 
Then you could do:
Menu mainMenu;
Player player;

Balloon balloon1(50,50, 0.5f, 1.2f, 2.0f);
Balloon balloon2(100,0, 0.7f, -0.8f, 1.4f);
 
After you get that working, then you can migrate to using std::vector for dynamically holding as many balloons as you want.
Menu mainMenu;
Player player;

std::vector<Balloon> allBalloons;
allBalloons.push_back(Balloon(50,50, 0.5f, 1.2f, 2.0f));
allBalloons.push_back(Balloon(100,0, 0.7f, -0.8f, 1.4f));



#5271132 sdl 1.2 class constructor doesn't work somehow

Posted by Servant of the Lord on 14 January 2016 - 03:07 PM

You need to post the .cpp file also, because that's where the bug is located.

 

We need to see every location you use "enemybox", because that's what you are having problems with.




#5271095 trying to think up a new way to level up

Posted by Servant of the Lord on 14 January 2016 - 12:40 PM

That was random laugh.png

But I see the point you're trying to make.

 

I'm a fan of war history, and that incident stuck out in my mind. tongue.png

 

The Halo devs mentioned similar ideas when designing Halo's gun system, with Battle Rifles (mid-range), Sniper Rifles (long-range), Shotguns (close-range), Rocket Launchers (slow but powerful), and Pistols (unbalanced mistake that was supposedly tweaked by someone other than the lead weapon designer without informing him shortly before the game was released).

 

The idea there is that each weapon has a different "environment" it better serves, and has different play styles.

 

That method works, and is one way of thinking about balance and variation and choice, but doesn't provide much room for player customization (i.e. making the player the weapon), so isn't a perfect fit for RPGs and MMOs. There's some commonality that can be gained from it, though.

 

Another example of great balance with a wide variety of choices is the huge amount of champions in League of Legends with different abilities and playstyles. But, also like Halo, this is more "make your choice and adapt your playstyle, but everything is reset at the end of the match", so again not a perfect analog with level progression in RPGs, but can still be useful in designing individual skills within skill trees.




#5271086 trying to think up a new way to level up

Posted by Servant of the Lord on 14 January 2016 - 12:00 PM

I personally like grinding, as a general idea, because it encourages people to use something and spend gameplay time on it, then rewards them with a useful skill based on the way the player likes to play the game. But the point is grinding is so bad in almost every game. Some give you too much reward for doing simple tasks which makes the skill worthless, and some others have a very boring mechanism and the grinding is based on the wrong thing and almost every grinding based XP system is spammable, meaning the player can do an easy task over and over again to level up.

 

Exactly. If the core "grind" isn't fun gameplay itself, the game has a problem. Fefw people complain when playing Call of Duty Modern Warfare that they have to play the same few levels over and over and over again, because the fun is gameplay based, not content-based. And "grinding" in CoD just means "playing the game".

 

It's also important to realize that CoD didn't reward players with (much) more power, instead rewarding them with more tools to play the game in different ways: it rewarded them with new gameplay.

Since there was limitations in what tools you can bring into a map, it was also rewarding you with more customization options. As the director of World of Warcraft mentioned, when referring to CoD's system, "Everybody seems to have very different build. Everyone seems to think their build is the best. At the end of the day, players are using a huge spectrum of different specs and choices. This system panned out better than [World of Warcraft] talent system worked out." (WoW (Blizzard) and CoD (Activision) is owned by different studios under the same company (Activision-Blizzard)).

 

Note: I'm using the Call of Duty: Modern Warfare series here as an example of a game with really well-thought out and balanced game design. I'm in not suggesting people turn their RPGs into FPSes or whatever, but I'm trying to learn from any genre when it does something right.

I'm not a huge CoD:MW multiplayer fan, except insofar as that I recognize the brilliance of its design. As proof that I'm not a huge CoD fan, I haven't played any of them for three years, and even when I did play them, I mostly played the campaign, and wasn't very good at the multiplayer. But I played it some myself, and sat for hours watching two skilled players play.

 

I'm not opposed to limited rewards of power, or limited subtractions of power, I just think I have to really analyze and assume by default that it's not the best solution, unless I prove to myself otherwise. A "design smell" as mentioned earlier.

 

One thing I'm mentally exploring is also the subtraction of power as the player plays the game, so as his real-world skill increases, his in-game skill decreases, thus the challenge also increases, making things (potentially) more enjoyable. Ofcourse, players don't like things getting taken away, so the presentation of it, as well as alternative reward systems, must be considered to make it palatable, since it flows contrary to the current language of games. A few games have done this, but very few, and I've yet to personally play any (other than the annoying "start off with all your equipment then lose it an hour into the game" trope. Grr, Metroid)

 

For example, the player can continue to increase in strength and new powerful abilities (rewarding with power), but his health or defenses could go down, so challenge increases as the game continues despite his new power (this is just an off-the-cuff example for illustrative purposes, not a thought-out balanced design, and thus not an actual suggestion).

Even better if those "powerful new abilities" are actually not more powerful, but more useful, by opening up new gameplay mechanics and decisions, rewarding the player with new options and mechanics, while also slowly increasing the difficulty to provide enjoyable challenge. No more disguised {Sword +1, Sword +2, Sword +17}, but Rapiers and Dirks and Zweihanders are all useful either in different circumstances, or else in different play styles. You can still, on top of that, have Rapier +2 and +3, but to a much more constrained degree, not only making things easier to balance, but creating more varied gameplay.

 

One of the reasons why the Israel was able to capture the Golan Heights from Syria in 1967 was that the Syrians' were trying to use long AK47s in very close-quarter tight bunker hallways, and kept bumping their guns against the walls when trying to turn around. Meanwhile, the Israelis had invented Uzi precisely for that situation: rapid burst guns that are held close to the chest, better suited to narrow hallways. But Uzi's aren't good with range. Different tools for different situations (the Syrians fought well outside of the bunkers though, but were unprepared for bunker-to-bunker combat).

 

[/disparate-and-unrefined-threads-of-thought]






PARTNERS