Jump to content

  • Log In with Google      Sign In   
  • Create Account

Zouflain

Member Since 12 Jan 2007
Offline Last Active Mar 01 2014 11:19 AM

#4996042 Are open pvp + full loot SANDBOX mmorpg's still possible?

Posted by Zouflain on 31 October 2012 - 08:05 PM

*Sigh* this thread again. Forgive me if I get a bit testy, but there's some obvious falsehoods that keep getting repeated. I don't mean to pick on you, Exodus, you're just the last person who repeated some of them. I may say "you" but I mean the people who keep making these arguments despite blatant evidence against them.

The point here is trying to create game with open pvp, that would actually work.

Full open PvP from the start, would mean that u would die immidietly.There would be someone next to u, as u started the game just killing new players as they entered.
Before the game would load u would be dead.

Unfortunately this is just patently wrong, and it's not difficult for a full anyone/anywhere pvp game to remedy this. I mean no offense, but it really seems like you haven't investigated the actual mechanics behind the variety of games (past and present) that have had exactly such a system and have not involved dying immediately. Eve Online, for instance, allows you to target someone the moment they enter space in their poor little noobship and instapop them with smarties (that is, kill a nooby the very first second they're in space in the super-high security zone), but this doesn't often happen. Why? Because the game makes it financially silly to do such a thing and, doing so is typically more profitable for the noob (who can respawn and loot your wreckage) than you. Good design mitigates griefing and does not require you to lose anyone/anywhere pvp.

In a game with truly open pvp, permadeath and full loot, attacking a noob would be devastating if there were just a few guards around who attacked aggressors (ala Eve's Concord/sentries, or Darkfall's guards). The noob loses the time it took him to load up. The idiot griefer loses all the gear it took him to get to where he was.

In this setting there is no character progression, or at the very best an unfair character progression, because those ppl who started the game in pre-launch would have a progression advantage over everyone else.

Not really. In general, it's not the beta or pre-launch players who lead in character progression, it's those with a lot of extra time on their hands (for instance, I was a GW2 pre-launch player and I still have yet to hit level cap) or those who are more efficient if it's a grind based game. In games without progression, like almost every FPS out there, then players are naturally divided into categories by skill/experience. Neither set up is inherently "unfair."

And ironically, it's the pre-launch players who write the guides for all the post-launch players to follow, and by doing so, drastically improve their efficiency. Pre-launchers are actually at a slight disadvantage, because they have to discover everything by trial and error without anyone to tell them "don't bother doing quest X, it takes 16 hrs and gives you 0.2 gold."

The point is there has never been an MMO that FOCUSED on world pvp

Darkfall. Haven and Hearth. Eve. Dear god the dev blogs on Eve go on and on about how integral blowing each-other's faces off is to the economy. And the economy! It's like Adam Smith's wet dream. Stop making these statements, please. Please?


#4995890 Affecting the actual player as an alternative to affecting the playable chara...

Posted by Zouflain on 31 October 2012 - 11:36 AM

The worst design decision a company can make is frustrating players. I say do not make mechanics that are intended to be frustrating, especially if they are able to be exploited by other players. It's one thing to be challenging, it's something else entirely to be frustrating. In the online world, this gets amped up because griefing is such a series issue in games, and you would be amazed at how far people will go to make other player's lives miserable. Don't give them the tools to make it easy.

If you want a high skill cap, include combinatorial and timing based effects, not control interference. Give players situational tools and lots of high reward/consequence choices, but don't interfere with control. In general, a game should do what I tell it to do when I tell it to do it and nothing else. I personally play pvp games almost exclusively and really enjoy games with very high skill caps. One major influence over how I and my friends judge a pvp game's quality is the standard of control (responsive? intuitive? comfortable?). I abhor games that use control interference, however, and have a near zero tolerance policy for them. Removing control from a player isn't encouraging skill, it's just making the game feel like you aren't in control and therefore should be looking for a better game.


#4995867 Creating a menu

Posted by Zouflain on 31 October 2012 - 10:35 AM

To be honest, writing a menu in C++ is something of a pain, not because C++ isn't perfectly capable of doing it, but because in general a menu is something that is better handled in a script rather than be compiled. A menu will be fiddled with quite a bit over the course of an application's development, and hard coding that into the game make iteration difficult. If you're up to the task, I would suggest adding a scripting engine/virtual machine into your game. Lua is extremely lightweight and easy to get running even for a novice programmer (heck, it was my first scripting language and I've never had cause to leave it!), but very powerful and worth your consideration. It takes literally about 4 lines of to get in running. Python is a nightmare to get running for a novice, so I don't suggest it at this juncture.

If you can get LUA running, then I would suggest doing all of your GUI widgets (which is what a menu is comprised of) in Lua, and let them handle all of the "if mouseX< 98484" logic and event handling. In my games, I just pass pertinent render code from Lua to C++ so it can communicate with OpenGL - C++ itself has no idea how or what a widget does, it knows only how to pass it a generic event structure and how to get back render data. Completely rewriting a menu is a snap at this point, as is adding new widgets or changing their behavior. Also remember to compartmentalize your data into objects as it will save you quite a bit of frustration, and make this sort of thing much simpler in the long run.

---Edit---
1) Be sure you give your CPU a rest in those while loops, unless you want your game to eat as much processor as it can get its hands on in nothing more than a menu. SFML has a delay or sleep function, add that at the end of your loop. It's not necessary, but I find it to be a nice gesture for those that run multiple applications.
2) Make sure the coordinates correspond to what you're expecting. When I first started, I didn't pay attention to the orientation of coordinate systems (naively assuming they'd all use the "standard" one in math text books). The button may be working, but not in the region you think the coordinates describe.
3) Without a debugger, finding crashes is a pain. I would suggest you get familiar with a debugger. Still, if you're into hackish style coding, you can comment out every line and test the application, uncommenting line by line until you find the line that prompts the crash (or, if you're familiar with "binary searching" you can use that rather than brute force...). But get a debugger.
4) I generally avoid while loops, except the main loop (there are appropriate places for them, but I don't think a menu is one). What happens if you get a WMQUIT message during that while loop? Your program looks to windows like its not responding. There are also a host of other events that ought to be handled. Instead of a while loop, implement a finite state machine.
while (game_is_running){
	 switch(game_current_state){
	 	 case MENU:
	 	 	 gameMenu();
	 	 	 break;
	 	 case GAME:
	 	 	 gamePlay();
	 	 	 break;
	 }
}
That's ugly, but an example of what I mean. No more while loop, and you can handle events before, after, or even during these function calls.


#4995847 OpenGL Not Rendering Models

Posted by Zouflain on 31 October 2012 - 09:59 AM

The last parameter, unless I'm sadly mistaken, is a pointer to the beginning of the data. If this is part of a buffer, it gets treated more as an offset then a direct pointer to memory. (void*)0 simply tells it "start at the beginning of the buffer" so if you have a vertex struct, the very first data entry in the struct should be this attribute. Typically when I get an error there (and I use only nvidia cards), it's because I've failed to enable that vertex array OR because I have passed an invalid value (like 8 instead of 3 floats). Be sure also that your shader program uses a vec3 when you pass it those 3 floats.

EDIT: Just though, also make sure that the layout of your shader program matches the order of the attribute arrays. Thus, attribute 0 must be a vec3 or other 3 float containing data type.


#4985116 can you copyright a game combat system?

Posted by Zouflain on 29 September 2012 - 12:31 PM

omg they have patent on that?
So other games cant use that kind of system with the recharging meter for when they can do another action?
Unless they pay squareenix?

that system is badass imo.
This is why i want to be able to patent a combat system i create...

What license did they choose to put on the active time battle system?

You really want to stifle game creation that badly? Personally, finding out about SE's patent makes me glad I haven't played many of their games. People wont buy a license for it, they just wont use it and games will suffer in general as a result. How many JRPG's do you see using that system that aren't from SquareEnix? I can think of none. Why? I'd wager it's because they'd rather use an alternative than pay SE anything. It's because of patent mongering like this that modern consoles don't have haptic (vibrational) feedback and a whole host of other things. Also consider that patents don't help you (the small firm) the way you think they'll help you - just consider that even if you did create a revolutionary idea that some major player player in the industry wanted to use, they can always bog you down in a legal quagmire and survive the costs a lot longer than you can to actually enforce your patent. Unless you have significant financial backing, the only people you will prevent from using anything are other small firms. Is that really who you're afraid of?

This and other posts you've made make you seem as though you believe you have The One Ideatm that everyone is just waiting to steal. This is not and just never is the case, and all you're likely to do is cause yourself a lot of wasted effort and cash. I strongly suggest you read the stickied posts in the Game Design forum which talk about this.


#4984582 Idea to prevent people from torrenting your singleplayer game

Posted by Zouflain on 27 September 2012 - 09:44 PM

DRM is bad and hurts sales. Requiring an Internet connection is just a fancy form of DRM and wont do a thing to prevent piracy. It's very easy, for instance, to spoof your game into "authenticating" with an invalid server or to simply circumvent the authentication functionality by hex editing the address of the function responsible into a dll injected "always return correct value" function. There are a multitude of ways, I imagine, to generate a pirate copy that could bypass any practical form of DRM. All it takes is one savvy software pirate to create and distribute a torrent for a modified version, and all your DRM is for naught.

Also, torrents increase sales (actually, any free access to intellectual property does). The more people that play your game - pirated or otherwise - the more word of mouth advertisement you get for the game and the more sales you eventually gain. Also, the more restrictive your DRM is, the more likely a client will say "I'd rather play a copy that doesn't require all these hoops" and go for the pirated/hex edited version. It's ultimately pointless to include DRM and no game has ever successfully prevented pirates for any significant period of time. Why waste the effort with something that does not and will never help your profit margin?


#4982008 OpenGL vs DirectX

Posted by Zouflain on 20 September 2012 - 06:54 AM

I'll preface this by saying I am (almost) exclusively an OpenGL user. I found DirectX cumbersome, as I tried to learn it simultaneously with C++ - this was out of a 10 year old book, so I imagine it was something like DX7 and a lot less streamlined. OpenGL automagically worked for me at the time, so I never honestly looked back. I still kept up with research, however. Ironically, this automagic property of OpenGL has almost universally been deprecated, but I digress.

The reason why I am opening this discussion is because the information about these issues is so spread and muddled with opinions. My goal is to more centralize the subject of OpenGL and DirectX for convenience. Also given the blistering fast pace of both OpenGL and DirectX changes in games, I want the latest perspectives.

Besides choosing one API over the other due to being unable to use the other (say, D3D for working with your favorite engine, or OpenGL for a wii game) there is no objective means of choosing one or the other, and so all you can ever hope to get is a wide spread and opinion muddled set of responses. I can say that most major game developers favor D3D because it's the traditional API that has been in use for quite some time. Familiarizing yourself with it from a professional game development standpoint is a wise decision... but OpenGL targets dozens of platforms, whereas D3D is quite limited. If you care at all about portability, D3D becomes a very poor choice.

Is OpenGL going to involve more advanced work for the game developer, yet greater flexibility in the long term?

Arguably. OpenGL is very minimalist, especially since 3.1. There are several "handy dandy" things that it simply does not do for you the way D3D does. It's still just as capable of doing them, but OpenGL does not define a default way of doing it (copying a texture to a texture, for instance, requires you to use framebuffers or pixelbuffers - the closest thing, glCopyTexImage2D, draws from the bound buffer) nor is the ARB interested in adding many convenience features. The difference in difficulty between D3D and OpenGL in this regard boils down to an occasional dozen or so lines of code. Not much, but "arguably" more.

It is also arguably more flexible, but only in that it is significantly more portable. Writing linux or mac games in D3D instantly makes WINE necessary at a cost to FPS (as WINE must redirect D3D calls to OpenGL), and I'm not sure if the Wii and PS3 support D3D at all. But while they had significant differences in the past, now they're both effectively equivalent in features. Games using one API do not suffer graphically over another - however, some designers may prefer the "style" or "approach" one API uses over the other, and like me, find it annoying to use the conflicting style.

Doesn't the hardware accelerated 3D nature of OpenGL offer more potential for game features because software processing could be run simultaneously with hardware acceleration to broaden the game engine base - so to speak? Isn't hardware acceleration offering the most potential for game performance and more 3D objects and 2D textures allowable?

They're both hardware accelerated, and most often have very close benchmarks. One might outperform the other at some specific operation or other, but overall there is no speed advantage to either. This is not an advantage for OpenGL.

Three questions answer which API to use:
--Looking to be familiar with rendering schemes of major AAA titles ? DirectX : Either //neither is better, but traditionally D3D is used. OpenGL is also used, but much less.
--portability matters ? OpenGL : Either //DirectX has no portability
--Prefer OpenGL Style ? OpenGL : DirectX //Purely your opinion

Remember, however, that DirectX is more than D3D. If for whatever reason you hate all DirectSound alternatives (FMOD, OpenAL, ect) or DirectInput alternatives, then DirectX trumps OpenGL by virtue of your project already using it elsewhere.


#4979995 Between helplessness and believability.

Posted by Zouflain on 14 September 2012 - 02:14 AM

I liked Ico, thank you very muchPosted Image. That aside, I did do quite a bit of reading on making game content scary and it all comes back to psychology. You have to strip away the things that make the player feel secure and by doing so you will create an atmosphere of horror.

If the player feels powerful, then the game will not come across as particularly frightening except for the occasional jump scare. So the first step is to remove the players sense of power. Don't go overboard with this, however, because making the player feel too helpless will only serve to become frustrating. A good balance is not letting the player kill enemies, but allowing him to temporarily drive them off. Imagine unloading a pistol into some shambling hulk, worrying to yourself as it shambles nearer and nearer despite your hail of fire. At the last moment, it decides you're not currently worth the trouble, glares at you for an unsettlingly long moment with bemused annoyance, and shambles off towards some unknown goal. Psychologically, this suggests that your efforts weren't meaningless, but that you didn't really win the fight since your enemy can always come back at you.

Permanence is another security blanket. Eternal darkness did a good job with breaking your sense of permanence. Doors would sometimes go to the wrong places, or objects in rooms would change enough for your mind to notice but not for your conciousness. Monsters would frequent a hallway often enough for you to expect them there, only to suddenly spawn in a different, unexpected room. When you remove permanence, you remove predictability, and humans fear the unpredictable.

Connected with predictability is comprehension. Make your enemies incomprehensible. I can't remember the title, but one game had several enemies all hunting the hero for absolutely insane reasons (one wanted a toy, one wanted to torture her, one wanted to experiment on her, and the robot wanted her uterus to become a "real woman"). These are fairly cliche, but it makes the characters unrelatable and therefore alien. Monsterous enemies should be even more incomprehensible, like a monster that will stop trying to eat you to stare intently at a picture... then rush you again. Or a monster that only attacks you if it sees you in the mirror.

A final security blanket has to do with conditioning. I still jump when I hear that old doom imp growl, or the sound of being spotted. When something bad happens, make a jarring sound to condition the player to expect negative consequences. Once this has been well established, you can spook the player by playing the sound, or make them think about bad situations by playing sounds that remind them of the alert sound. A dangerous monster that rushes you from corners might make a low rumbling noise. Teach the player that when they hear that noise, they have a short while to find it and scare it off before it charges them (and kills them). Later, include rooms that occasionally play the sound, but have no monster in them.

If ICO had those elements, it would have been a lot more horror oriented, I think. But it didn't need them. Because ICO rocks Posted Image


#4979978 Lua integration into a game

Posted by Zouflain on 14 September 2012 - 01:14 AM

I don't even go that far. I only run luaL_dofile on a .lua which calls a hooked C++ function that itself calls luaL_dofile on the argument passed. Thus, I never have to recompile the project when I add a new script, or when a script wants to import another script file (loading every file in the scripts folder adds extra hoops for seperating one mod from another). In other words, the engine only looks for init.lua, and init.lua is just a series of "DoScript("file.lua")". By doing this, a mod manager can easily append or delete the varius DoScript("file.lua") lines and your mod is loaded painlessly.

Otherwise, I handle things exactly as you and kd7tck said.


#4979963 Lua integration into a game

Posted by Zouflain on 14 September 2012 - 12:23 AM

You're going to catch some flak for using a singleton, even if the use is justified. Thread safety should be a concern of yours, if you are using multiple threads. Otherwise, all I have to say is it sounds fine, but be aware that you generally only have to luaL_dofile(---) once, and then use C++ functions that interface directly with your virtual machine (so instead of ScriptManager::DoScript("filename.lua") I would suggest ScriptManager::some_function(some_args), where some_function pushes the Lua function name and arguments onto the VM's stack then calls said function. Remember, when you're executing a .lua, it defaults to the global namespace, and you dont generally want to access your scripts that way, except to initialize them.

But, others might know better. This is just how I use lua, and I dont run into trouble with it.


#4979776 Space game design

Posted by Zouflain on 13 September 2012 - 11:04 AM

What's your opinion about this?

Can you fit a kitchen sink in there, too?

I don't mean to be unecessarily blunt, but I think the game is overreaching by a very large margin. You have several games all merged into one, each with very sophisticated systems operating simultaneously. A spaceship designer is not unfeasible, but to then make that designed spaceship walkable is an order of magnitude more complex - especially if you want anything to occur inside of it like, heaven forbid, combat. Combining a space game with walk-in-stations is difficult enough, but adding entire planets and the associated code is again a whole order of magnitude more difficult. Major development teams - specifically CCP - have found the task daunting at best, and in years have not managed to combine those elements to the extent you describe.

Further, a game element should only exist if it is fun. Consider the workload it's going to take to make mining fun. That is a game onto itself. On top of this, you must also create a crafting game, a walk-in-cities game, presumably a space battle game, possibly an on-foot combat game, and whatever other games you plan on including in this massive project. Even if you can make each of these games, you must also make them interoperate smoothly and in a fun manner.

It is anything but basic.

I would say make a space battle game with nothing else, just a few prebuilt ships. Get that to be really fun. If you manage that, then make a mining game, and make that really fun. Then try to fuse the two, and continue until you can incrementally develop a suite of games into one project. But to take all this on at once is unfeasible for any but the largest of development teams.


PARTNERS