Jump to content

  • Log In with Google      Sign In   
  • Create Account


Ravyne

Member Since 26 Feb 2007
Offline Last Active Sep 10 2014 12:11 PM

#5175159 Own ruleset - how likely do I violate others?

Posted by Ravyne on 20 August 2014 - 09:06 PM

I am not a lawyer, so do not take this as legal advice -- that being said, here's what I think about your question...

 

You're being paranoid.

 

Not just about yourself infringing on others, but of "protecting" your own ideas as well. This stems, bluntly, from a complete lack of understanding about what can even be protected and of how valuable or not something is, just because it's 'protected'. The symptoms are evident in the way that you think you're working around D&D rules by using different stat names, etc -- and in your being overly secretive about your own specific rules. If anything at all can be protected, its certainly not the generalities -- its the specifics, in concert. That is to say, using different stat names affords you none of the 'protection' you seem to think it does, and by not revealing your complete ruleset no one here can formulate any idea at all about how vulnerably you might or might not be to litigation. I'm not saying to never think about it -- certainly you can't just clone existing rules outright and get away with it unchallenged -- but protection of creative works doesn't typically afford each element in isolation (e.g. rules, archetypes, themes, a'la carte) protection, it generally protects the sum total of those things, possibly together with *specific* people, places, and things (that is, nouns that begin with capital letters.)

 

Besides that, you say it took you three years to develop -- so, either in those three years you've done something amazing with and around those rules, creatively, which serves as a moat around your castle (good); or, what you have isn't all that special and neither affords or deserves the protection you think it does (bad). Game mechanics of any kind, as a general rule, are difficult or impossible to justify protecting -- ideas alone are not afforded the benefit of protection out of hand, there are requirements that have to be satisfied first.

 

And even achieving your own special snowflake of a game, guess what? Anyone can sue you at any time for any perceived toe-stepping at all -- and to the degree that their allegations have any semblance of a reasonable reality at all, their charges will either be thrown out, force you to settle, or drag you through a trial. That's not just a threat, its a legal tactic that IP holders use *all the time* to keep would-be competitors out of their scrapyard -- sometimes the bark is just as effective as the bite.

 

Despite my hyperbolic tone -- there's no bad news for you here, unless by "not copying D&D" you actually meant "I'm TOTALLY copying D&D!" If you can put your game down in front of any role-playing group worth their salt and they don't immediately shout "Dude! This to totally F*cking D&D!", you're probably about as safe as you can expect to be.




#5175067 So... C++14 is done :O

Posted by Ravyne on 20 August 2014 - 11:38 AM

Am I the only one that thinks that all those new features makes C++11 look and feel completely different than C++?

Seriously, that's practicality a different language, why keep calling it C++?

 

Thankfully -- nay, intentionally -- you're not the only one and its honestly the best thing that's happened to C++ since its original standardization (C++98).

 

Its still C++ -- save for the old meaning of 'auto' and some difficulties with primitive sizes, all your old C++ code should mostly just compile. From that same source code, the object code generated today will be vastly superior to what would have been generated at the time of its writing. But writing non-trivial, well-engineered programs in C++ has always been something of an obtuse exercise -- the mechanics of lambdas, for instance, have always been there (I spent a solid month some years back 'back-porting' code with lambdas to a compiler that didn't yet offer support); building them into the language is so much better. For years, C++ has hobbled along with villainously-clever, mostly-working library implementations of what are language-features in other places (See: Boost). This has had an effect of making 'serious engineering' in C++ mostly a domain reserved for experts. There are several sub-themes to C++11/C++14, but the one unifying theme is making all that expert-level engineering stuff (simplifying call-backs with lambdas, simplifying template code with auto, decltype, variable templates, etc) accessible to the non-expert.

 

C++11 *is* a different language -- one better than previous incarnations of C++, but one that is (previous exceptions noted) basically a perfect superset of its older self.




#5174803 Weapon statistics visualization

Posted by Ravyne on 19 August 2014 - 12:57 PM

Don't make it an explicit and permanent part of the interface, or at the very least bury it under the pause screen somewhere.

 

The best possible way is to allow the game to demonstrate it to you -- perhaps because the first time you encounter it is in the hands of a friendly character or foe. Or, maybe you infiltrate a laboratory where the weapon is developed and the results of its tests are visible. It could be part of a cutscene, even. Be creative, and keep in mind you don't have to do it with 'standard-fare' weapons -- the machine gun, "bfg-9000", and shotgun/"spreads" are well-worn tropes.

 

If you are compelled to have a slick animation in game, have it interrupt gameplay with a modal dialog, but only the first time you pick up that weapon -- furthermore, as best you are able to within the confines of your design, try to ensure that this first time the weapon is picked up happens during a lull in the gameplay as to not break up the immediate flow or intense action.




#5174800 What game companies hire remote programmers?

Posted by Ravyne on 19 August 2014 - 12:49 PM

Remote positions at big studios are almost unheard of -- they will sometimes allow for existing employees to work remotely, but as a new hire this is pretty much limited to those with an especially high level of skill and an established track record. In general, game development at a scale of larger than a dozen or so people is a very collaborative process where daily face-to-face communication is a necessity. Complicating matters further are technological issues, wherein it might be very difficult for a remote worker to have a workable network connection for all the high-bandwidth things he needs to do -- a developer like yourself needs either the bandwidth to download regular, full builds (which could be in the 10s of GBs, daily or more) or needs to maintain a local copy of all in-progress art and code assets, along with a fully replicated build system. Even further complications arise if you do console development or must work under NDAs that prohibit documentation and/or physical dev-kits from being stored at non-commercial work-sites -- I'm not sure if its that way with the just-launched generation of consoles, many of the companies seem more open about it, but at least in past console generations none of the manufacturers allowed you to have a devkit if you worked from a home office.

Certain roles are more amenable to remote work -- Audio in particular, where the workflow permits and where few companies have enough demand to justify a fulltime composer or sound designer (even large ones). Most of that is contract work. I imagine art is the same, to a lesser extent.

Companies that work relatively exclusively on PC titles, or smaller indie studios are typically more amenable to remote situations -- many of the better known indies studios started as -- or still are -- largely remote affairs.

 

Small contract work is sometimes available, but it takes a lot to build up a reputation and unless you know someone, usually requires working your way up from the bottom. One of the best ways to fast-track your reputation is take on an open-source project to work on -- remember that any code you write under contract isn't something that you can just slap into your portfolio.




#5174793 So... C++14 is done :O

Posted by Ravyne on 19 August 2014 - 12:27 PM

My understanding is that range-for isn't strictly syntactic sugar, because iterators can fall down (or at the very least can be unwieldy, possibly requiring otherwise unnecessary specializations) under template code. It might be the case that std::begin / std::end alleviated those problems (IIRC, range for utilizes them), but I also believe it was the case that std::begin / std:: end were proposed after range-for had gained steam -- besides that, I like that range-for specifies intent exactly "visit each item in the container once, from front to back", yes the iterator idiom is common, but if the loop body is more than a few lines long I have to parse it to make sure there's no funny business going on with the iterator.




#5174534 So... C++14 is done :O

Posted by Ravyne on 18 August 2014 - 02:14 PM

You also missed extended constexpr Nevermind, no you didn't, but regardless -- for a complete rundown, see https://isocpp.org/wiki/faq/cpp14-language

 

The new auto return type is more than just extending it to functions, it also has more capability with respect to multiple return statements and recursive calls -- basically, as long as the first return statement's type can be deduced, you can now have subsequent return statements, including recursive calls, as long as they all agree on the type.

 

decltype(auto) is a new refinement of type deduction that is mostly useful to preserve the reference-ness where simple auto wouldn't -- My understanding is that it performs the same function as auto-with-trailing-return-type-of-decltype, but without the trailing part. It can be used anywhere a declaration can be used, which might be useful but early guidance is that this would be an anti-pattern. This is super important, but mostly for library-implementors.

 

There's also a new standard [[deprecated]] attribute to mark deprecated APIs, and you can now use the single quote (') character anywhere in numeric literals to separate digits to make them more readable, in any of the literal formats -- e.g. 0b0110'0011 to separate out the nybles in a byte.




#5174331 How to build a virtual machine

Posted by Ravyne on 17 August 2014 - 03:44 PM

Depends entirely how you define 'VM' -- I assume what you're talking about is "something like the Java Virtual Machine" -- and even within the context of something like the JVM, there are several distinct approaches. The easiest approach would be some kind of high-level language or byte-code interpretter -- In that approach, the JVM is not unlike the BASIC programming languages of yore, or many of the scripting languages popular today. Byte-code interpreters are basically the same function, but are attractive because of increased performance of applications running on the VM, and code-density/code-hiding -- but now you also need to write some kind of compiler, in addition to your VM, both of which are big tasks.

A state-of-the-art VM today uses just-in-time (or JIT) compilation to get best performance. In this setup, there's typically a compiler that takes a high-level language and translates it into Intermediate Language (or IL), a lower-level representation (which often, but not always, looks similar to assembly language of popular CPUs); this compiler only concerns itself with high-level, algorithmic optimizations. Then, the JIT-employing VM performs a final phase of compilation in which the VM IL is compiled down to actual machine code that can be run on the host processor directly, but still within the sandbox defined by the VM platform.

 

Much of the job of writing a usable (professional) VM today is about security of the sandbox environment, things that enhance programmer productivity -- like garbage collection, and JIT performance. Within that sphere of influence, the part you probably think about as "the VM" is mostly about defining what the virtual hardware platform and IL look like -- things like whether the machine architecture is register-based/stack-based/direct-memory/something-else, to tedious and not-immediately-obvious concerns like what the threading model/shared-memory/message-passing/memory-coherence models are. That's for a 'production quality' kind of VM -- odds are, if you want to keep it simple, your VM will look more like a scripting language.




#5173669 Advise on Class structure

Posted by Ravyne on 14 August 2014 - 01:04 PM

Some criticisms:

  • Why is everything public?
  • Getters and Setters are often a code-smell or unnecessary java-ism.
  • Why is everything public and you also have many getters and setters?
  • Your naming conventions are all over the place, I see lowercase-underscore, PascalCase, and camelCase all mixed together.
  • Your naming choices for member functions and member variables are unintuitive and unclear.
  • I don't see 'const' used anywhere -- const-correctness is an integral part of maintaining the invariant state a class is supposed to maintain.
  • I don't see you passing parameters by reference anywhere except where it would be dictated by D3D convention -- I could be wrong about this, as I'm not familiar with all of these data structures you refer to, but my experience says that passing by const reference is usually more prevalent than what I can see here.
  • You have several cases of 'foo1(...)' and 'foo2(...)' that have the same parameter and return types. 1 and 2 doesn't tell me anything -- the function name should tell me what's different about them.
  • You mostly don't name your parameters -- while this is allowed and even sometimes useful, its more-often bad form for a public interface to not describe what its parameters are. When the class members are implemented in a non-header file, clients won't see the names you give them there.
  • It looks like some of your member functions shouldn't be members -- these should probably be non-member-non-friend functions. If they're part of the same logical interface, keep them in the same namespace, otherwise put them in another namespace. For example, 'void createSphere(  LPDIRECT3DDEVICE9&)'



#5172084 Does the interface of every graphic adventure game suck?

Posted by Ravyne on 07 August 2014 - 12:01 PM

I think part of the problem, as they say, is that a picture is worth a thousand words. In the old text-only adventure games the descriptions could be very rich but it was also very clear what the nouns were. In an image-based adventure game, literally every distinct thing on the screen is a potential noun, and that obscures which nouns are actually viable or interesting, which kind of gave rise to the sweep technique where you revert to sweeping the entire screen with the cursor when you're stuck on a puzzle. I don't know if its reasonable to implement a natural-language-like interface in an image-based adventure game, but there's certainly room for innovation.

 

If you want an example games with somewhat different takes on the genre interface, check out the more recent installations of Broken Sword from The Adventure Company, or Shadowgate 64 for a (admittedly, probably poor) example of a fully-3D, first-person adventure game.




#5168475 How to invent names (theory)?

Posted by Ravyne on 22 July 2014 - 03:58 PM

Also, keep in mind that with things like names of people or places, you're thinking in terms of lineange and legacy, not today. It seems obvious, I suppose, but at least in modern times, the actual people in question are removed from where their name might have come from -- A character might be Sam Baker because his great-great grandfather was a baker, not because he is. If everyone in your world carried the name of their profession that's going to start seeming lame very quickly.

 

Lots of places are named after important people or religious figures -- for example, Columbus Ohio, or San Francisco. Places are also sometimes given names to make their importance clear -- King's Landing in a Song of Ice and Fire, or historically to confuse in some cases -- Greenland is icy and inhospitable, Iceland is nicer, because the Vikings were trying to trick their enemies.

 

Most important though, is being consistent. In A Song of Ice and Fire, Bravos has a sort of Spanish flair, The Dolthraki (Spelling) are sort of Mongols.




#5167986 Linux development workflows?

Posted by Ravyne on 20 July 2014 - 01:25 PM

Honestly, my development experience on Linux is mostly as a kind of playground. That is, the kind of coding I do there is mostly recreational -- messing around with Arduinos or other embedded stuff who's tool chain runs best on *nix, exercising my more 'academic' language pursuits like Haskell, or playing with neat linux stuff like Docker. Because I'm not so concerned with efficiency then, that informs some of my other choices. I use Vim not because I find it to be instantly productive, but because leaning Vim is a goal in itself -- its simply useful to know at least one lightweight text editor that you can use even from a remote text console -- and because the long walk leads to becoming possibly more efficient than WYSIWYG editors and fancy IDEs.

 

In general I like Linux because its a more 'orthogonal' environment in some sense of the word. The trend on Windows (and old-world Macs, the trend has reversed since OS X) has been towards more monolithic, swiss-army-knife applications, or to largely independent 'kingdoms' of apps that inter-operate nicely. The trend on *nix has always been towards a more inter-operable ecosystem of smaller and more focused tools that do one thing very well. It goes beyond the apps themselves though -- even where windows has functional equivalents (say grep vs. findstr) the command-line apps on Windows all use wildly-different argument formats, and not every app necessarily supports piping in ways it ought to. The *nix world largely has that problem sorted.




#5167708 Classes and OOP

Posted by Ravyne on 18 July 2014 - 06:58 PM

Single-Responsibility Principle.

 

Stated another way, functions, classes and modules should strive to this mantra: "Do very little, very well."

 

You get into a very philosophical question of "What is a single responsibility?" pretty quickly, and it depends on the level on which that element operates. For two numbers, adding and subtracting are each single responsibilities. For a string, a single responsibility might be concatenating two strings together, or finding the first occurrence of a character. For a database, a single responsibility might be inserting a row of data atomically.

 

A simple rule of thumb is this -- describe in some detail the essence of what the function, class, or module does in just one sentence. If you can do it without using a conjunction -- usually "and", but sometimes "or" -- you're probably golden. If you struggle to fit it into a sentence or can't do so without reaching for a conjunction, then it's a sign that it might do too much -- that it might have more than one responsibility. It doesn't *always* mean that, strictly speaking, and sometimes you just have to accept it for practical reasons (preferably late in the game, you should be less willing to compromise early on), but it should always make you cast a suspicious eye towards it.




#5167707 why c++ is the most widely used language for professional game development?

Posted by Ravyne on 18 July 2014 - 06:44 PM

Inertia plays a big part, but the other reason is simply that C++ is currently the best, most-widely-available language we have at our disposal when you need to touch the hardware. At the lowest levels, doing the kinds of things that runtimes, drivers, and operating systems do, basically everyone speaks C or C++ -- there are other systems-languages with pockets of support, but in consumer software and consumer electronics, C and C++ are it. Then, it stands to reason that if you're writing any kind of high-performance app that needs to get the most of of those runtimes, drivers, and operating systems, using the same language will give you fastest and most authentic, transparent path. Stepping back one space, to achieve high-performance in code that isn't so much touching those underlying elements, you still need to employ the same kinds of low-level techniques that those elements use themselves -- for example, you might write a memory manager, or you might implement certain parts of the code using intrinsic or inline assembly, perhaps making use of instructions like SSE or AVX that aren't available to the VM models of languages like Java or C# -- and again C and C++ are the natural choice.

 

I think ultimately, it comes down to the fact that C and C++ are one of very few languages, and by far the most popular, that give full trust and confidence to the programmer that they are doing precisely what you want. C and C++ will let you shoot yourself in the foot, sure, but when you pull a gun, point to the ground and shout "Watch this!" C and C++ will almost never second guess that you know what you're doing unless you ask it to -- and even when it thinks better of it and objects, its not hard to convince it that you do, in fact, know what you're doing. This is a perilous but powerful relationship to have with a compiler, other languages are such hypochondriacs that not only will they prevent you from shooting yourself in the foot, they will also stand in your way when you want to undertake all kinds of unorthodox but supremely mundane activities, regardless of how well thought out of a plan you want to try to convince it you have.

 

That said, those other do-gooder languages are often enough fast enough and flexible enough for a great many things -- used well, and combined with a little arcane knowledge of their supporting run-times, they're even suitable for games. At some level underneath, there's a hidden sea of C and C++ doing all the things that C and C++ do to make stuff go fast, but those other languages are suited well enough for directing its current.

 

C++ is popular in games because it started doing a job that needed to be done before anyone else was ready to do it, and because no one since can do, or do such a better job at to make the switch worthwhile. There are other interesting systems languages available that are aimed at the consumer software space, D and Rust come to mind, but they don't now are aren't likely to have the necessary industrial support to turn the tide any time soon.




#5167462 C++ avoiding pointers

Posted by Ravyne on 17 July 2014 - 01:26 PM

Smart pointers, smart pointers, smart pointers.

 

The whole idea of a smart pointer is that they effectively allow you to hoist dynamic, non-deterministic memory usage into the realm of static, deterministic memory usage where you can effectively treat them as value-types.

 

Today, you basically don't have to think about the Rule of 5 or rule of 3 -- provided that use an appropriate smart pointer whenever a heap object is owned, and you only use raw pointers when no ownership is implied. Which kind of pointer you use is easy once you understand what each kind of pointer does -- your entire decision-making process can be expressed through a flow-chart that fits on a postcard. The only part that's a bit tricky is learning to recognize where weak_ptr fits in, but the entire landscape is a whole lot smaller than what you need to know to implement correct memory management patterns using new/delete directly.




#5167461 Implementing an in game debug console (WebGL/Threejs)

Posted by Ravyne on 17 July 2014 - 01:16 PM

There's not a ton to it -- you can create the UI with normal HTML elements, style them with CSS, and fancy them up with jQuery or other libraries. But, you need to write your game such that your game loop includes console-handling, and can then pass the commands down into your game control structures. You also need to be able to read out various stats/data from your game. Its hard to tell you how to do that last part -- its where most of your effort will go, and it completely depends on how your game works.

 

One good bit of news is that basically all debug consoles work in the same way, regardless of language or UI technology. any information you find on debug consoles can apply to your particular situation in a fairly straight-forward way.






PARTNERS