Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2007
Offline Last Active Yesterday, 06:10 PM

#5304262 Ide For Linux

Posted by on 05 August 2016 - 04:41 PM

Give Visual Studio Code a look together with the first-party C++ Extension -- its a lightweight code environment that's partway between an IDE and simpler programmers' editors. 


It doesn't have as good of intellisense as Visual Studio (but its as good as CLion's) -- The debugger is pretty slick, too. VS Code itself supports Windows, Linux, and Mac -- the C++ extension supports GCC on all of those platforms, but Windows is (surprisingly) the least mature (but then you have VS Community for free on Windows). Last I looked, CMake was a work in progress, but should be coming along quickly.


Agreed with previous posters that Eclipse is quite heavy, though closest in feel  to Visual Studio.


I like the Emacs+cmake+GDB+terminal route myself (using Evil Mode (Vim emulation) because Vim's keyboard commands are better). Vim is fine and works, and is the better human interface (IMO), but Emacs is better software. NeoVim is also better if Emacs doesn't float your boat.

#5303901 Best Way To Comment Code Without Cluttering

Posted by on 03 August 2016 - 09:11 PM

What I try to follow for my own code:


Write code that, for the most part, does not require comments. This includes proper names for things, keeping functions small & contained, dealing with as little code as it makes sense to do, keeping with the style of surrounding code, etc.


For algorithms or math heavy stuff I sometimes add a link in a comment, or copy the formula and information directly in comments if it doesn't take too much space.


Comment things that are out of the ordinary, or where the intuitive solution is not the correct solution.


This is more or less what I strive for as well.


Comments and documentation aren't the end-goal -- an understandable code-base is. To that end, reducing the need for comment or documentation is every bit as good and useful as writing comments or documentation; in fact, its often better because the code cannot diverge from itself, as comments often do from the code they purport to represent. Documentation that diverges from its code is a bug-in-waiting.


Code should never be more complicated than there is reason for it to be. There's no reason to be clever or flexible or fast where its not certain to become a necessity. I'm not saying we shouldn't ever do these things, but that we spend altogether too much time in pursuit of these facets for their own sake, or for valuing them against their imagined benefit rather than their actual utility. Avoiding such frivolities shrinks and simplifies code bases, resulting not only in fewer lines to comment, but also less pressure to comment the lines that remain*.


Strive to make your code self-explanatory at every scope it could be reasonably dissected into. The best loops are those I can understand without looking to the rest of the function. The best functions are those I can understand without looking to the surrounding class or file, or to the functions it calls or that call it. The best classes are those I can understand without looking to the member functions it carries, the base(s) it inherits from, or the rest of the module it lives in. If I can look at units of code at all of these levels and understand what I see without insider information, that code might not need to be documented at all. Likewise, where I lack the information to understand this unit of code tells me precisely what comments I need and are appropriate for this scope.


Document the complexity that you can't avoid, and document the rationale behind not avoiding it. You might introduce complexity to fix a bug (unless the bug was the result of a typo, there is complexity here by definition -- you missed it the first time), to make things flexible or extensible (open-endedness is always introduces complexity), or to make things go fast (going fast sometimes requires specialized code, and specialized code makes assumptions, is complicated, or both -- almost always). Documenting why you did something is every bit as important and illuminating as documenting what you did.


Where appropriate, reference or link to relevant artifacts. Sean mentions bugs, Lactose mentions algorithms. Absolutely do that, and add your specific context to comments or to the artifact itself if it makes sense. Make sure that artifacts are long-lived and if you cannot control or trust that they are, pull the artifact down, check it into your project's source control, and reference the copy you control. It shouldn't be anathema, for instance, to have a folder full of white-papers in your source code repository**.



* Caveat: One way to simplify is by making simplifying assumptions (e.g. "The list will never be empty") -- non-standard assumptions, and especially assumptions against the prevailing mindset should always be documented. In general, all violations of the "principle of least-surprise" should be documented if you choose to make them willfully.


** Caveat: If your repo is public you need to be respectful of copyright and abide by any licensing terms granted, get permission, or be covered by fair-use scenarios.

#5303719 Repository Host Suggestions

Posted by on 02 August 2016 - 03:59 PM

If you insist on sticking with SVN, consider getting yourself an assembla account, which is free with unlimited private and public repos for up to 5 users (but you only get 1GB of storage on the free tier, and it goes up to $24/mo. for up to 12 users/5GB storage). In addition to hosting your SVN, you also get features for issue and bug tracking, project planning, etc.


Google drive and other such file storage can work, but you have to understand that its a separate system -- If you do a commit on your machine to your SVN repository, it may take some time before GDrive and similar catch up, and similarly, other machines have to sync to GDrive before they can sync to the latest changes in the SVN repository.



If you're open to switching to Git, a lot more options become available to you. Nearly all of the free software world has switched from centralized versioning systems like SVN and its predecessor CVS to distributed versioning systems like Git or Mercurial. These models work very differently -- centralized systems work like a library of code files which users check out to change, modify, and then check back in -- distrubuted systems don't operate on checkout/checkin, instead they allow everyone to work in their own branches at the same time, and then merge them in later (with sophisticated tools to automate as much of this process as can be automated). Even for solo developers, many prefer Git or Mercurial over a centralized system -- the different workflow does take getting used to if you come from a centralized version control system, but there's an excellent free ebook that you can browse online or download, or even buy a copy on paper.


For Git, the obvious choice is Github -- creating an account is free, with unlimited free public repositories (e.g. open-source of some ilk). The personal plan is $7/mo and gives a single account unlimited private repositories (you can grant access and accept pull requests from other github users, but you can't give them permissions to push changes directly). If you want additional people to have push permissions, you need to create an organization which is $25/mo for up to 5 users (push permissions) and $9/mo for each additional user -- you get multi-user, multi-role access permissions to control which users have what kind of access on a per-repository basis. You get 1GB/mo free storage and transfer for 'large files' using Git-LFS (things like working files for art assets, you don't want to check those into Git in the usual way), and its $5/mo for each additional 50GB storage/transfer.


Github is the largest and most-active developer community, especially for open source. Its very well developed, very well understood, and full of smart developers. Their pricing structure is pretty sane and fair now, but there's a minor issue if you use Git-LFS that basically means you don't want to use it for open-source projects (It can't be forked by other users, which is the usual workflow for Github). Other than that issue, its got the best tooling and community for hosted source control, hands down.


There's a competitor, GitLab that offers entirely free and as far as I know unfettered Git hosting, and they more or less emulate GitHub with some of their own ideas and changes thrown in. They're entirely free if you use their online system, unlimited public and private repositories, free Git-LFS (IIRC) with no storage or bandwidth limits. Their business model is supported by their on-premises enterprise deployments -- the (minor) downside of that is that if your team scales up such that you need something more than their online experience, you need to migrate to another provider or buy into their enterprise package, which has a minimum seat requirement that makes for high costs -- then again, if you need that level of capability, then your organization can surely afford it.

#5303561 2D Rpg Cutscenes

Posted by on 01 August 2016 - 04:38 PM


Why would instructions need to be read from a file? Wouldn't it be simpler to hard code the instructions, since each of the scripted sequences will stay the same? It would improve performance too since there wouldn't be any file io.



Are there any significant drawbacks to this approach versus using a scripting language, or is it manageable given the scope of my requirements?



The general benefit of reading scripts (and configuration data) from a file rather than being hard-coded is that changes do not require your entire program to be rebuilt for every change (scripting can even be implemented in such a way that you can modify and re-run scripts without even stopping the program), and that scripts are "sandboxed" -- that is, the only actions exposed to the script are safe, and can't make mistakes or take harmful actions that could destabilize the program or overwrite important data. As a single developer, that second part is perhaps less of a concern to you, but the the first part helps reduce your iteration time (time to identify problems, make changes, and see results) for scripting sequences.


For very simple scripting activities such as moving characters around a screen, showing dialog, and setting or testing flags (as to indicate progression past a plot point, and testing for it later) those sorts of things can be done with a simple, command-based scripting language. This kind of language generally has one command per line in a text file, where the first word is a verb (some kind of action to undertake), and the remainder of the line serves as parameters -- this is basically like a function call.


A simple script might look like:

MOVE Goku, Slow, 10, 0, 0, 0
TALK Goku, "Hi Master Roshi!"
TALK Roshi, "Goku! Piccolo needs your help!"
TALK Goku, "OK!"
MOVE Goku, Fast, 0, 0, 20, 0

Its not difficult to write a simple script interpreter, especially in a language like Java that has good support for Regex. In your code, you need a means of parsing the file to recognize commands, classes and methods to implement those commands, and a system for dispatching those commands. Depending how you handle movement and how fine a control you want, and how hands-free you want your script to be, you might need to implement some basic "concurrency" so that commands can complete simultaneously (as in, two characters can move at the same time, rather than in order). Timing also plays a big part in scripting, so you'll want to build in various pauses, delays, timers, and time-based triggers into your system. Many kinds of scripting languages employ the Actor model and/or some form of coroutines, which form the basis for concurrency and timing.


When you want to talk about moving game logic into scripts (again, to reduce turn-around time) then you definitely want to look into readily-available scripting languages like Lua, unless you actually have an interested in building a scripting language of your own (And if you have no interest at all, even to build a simple, command-based scripting language, you might want to adopt something like Lua regardless). Lua is generally considered to be a simple and effective scripting language for games, and its widely used -- I'm not sure what its Java binding story is though. If Lua is too complex, Java/TCL (Wikipedia) [project homepage] is a command-based scripting language that can be embedded into your Java application.


Finally, you don't *have* to use a scripting language if you're willing to forego its advantages with regard to iteration speed, security, and flexibility. What that generally looks like is that you provide yourself an API that does all the common things you want to do in your cut-scenes, and then you have methods that correspond to each scripted sequence that linearly call those functions; In this approach you don't need to implement value setting and testing because you can rely on the language's normal operations and flow-control. You can even use the language's timing primitives to an extent, but you probably don't want timing to block your thread -- you'll probably need to provide a non-blocking system eventually, and you might find a library or framework (again, "Actor Model") that does this and more for you, if you don't want to write it yourself.

#5303001 Xml Parser, C++

Posted by on 28 July 2016 - 04:03 PM

I've used Xerces in the past -- I didn't spend any significant amount of time researching or weighing its pros and cons versus competitors. The impression I get is that Xerces is probably the most conformant (its an Apache project, and is a validating parser) and is likely the most heavyweight library, for good and for ill. The other options mentioned here will likely get the job done in any case, and with conformant input themselves, even if they don't accept all conformant XML (that is, my impression is that they accept a pure subset of valid XML that differs in little-used ways, or ways not relevant to their use cases -- and that they do not accept invalid XML).

#5302820 When Tertiary Operators Become Confusing

Posted by on 27 July 2016 - 04:10 PM

Its "ternary", not "tertiary" -- though its an easy mistake I was once guitly of myself. "Ternary" means "composed of three parts", "tertiary" means "of the third order, as in primary->secondary->tertiary."


I've never seen this form of ternary operator before though -- what language is this? In most (all?) languages, ternary operators are expressions (meaning that they have a value which can be assigned, passed to a function or otherwise consumed directly), whereas if-else constructs in most* procedural languages (C, C++, and cousins) are not expressions, they're statements. If you don't take advantage of of their status as an expression, code using ternary operators usually is more ugly than if-else-style code, and its often the case that when if-else-style code changed into a ternary expression is still ugly, then it was probably better off as if-else anyways.


Using C-and-friends-style ternary operators, cleaner code might look like this:

auto move_speed = (is_running) ? normal_speed * run_speed : normal_speed;

Or even this:

auto move_speed = normal_speed * ((is_running) ? run_speed : 1);

* Many functional or functional-inspired languages have if-else expressions rather than statements.

#5302560 Unity Or Ue4 To Use As A Show Reel For My Portfolio

Posted by on 25 July 2016 - 07:18 PM

Whatever you do, don't send mixed messages -- Apply as a programmer and showcase your programming, or apply as an artist and showcase your art/modelling. These will be distinct Portfolios for sure, and should be distinct resumes as well -- even if they draw from the same education and experiences list, each resume should have a different angle focusing either on your programming or artistic prowess.


Now, an important question to ask yourself is whether or not you actually have the requisite background and skill level as an artist to compete for jobs against those with an arts background. Its entirely possible you might have the talent, if not the paperwork, but be aware that there's a whole different background expected of an artist -- even if they're title is "modeller" its still usually expected to have some level of competency with traditional art (sketch, painting, etc), digital 2D art, concept development, and a general familiarity with art history, terminology, and all the foundational techniques a pure artist would have gained.


If your modeling skills are strong and your general art background/capability not lacking, your ability to program might make you uniquely attractive to a small team looking for a first/only artist because you'll need a strong ability to interface with programmers on a technical level. In the industry, there's a title something like "Technical Artist" who performs this same kind of function for a larger team -- being the liaison between the art and programming sides of the house, working with programmers to specify what the art team needs of the engine, and helping the artists work towards what the programmers enable. On a larger team this person doesn't usually do art themselves, at least not primarily, but for a team with only 1 or 2 artists, a similar capacity to collaborate on a technical level can be useful -- it could be a programmer who understands art, or an artist who understands programming.

#5302536 Rpg Stats - Temporary Changes, Harder Than I Realised!?

Posted by on 25 July 2016 - 03:32 PM

A good design pattern for this is the Decorator pattern. Applied to this problem, you can think of it as an object-based formalization of Hodgeman's stack suggestion, or some of the other suggestions here.


How I use it is this --


First, in my case, characters' stats are fixed per-level, and stored in a read-only array-of-structs -- there's one struct for each character and for each level. The character data structure points to this for its base stats. Weapon, armor, and item stats are similar, but separate -- You can think of all of this as being a big dictionary, or set of spreadsheets or database tables -- in fact, that's usually how I author this data, which gets fed into the build (or could be read from a file a load-time).


*side note* If you have non-static leveling (e.g. where the user allocates their own points when they level up) you would manage this base data differently, but the basic pattern and application stays the same. You have a couple obvious choices: One is that you do away with the dictionary and just have a base-stat data structure for each character/item that you modify directly; The second way is that you still have the dictionary of read-only base stats, and you implement the user-allocated points themselves using this pattern (just apply them before any other buffs/debuffs/effects).


Now you apply the decorator pattern to that base stat structure -- basically, you have a decorator that presents the same interface as the structure itself, and when a decorator is applied, the character points to the decorator, and the decorator points to the base stat. This means the character reads from the decorator, which is where it gets its opportunity to modify the base values. What about multiple effects/buffs/debuffs? Simple! Since the decorator has the same interface as the base state, a decorator can point to either the base state or another decorator as long as they derive from the same interface and you use a pointer to the base class -- you can stack them arbitrarily deep, and each decorator will modify the sum of the base stat and all the decorators that came before it.


This might sound like an awful lot of engineering for something so simple, but its very robust and the pattern isn't terribly complicated. One of the things that makes it nice is that it really decouples the implementation of effects from one another and from the base stats structure. They don't need to know anything about what the other states look like, how many there are, or what they can do. It communicates only the language of the character stats (though, in my implementation, I have a side-channel that allows an effect to know if a certain effect has already been applied -- for items, think of a set of armor that's stronger when all its pieces are equipped.)


Also worth noting, is that the reason I like to pass in the entire character stat-set, rather than having individual decorators for each stat is that it makes it much easier to have multi-dimensional effects that modify several stats, or which take into account multiple stats in determining its value (e.g. a character's defense against spells might be modified based on both their magic resistance and their intelligence) -- its also a whole lot less to manage and a whole lot less code to write.


To talk about implementation of the interface for a bit, it'll depend on whether you're programming in a language with properties (like C#) or without (like C++) -- if you have properties, then you can use them to implement getters for each base stat (and setters, if you don't go the dictionary of read-only structs route). Otherwise, you need to implement member functions to get the values out.


Another good shortcut to know about is that in C++ a virtual function can have a default implementation -- so what I do is when I define the base class for the decorators is give the virtual getter a default implementation that just reads the value form whatever it points to and passes it along unmodified. That way, when an implementation of a particular decorator only modified one stat, I only have to implement that one stat's getter without any other boilerplate. Not only does it saves me typing, it removes the opportunity to make mistakes.

#5301846 What Makes A Game Look Realistic?

Posted by on 21 July 2016 - 06:06 PM

Agreed -- Lighting.


Tim Sweeney of Epic Games and a graphs wiz every bit as good as Carmack--if not better--roughly lumps generational lines of rendering advancements as to how many bounces of light they simulate. In raycasters like Doom, light bounced just once off of a surface of the world directly to a pixel on your screen and nothing intervened in it -- light didn't come from anywhere in the world, it was just an ambient value, ever-present, constant, radiating in all directions evenly. In the first generation of polygon games like Quake or Unreal, light "bounced" twice -- light affecting a particular surface had a single origin in the world and each origin could have different properties, an ambient lighting factor continued to stand in for all the indirect bounces; pre-baked light-maps helped color-in the illusion of localized lighting and occlusion. For a long time, lighting advances came by increasing the number of lights in a scene, not increasing the number of bounces -- Even through Doom 3 was more lights, not more bounces. Modern games of today simulate ~3 bounces -- IIRC, the ambient light factor bounces off of one surface, picking up its properties, propagates that to a nearby surface, and finally the sum of this and the localized, two-bounce lighting to your eye. The coming generation--maybe today's bleeding edge--should make a good run at subsurface scattering.


Adaptive animation is another of the current frontiers that builds on realism. After that, probably AI/Behavior that results in more than a simple choice between pre-canned responses that are blended at best -- something more natural than that will be needed to cross the uncanny valley once we reach realistic-appearing humans in real-time..


A parallel advancement has been Physically-based lighting, which gives materials a logical consistency like you see in the real world. In the past, materials were often bespoke and could have their knobs tuned to wildly different values to achieve an appearance consistent with the scene as a whole.

#5301661 Is It Really That Nonsensically Impossible To Have A Successful First Game Pr...

Posted by on 20 July 2016 - 07:44 PM

Its not that its impossible given the right research, team, and discipline -- its that only rarely do those big dreamers have any of those things. And even when they do, its still not a sure bet. If you manage to have all of those things, you still need to develop the right kind of connections, gain the right kind of attention, and bring it all to bear at the right kind of time in the market. Success doesn't follow a formula, you can do everything right and still fail for no apparent reason, or you can mess up some things and be wildly successful for reasons mostly beyond your doing or understanding.


The best you can really hope for is to do your best to stack the deck in favor of your success. Doing that means being on your game all the time, always being in position to take advantage of favorable winds. And your team needs to maintain that despite what life throws at them, and--without funding--for an uncertain and uncompensated future, all while doing whatever it is they do to feed themselves or their families. Its a lot to ask for, and only a very small chance of a worthwhile payday in return.


By all means reach for success and do everything you can to tip the field in favor of achieving it, but don't place real or emotional stakes that you can't afford on success alone, especially a big success. Small successes in service of an eventual bigger success are often more achievable and even failures in service of that goal are often more palatable than betting all your hopes and dreams on one singular push.

#5301258 Copying An Existing Idea

Posted by on 18 July 2016 - 02:21 PM

So, assume there is a game. Also assume that the law stuff would allow you to copy it, share it, use it etc. Now assume you take this, port it to another plattform, aybe tweak it a bit and then release it as a commercial product.


Being granted a license to use/share/distribute a software product freely (as in freeware or shareware) doesn't grant you any license to make derivative works of said product. Some kinds of freely-available software, such as "open source" software give you all of these rights, but usually on a conditional basis. For example, the GNU license, among other things, says that you can modify the software and distribute your modifications or modified versions, but you must not close your source code, you must not remove or modify the license, and you must contribute your modifications back to the original project so they can be integrated there (though they might not be); Also, you give up your copyright on the code you've added. Other licenses, give you different rights and require different things of you in return. Also, be aware that the license governing the source code may not be the same license governing other program assets like graphics or sound -- even if the source code may be modified and distributed, it does not imply that the same is true of other program assets.


As for where the legal and ethical lines lie its less concrete. Legally speaking, copyright laws do not protect ideas but do protect a particular expression of an idea; which is necessarily subjective matter in ways that other kinds of torts are not. Recent court rulings have resulted in damages being awarded in cases where clone products were effectively identical in all but aesthetic differences. Read up on the Tripple Town / Yeti Town lawsuite as an example. Basically, the judge ruled for damages because Yeti Town was a direct clone, down to the rules, item function, and general progression of play. Still, this is not cut-and-dried, because there's no clear consensus on how much sharing of rules, item function, or progression constitutes a clone.


Also, copyright law is absolutely clear that you cannot create derivative works which steal characters, settings, specific premises or other established elements of a creative work for your own; so don't do that in any case.


Ethically, I'd say you're best steering clear of clones and near-clones, even if you change up the artistic elements, characters, etc. Take inspiration, pay homage -- hell, even satirize -- but don't copy. For me, and what I've always advised, is that if your work doesn't stand on its own merits, then its not really your own, and furthermore don't do anything you'd be upset by if the shoe were on the other foot (also, trying to imagine that on this other foot, the product being cloned might be feeding someone's family). If you avoid those things, you don't have an ethical duty to even ask -- it can be a nice gesture, but be aware that if you get a polite "Thanks for asking, but no.", and you then cloned or heavily borrowed from them anyways, you've given them great ammunition to go after you with in court, if they decided to -- and they could tell you no and later go after you even if they don't have solid legal grounds to stand on. If you ask, you need to abide by the terms you're given.

#5301253 Compilers

Posted by on 18 July 2016 - 01:49 PM

- better C++ language standard compliance

Non of there are advantages of non-MSVS nor they are disadvantages of MSVS, as they are easily achievable with the Microsoft compiler. 



Microsoft's compiler still lags a bit behind on conformance issues, not much now, but some. There are some language features that can't be fully supported (or at all) until their compiler rejuvenation project is complete. They've written about it on their blog, but the basic problem is that for historical reasons the compiler took things from source to final representation as quickly as possible, so unlike most other compilers there's no intermediate form representation of the entire translation unit, and this makes a few of the new language features very difficult to achieve. Good progress is being made on the rejuvenation though, they announced their SSA optimizer recently, which is a first step in resolving the legacy problem. There is an interim sort of work around, though, that I'll speak to in a bit.




First, we need to settle on some terms -- A Compiler is the program that transforms your source code to machine code in an object file; notable examples are GCC, Clang, and Cl (Microsoft's compiler). An IDE is the tool many people use to write their source code, manage their projects, debug, and do other things; notable examples (for C++) are DevC++, XCode, and Visual Studio. You don't need an IDE to write code -- you can use any text editor you like, or other IDE-lite offerings -- as long as you're comfortable doing your compiling and linking from the command-line, and with debugging with stand-along tools like WinDBG or GDB. For running your builds, things like MAKE and MSBuild exist -- those allow you to build your program for various targets easily, from the command-line.


For an IDE, Visual Studio Community is probably your best bet right now -- As long as you select the C++ tools during install, everything should be set up. Other IDE options, IDE-lites, and text-editor-based workflows usually require a bit of extra setup.


For the compiler, there are a few things to address -- I'd wager that DevC++ in your instance is pointing to a GCC compiler, or possibly to Clang. Either of these have different command-line options and language support than Microsoft's compiler. If its the case that you'll need to use a compatible compiler for you course-work, you'll need to set them up. Possibly, one option is Microsoft's Clang/C2 compiler -- basically this is the Clang front-end, strapped to Microsoft's Code Generator; this gives you a GNU-style compiler (command-line options) that has Clang's level of language support, and creates object files, libraries, and DLLs that are compatible with programs written with Microsoft's normal toolchain. It might be enough for you to do your coursework with. I've used it myself to write code using Boost::Spirit::V3 (a template library that doesn't compile with Microsoft's toolchain).


If your school is a linux house, another good option around the corner is Bash on Ubuntu on Windows -- This is basically the entire Ubuntu user-land running on top of windows, and gives you a full Ubuntu command-line environment right out of the box -- its not "like" Ubuntu, it is Ubuntu -- You can run any Ubuntu binaries you get right from Apt, or you can compile and build from source, just the same as any Ubuntu machine. I believe that's being released to the public with the Windows Anniversary update on August 2nd (based on Ubuntu 16.04), but I'm not 100% certain; you can get it on the fast-ring now though (based on Ubuntu 14.04).



In any event, you'll always want to ensure that your program compiles and runs correctly using whatever environment your work is graded against. Even if you think your code should work and be portable, you don't want to start racking up zeros because you didn't test it.

#5300613 Copyright

Posted by on 13 July 2016 - 04:49 PM

Copyright grants its holder two broad categories of rights. The first is essentially a government-granted monopoly to the creator of an original work for the exclusive right to distribute it -- the holder is the only one who can publish, reproduce, perform, display or export the work, and is the only one who can license or sell those rights to a third party. The second right is the exclusive right to create derivative works -- only they can produce sequels, prequels, side-stories, etc. using the characters, settings, and the "universe" they've developed. Again, they can license or sell any of these rights individually, or altogether, but they are not free for the taking.


Keep in mind that these are matters of civil law, and the standard for proof of infringement is something like "would the similarities lead the average consumer to believe that these films are drawn from the same pot as the games" -- if the answer is yes, you would be found to be infringing. That means you must avoid even the appearance of continuity between your story and theirs (by which I mean logical continuity, not literal continuity) -- you certainly cannot imply continuity, much less claim it outright.


So, you can create your film epic using the framework of what you've been inspired by, but you'd need to strip off any features readily-identifiable as being taken from that creative universe. There's also the matter of context -- Orcs are a general enough concept, war between races of men and monsters is general enough, but put together in culmination towards something that looks an awful lot like the warhammer universe, is hard to argue that its mere coincidence, even if you don't use specific characters or places.


A good rule of thumb is to avoid riding on the properties coat-tails. If the thing you're doing doesn't make sense without the other properties existence, or wouldn't be viable without an implied relationship between them, then you're riding their coat-tails and there is only the barest of chances that you're not infringing.


Another good rule of thumb is that you should always consult a lawyer if its not 100% obvious that what you want to do is safe; and that even if it is you should still consult a lawyer to make sure you're doing it right for your own protection.


Standard disclaimer -- I am not a lawyer, neither are most people here. Even if they are, they are not your lawyer. None of what's here constitutes legal advice.

#5297795 Have I been aged out of the industry? And where else can I go?

Posted by on 24 June 2016 - 12:20 AM

What were your specializations in the industry? Graphics? Simulation? Optimization? Were you more of a generalist?

#5297776 Have I been aged out of the industry? And where else can I go?

Posted by on 23 June 2016 - 08:57 PM

Maybe its your resume?


Certainly you're experienced, but if you've had a long stretch without having to job-seek its possible your resume isn't in a contemporary style or doesn't use the right buzzwords, etc. Especially if you're looking at medium and large-sized studios the very first thing a resume has to do is get past the HR drones. Last month, after 5 years in my current position, I had to update my resume for a different role I was interested in inside the company -- It was a lot more work than I would have thought to bring my old resume 5 years forward all at once.


How are these companies that aren't interviewing you getting wind of your age anyways? If its in your resume or explicitly in any professional profiles you might consider removing or making that information less front-and-center. Hopefully I'm not out of step with the resume angle, its just the fact that they're apparently getting your age from it which gives me concern that it could be part of the issue.


Finally, some standard but seemingly-uncommon advice on job-seeking:

  • Use your contacts -- I've read that referred resumes are 20x as likely to land a follow-up (phone screen or interview).
  • Cover letters should always be customized to the position -- show interested in the company and position, and share why you think you'd be a great fit.
  • Remember that the purpose of a resume is not to get a job, the purpose of a resume is to get an interview (or whatever next steps are).
  • Stay positive -- If they're looking at your resume, they want to give you an interview; if they give you an interview, they want to hire you. its just the process of whittling down.
  • Be aware -- The biggest reason job-seekers are cut short of the position they want is not lack of knowlege, its risk. Be specific about what you know and have done, and don't do anything that puts doubt in the hiring manager's mind about what you're really capable of. I know of enough who've tried to appear more knowlegable than they were, and it wasn't the lack of knowledge that killed them, it was the the grandstanding that painted them as a risk.