Zeyelth

Unfortunately, there aren't a whole lot of game developers who focus on story, and of those that do, few studios employ more than a handful of writers (you can get a good idea by checking the credits list of published games). And not to dash your hopes or anything, but there isn't really a lack of ideas in the games industry. Nearly everyone in the industry has at least one good idea, game concept or story which they would like to develop, given enough resources. What makes a game great is not the idea, or concept, but the implementation and execution. That said, if you really want to get into the industry, don't give up. There's plenty of studios out there, both indie and AAA (with quite a few located in Stockholm, Sweden), and there's always the option of starting your own. As for grades, well... If you study at university level, your focus should be knowledge, not just grades. Also, use some of your spare time to practice your skills. If you're a writer, then write. If you're an artist, draw lots of art. If you're a programmer, code away. Quality over quantity, though quantity tends to result in higher quality over time... While grades may be important for some employers, game companies are usually less interested in grades, and more interested in what you can do. Being able to show off previous works—even if it's just hobby projects—is worth a lot more than grades, although having a university degree is still a plus. When applying for a job, programmers are generally asked to show some sample code, together with the usual interview questions/tests. Artists and writers would typically need to build a portfolio. It helps if you can show off something which is relevant to the company you are applying for. If a company makes action games, show that you can write action scenarios. If a company makes RPGs, then maybe a short story with interesting characters is more appropriate. Whether you should go for a gamedev focused education or not depends. In most cases, all things being equal it's often better to go for a more general education. For programmers, a M.Sc. degree in Computer Science is often better than a 2-3 year gamedev programming degree. It may not always matter to the employer, but if you fail to find a job in the industry, or if you decide that you want to do something else, then a gamedev degree is going to be of limited use, while a M.Sc. or equivalent is still a huge plus... If you do go for a gamedev education, make sure that the institution is endorsed or has connections to the industry, otherwise you may end up with some useless, quasi-academic fluff. Other than that, contacts is probably the best way to get a foot in the door. I got most of mine from my university studies. In retrospect, I think they were more valuable than my actual education... Finally, the best way to build a relevant portfolio is to develop games, preferably in a team, as that is exactly what you will be doing at a company. If you need motivation, there are plenty of gamedev competitions you can join, from just-for-fun amateur level, to more serious indie competitions, where the winners often end up forming successful indie companies.

Well that hasn't happened in this thread, so why did you bring it up? The topic did seem to turn into a discussion about how programming in higher education is taught and rants about college/university education experiences. The guy's in high school. I'm not sure it's all that relevant just yet. I strongly disagree. Regardless of whether a kid falls in love with coding or intends to pursue it as a career, I think that given society of 2012 and the unstoppable direction of technology, those kids who don't understand basic parts of computer science - especially the notion of programming (and all the tech savvy it builds up) and being able to do the simplest stuff like hello world and a factorial function - are at a huge disadvantage for their future. I think it's natural to view your area of expertise as important—even vital—but it's often not. While it's becoming increasingly necessary to understand technology and related concepts in today's society, it's not the same as knowing how to program. It's a bit like saying you need to know how to build an engine in order to drive a car, or have an in depth knowledge of chemistry/physics in order to cook food; knowing programming is a useful skill, if only because it boosts your problem solving skills. However, it's by no means vital, or even needed to survive. Knowing your way around common user interfaces is enough. In fact, UIs have been specifically designed so that you can use them with very little knowledge about the underlying system (ideally none). In game development, an artist needs to be aware of technical limitations, what a polygon is, and why it's a bad idea to use a million of them to render a chair. Programming is not really necessary, although an artist with some programming skills could aim for a position as a technical artist. While I agree that there should be better education with regards to technology in schools, and definitely agree that learning should be made as fun as possible, I feel that you are projecting your own desires here. Not everyone has an affinity for technology. In my experience, most don't. However, a short introduction to programming, together with some hands on demonstration as part of a general technology class, may be a good idea to find out who is interested in the topic. You could then allow kids to take an optional course, if they want to. I would actually argue that this should be done for every subject. Going on an off topic rant about education for a bit here, but I feel that the ideal system should carter to an individual's natural talents and area of interest whenever possible (balanced against usefulness, of course). The current system in most (all?) countries tend to suppress creativity and shoehorn everyone into roles they may not be very good at, or even enjoy. This is why I asked what Andrew was really interested in. Remember, OP said he wanted to "make games". That does not necessarily translate to programming. Maybe that's his thing, maybe it's something else. Maybe he enjoys solving problems, but find the concept of hardware optimisation incredibly boring (or worse, downright scary). He could still be a great scripter though... Maybe he's a good artist too. If so, the role of technical artist may suit him better. I'm not saying he should stay away from programming. I'm saying it shouldn't be forced upon him, and that there are plenty of other disciplines that goes into creating a game. The problem of forcing knowledge on someone is that it may have the opposite effect: They may come to hate it, and actively shun it. An alternative to pure programming would be to let him play with various game engines. Unity, Unreal Engine, CryEngine... Nearly every big game engine has a free version you can use today. Most come with fully functional examples you can play with and tweak. This may expose him to visual programming (graph nodes), scripting, and all the other things related to game development. It's a great way to find out what you're really interested in.

I see these threads pop up from time to time, and they tend to quickly devolve into language wars or some other irrelevant discussion when the question we should really be asking is whether programming is the right choice to begin with. What does he enjoy, and is he already good at something? Before I even go into the programming bit, let me ask you this: Does Andrew want to make games, or does he want to play them? This may seem like a weird question, but I've seen way too many people go for a game development education/career thinking that because they play a lot of games, game development should be super easy and fun!™ Most of the time, these people have no idea what game development is actually about, and quickly drop out once they realise what they've gotten themselves into, either because it wasn't what they expected, or because they picked the wrong discipline. Furthermore, while it's true that most game developers are gamers, gamers may not be very good game developers; when you go into game development, you have to enjoy the process, not just the product. It's the difference between playing in a sandbox, and creating sandboxes for people to play in. My point is, I wouldn't recommend jumping into programming if that's not something he fundamentally enjoys. A good rule of thumb is to find a discipline you enjoy, even when it's applied outside of the games industry. It could be programming, it could be concept drawing, 3D modeling, composing music, writing, creating visual effects, etc... Programming is not required to make games, although knowing it certainly doesn't hurt. There are plenty of solutions out there which allows you to make games with very little programming knowledge, though if you don't have any preferences and have to pick one discipline, programming is probably the best one. That said, it's hard to give advice without knowing what his goals are, and what he already knows. If he eventually wants to become a professional game programmer, then he will have to learn C++ (probably C++11 by the time he's done). Although depending on who you ask, it may not be the best starter language. In general, there are four languages commonly used in the industry: C++, C#, Python and Lua. The latter three are mostly used for scripting and/or tools development though... For mobile platforms, there's Java (Android) and Objective C (iOS). I'm a bit reluctant to give advice on any particular starter language. Python and Java are generally used as introductory languages at universities over here, because you don't have to know that much about memory management and such. Python is fairly easy to read and is great if you want results quick, which is an important aspect for beginners. It's also easy to set up, and everything needed to run it is free. However, it's more suited for prototyping and may give you some bad habits. Java or C# may be a good middle ground as they are syntactically similar to C++. However, they are a bit harder to set up, and C# pretty much requires Visual Studio (there's a free Express version, but I don't know what the exact limitations are). Maybe start with Python for the basics, and then move on to C# or Java once that is done. C# + XNA may be a good choice, since there's quite a bit of documentation and tutorials for it, and it's been used by quite a few indie studios. Again, not sure how far you can get with the free version of the development environment, but it's worth looking into. Here's a collection of links which may prove useful now or later on, although some may contain outdated knowledge: http://www.python.org -- Python homepage. Contains everything you need to get Python up and running http://notepad-plus-plus.org/ -- Notepad++, Text editor with support for syntax highlighting and other useful stuff. Pretty good for Python development if you don't want to install a full blown development environment. Also free. http://learnpythonthehardway.org/book/ -- Haven't used this myself, but heard good things about it. Teaches Python in small chunks, starting at a very basic level. http://www.gamedev.net -- game development community http://nehe.gamedev.net -- NeHe, has some beginner OpenGL tutorials (C/C++) http://www.pygame.org -- Haven't used this myself, but have heard good things about it. Basically a set of modules for making gamedev with Python easier. http://www.xnadevelo...tutorials.shtml -- C#/XNA tutorials. Haven't used them myself, but seems decent enough.

Lots of opinions, and an actual discussion on the pros and cons of various mechanics. Awesome! This is why I created the thread in the first place. This thread is not an argument against people who save/reload to optimise their playthrough; I'm fine with people cheating in single player games. I'm actually in favour of mods and tools which manipulate game data. I love games with an intact debug console. Cheating is only a problem if it negatively impacts the experience for others (i.e. unbalances multiplayer games, devalues achievements, etc.) Ultimately, games are entertainment, and if optimising stats via meta-gaming increases the entertainment value for some, then more power to them. That said, I still believe that it's a flawed mechanic, and that it can be improved upon to the point where you no longer feel that save/reloading is necessary, even if the outcome is less than ideal. I actually try to avoid reloading when a bad roll improves the flow of the story. Likewise, I can sometimes reload when an outcome felt unrealistically good. I don't particularly care if people cheat, but I don't want to feel that reloading is necessary for the story to make sense; it's a workaround for a broken mechanic, or at best, an unbalanced design. And by incentive, I don't mean some powerful item, skill bonuses, or anything of the sort. I'm talking about making the player feel satisfied by the outcome, even if it's a failure. Something which makes the player think: Well, that sucked, but I totally deserved it. The incentive would be more along the lines of a good narrative flow. Part of my problem with the "current" design is that you are rewarded for succeeding, or punished for failing, however you want to look at it. In other words, a reward system is applied to a mechanic which you can't really control. The result is that the game actually gives you an incentive to cheat, not the other way around. This is a rather binary statement, and is an attitude I find to be rather counter-productive. No offence, but it reads like "We can't simulate the world perfectly, so there's no reason to even try." A better solution likely lies somewhere in between, with variables you can control (accumulated actions and events throughout the game), combined with some randomness to give it flavour, without taking over completely. I'd like to go over some detailed design suggestions, but it's getting late, and this post is already getting far too long. Indeed, we don't have to implement the butterfly effect, but these type of seemingly random events does not translate well to games. At least not if they are replaced by a random number generator. Two things: If a skilled person fumbles, he or she will likely know why. Maybe a sudden gust caused a loss of balance, or sleep deprivation caused a loss of focus. We don't get this with the way skill-based dialogue options are currently implemented; there's no feedback. No reason. A skilled person will be able to recover in the face of failure. If a smooth talker says something inappropriate, he or she could quickly turn this around by making a joke about it, drawing attention away from it. Likewise, a juggler could counter an accidental stumble by throwing the balls higher, giving him/her time to catch the one s/he's about to drop, etc. Both of these points are possible in pen and paper RPGs, because the DM can give detailed explanations, and adapt to allow players to recover from fatal mistakes if they are creative enough (and if it's appropriate). Agreed, with emphasis on "to a point". It shouldn't feel as if the failure is out of character, or if it is, the game should provide a reason for it. Maybe the character is drunk, or is otherwise in a poor/awesome mental state. Though again, things like that could actually be used to replace randomness. Given enough of them, the outcome will still be variable, but you can also figure out why, after the facts. Especially if hints are dropped in the response to your attempt. If my hypothetical bard, with a high success rate of persuading people, had one too many pints, and suddenly got rejected with a response of "Go home bard, you're drunk." I wouldn't even want to reload, because it's actually quite appropriate. Yep, that's one of the biggest flaws with Mass Effect's way of doing things. What I did want to bring up with my example though, was how your responses are remembered, and will be referenced later on, sometimes even in later games. Without going too deep into spoiler territory, one example which comes to mind is the Rannoch mission, where choices from all three games will affect the available conversation options at a rather critical moment. Sure, the Renegade/Paragon points as an implementation for reputation could be better, and we could argue about some of the details of this mission and resulting conversation, but the key point is that success or failure is largely based on your own actions; ultimately you only have yourself to blame.

Not going to bother with quotes, but following up on what AGX-17 said: Randomness in conversations is a cheap way of "simulating" all those little tiny details which normally affect other's perception of you, and the result is not very good. It's not that randomness itself is bad, it's that the game doesn't offer a plausible reason for the failure; there's no feedback (and no, seeing "persuasion check failed" printed on screen is not proper feedback). In real life, you get subtle clues, and you can infer the reason from that; you didn't seem to care (lack of sleep), didn't seem very enthusiastic, etc. With classical CRPGs, we have been conditioned to accept that everything is determined by a roll of a die, with some modifiers applied. Again, this is a legacy mechanic from way back when the only alternative was having a storyteller (DM) say "because I said so". Games which rely on pure randomness for non-combat situations are often based on one of the many pen and paper rule systems. Given the choice between completely static conversation trees and random-influenced conversation trees, I'd choose the former, even if I don't think it's very good either. That said, there are quite a few ways to avoid involving randomness. Some which have even been implemented in highly successful games. For example, Mass Effect use skill points to limit your conversation options (charm/intimidate), but the available dialogue options vary depending on other factors too; taking sides open some dialogue options and closes other. Some actions may alter, or even completely remove some conversations. Sure, there's a lot of other problems with Mass Effect, but in most cases there's an actual reason as to why you can't steer a conversation in a given direction. When it comes to computer games, there's no real reason NOT to store all those tiny details which the randomness was intended to replace. Furthermore, you don't have to limit skill checks to a simple pass/fail, you can add other requirements too; maybe your trap-finding skills aren't that great, so you can't see the traps unless you get close enough. Bumping that skill would simply mean that you can see them from afar. In this case, randomness could also be involved, but it shouldn't affect the skill check, it should be applied to make the visibility range variable (simulating flickering lights and other things which could help or distract you).

Sure, I could be apply some strict self-control and not reload saves when I get a bad roll, but that's missing the point. The point is that the mechanic isn't well suited for computer games, and could be replaced with something better. It was originally designed back when all you had were a handful of dice, and in some cases a deck of cards in place of random events. Yeah, I would prefer some other checks which tie in to something more tangible, like past conversations, your reputation, knowledge (visibility of map), etc... Not saying that OE will somehow write a situation where you fail a check and have to start over (that's just bad design), but the mechanic often introduces randomness in situation where there should be none. As an example, randomness on persuasion checks. What exactly does the randomness represent here? A sudden memory of something funny which breaks your pokerface? It would be more natural if your choice of words made a difference. Having a low int. or charisma could restrict you to a subset of replies, or make some options less viable (charm may not be very effective if you just soiled yourself), but I don't see why the *success* of a given option should be determined by chance. Picking locks? Yeah, randomness could definitely represent the quality of the lockpicks, making some more likely to break than others. I think Skyrim implemented it for durability, while making stats affect difficulty, which tied in to your own skills. Not saying that PE should use that mechanic, but it's something to consider. tl:dr; I want to be punished for making bad choices, not because the random number generator decided to stay on the low end of the pool.

Jargon may help flesh out the world, but it has to be done correctly. If the PC is supposed to know something, the player has to be introduced to the concept, preferably without breaking the fourth wall. A well written game or book will do this so seamlessly that you at no point have to stop and try to figure out what a word means in order to understand what is being said; a word could be used in such a way that the meaning can be inferred from context, even if it has been explained previously (you can't expect people to remember some random line from a conversation which happened several hours ago). I do agree on some points though. For one, I hate it when characters interject made up words in the middle of a sentence when there's already an English word for it. Makes it sound cheesy and pretentious. If the word describes a concept which doesn't exist in the English language though? That's awesome, and should be encouraged, because that's how languages evolve in the real world... Though it shouldn't be used as an excuse to use the same couple of words all the time. Regarding Skyrim, I don't think it was necessarily a bad thing. Sure, for the first hour or so, it was a bit confusing, but your character was evidently supposed to know most of those words. The key thing with Skyrim though, was that it didn't prevent you from playing the game, or from following along in coversations. Sure, maybe you didn't understand what a "Nord" was, or what they meant with Imperials and Stormcloaks, but it didn't really matter. Context made it clear that it Nords were a group of people, and that Imperials and Stormcloaks were rivaling factions. For the first few hours of the game, the details weren't really important.

That could work, if carefully balanced. Otherwise you may end up with a situation where you get the worst roll possible in a really important situation, which may require you to massively level up a skill just to pass that check. On the other hand, it does add a frustrating aspect to character building which is very hard to plan for; there's no real feedback, and things would just seem to randomly fail, without any reasonable justification ("hey, I just talked down this powerful demon, why can't I convince this peasant to go away?")

Whatever method they use for distribution, unless the distributor provides updated packages and a client which takes care of the execution details, I prefer tarballs. Tarballs complete with any needed libraries included, and a shellscript which you use to execute it. Why? When the included libraries no longer work because they're out of date, you can simply install new ones and tell the shellscript to use them instead. Such tarballs can also be dropped in the home directory, and executed, without cluttering the rest of the system with random files. Furthermore, if you really wanted to, you could roll your own distribution specific package, most of them are little more than zip-files with instructions on where to place files and a list of dependencies anyway... Oh, and for users who aren't that savvy, they will likely only run into issues when the libraries stop working, and with a tarball, it would be fairly trivial for the community to provide an updated shellscript.

I don't think porting the game would cost that much. At least not in terms of getting it to run on other platforms; there's a reason why they're so confident about the Mac/Linux port. I guess it depends on what licence they have with regards to Unity, and whether they modify it, but any port to a platform Unity supports should be fairly painless, barring any hardware constraints such as memory and CPU. Though they could probably "fix" most such issues by lowering the resolution of assets instead of spending time on optimisation. What will require time and resources however, is adapting the game to a non-keyboard and mouse setup, which would likely create a rather different experience. A straight up port with a simulated keyboard and a Wii-mote/analog stick as a substitute for a mouse could potentially work, but would likely feel awkward. In any case, I'm fine with a port if they do it post-release, and only if it does not impact the PC version in any way.

Did a quick search, but couldn't find this particular topic. One thing which never really translated well from the D&D based games was the randomness involved in non-combat skills checks. That is, skill checks for conversations, or finding hidden doors, etc. The problem often manifested when your stats were good enough for you to succeed, but low enough to frequently fail. Since a huge difference between a Pen and Paper RPG and a CRPG is the ability to save and reload, this often made for an unfortunate meta-game, where you memorise a dialogue tree, and save/reload until you get it right, and you pass the right skill checks. Is it cheating? Yeah, kind of. But most games I've played completely lacks an incentive for accepting a bad roll of the dice. There are ways around it, but while a bit of randomness in combat makes it less predictable and more fun, I think it's a mistake in non-combat situations. I'm not sure what a good alternative would be, but one idea is to base it on your skills. No randomness, and then shift the requirements over time, depending on things you do. For example, conversations with an NPC at one point in the game may lower or increase the requirements to pass a future check. That way, it's harder to just reload a previous save, and you can use a strategy guide predictably if you really want to.

I think that the option "Yes, not all battles are won with blades and magic" already implies that both methods would be available but, in some situations one would be more effective than the other. Indeed. I mean, sure, there could be encounters where you either have to be clever about it, or flee, because you for some reason are inadequately equipped to win in a straight fight. Although situations where fighting isn't an option at all could easily become frustrating and boring if not done right. Especially in subsequent playthroughs. I don't think that the non-combat option should necessarily let you succeed earlier. For example, I would imaging persuading dragons would be difficult. I agree that it probably would not be as difficult as killing them. With your scenario, I would add an additional outcome. The dragons realize what you are trying to do and kill you instead. Sure, the scenario is rather bare bones. Succeeding or failing to persuade or deceive would depend on your character's level and other factors (reputation? Charisma? Maybe how you respond if "caught", etc.)

The entire point is to be able to solve the quest in multiple ways, resulting in different outcomes which rewards your play style differently. Basically, you can chose to do the quest later (grind levels and use tactics), but you are also able to complete it much, much earlier by being clever (with a different outcome). The idea is to reward players who think outside of the box while still allowing those who want a tough boss fight to have just that. So yes, the scenario could be designed in such a way as to encourage one set of solutions (in this case, not rushing into battle head first), but choosing to deal with the situation differently shouldn't make you feel as if you broke the quest, or that you somehow did something you weren't supposed to (in this case, winning by pure strength and combat skills still solves the quest). Normally, the only way to solve a tough battle is to fight it head on until you succeed. The purpose of the poll was to see how many people would like to be able to solve impending battles in a more clever way. Perhaps by avoiding it entirely, or by turning the odds in your favour through a series of events, triggered by the player. I included the difficulty level of the battle in order to provide contrast, but I guess the scenario could apply to "normal level" battles as well. The "yes" option isn't to exclude winning by straight up fighting your way through, but rather to encourage the use of alternative methods. Something games often discourage due to too much focus on a given game mechanic. The problem for most games is, in the cases where you are able to avoid a fight, you often end up with cut content, or simply miss out on loot. That is, you are indirectly punished for avoiding the fight.

$250 tier for a total of $313 ($25 obsidian t-shirt + $8 obsidian order + $30 shipping). Wanted the Collector's Edition, and I like art books. Couldn't justify $500 for the hardcover version, but then that got added to the $250 tier anyway, so I'm happy. Had the kickstarter happened two months ago, I might've spent my tax refund on the $1000 tier.

I got the impression that this book is going to be a bit larger than the small books you typically get in a Collector's Edition, which would probably cost quite a bit more to produce. Not to mention additional shipping costs. If they made it an addon, you'd likely be halfway to $250 anyway, and you'd remove a large chunk of the incentive for the $250 tier.