• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Sphet

Members
  • Content count

    692
  • Joined

  • Last visited

Community Reputation

631 Good

About Sphet

  • Rank
    Advanced Member
  1. Quote:Original post by Tom Sloper To be a producer, you really really really need video game experience. QA experience is excellent for that. It's really really hard to break in as a producer with nothing but external management experience. I know a lot of producers who started in QA. I don't know any who started as managers in some other industry. Did you read the producing FAQ yet? Tom, it must be different where you work. In our studio, and the studio I was at before, a producer really needs management experience, scheduling experience, and people skills. In my opinion, a good producer understands how to work with the other area leads (technical, art, QA, audio, design) to establish whether the quality bar is being met. The area lead is responsible for quality & scope. It's the producers job to make sure the project gets done on time and on budget. jthomson166, you'll find opinions differ. Why not contact some local studios and see what they have to say?
  2. Quote:Original post by adt7 I think I'll just go with using strings rather than an enum for now. Doing string lookups each update doesn't seem the best way of doing things, but it's not like I'm trashing the CPU with enough that it's actually going to matter. Could you use objects instead of enums? That way you won't end up with 'typo' errors the compiler misses. If you have an InputAction class, it just becomes a pointer/refernece compare. You can put a string in there for debugging: InputAction Jump( "Jump" ) InputAction Punch( "Punch" ) AddMapping( Jump, Buttons.A, Buttons.B ) AddMapping( Punch, Buttons.A, Buttons.B ) InputAction action = Punch Jump != action Punch == action Since they are all InputActions you can store them in lists, or arrays, or dictionaries. As long as they are classes, you get equality only if the pointer matches, unless you overload IsEqual(). Of course you cant switch on them, but you can load them into a dictionary with delegates just fine. If you InputAction an interface only, the end user can do whatever he wants with the implementation, which might be useful for actions if you need to extend them for client reasons (is it currently valid, etc). Why would this not work?
  3. Quote:Original post by jthompson166 Thank you, Sphet. That was very detailed. I appreciate the obvious effort. And I do mean management when I say producer. I have never heard of anyone equating design with producing, although there are line producers. Your take on QA is very interesting, but the problem with the current market is that there isn't much else out there for someone with little to no experience. I think that's why I would encourage you to look for opportunities outside the industry. Management experience of any kind is more useful than none. In fact, in our studio, the majority of our producers come from outside the industry and they are good at their jobs.
  4. I'll bite, but I don't want to disclose too much information. 1. What is your name? Title and surname are adequate. (i.e. Mr. Smith) pass 2. What position and/or title do you currently hold in the game industry? (i.e. art director, audio technician, etc.) Technical Director 3. How many years have you worked in the game industry? 10 4. What are some titles that you have shipped which you would consider notable? Lots - mostly to critical but not financial acclaim: sega soccer slam, NHL Hitz, Need for Speed Hot Persuit. More recently for larger first party developers at my current studio. 5. As I said before, it is my aspiration to become a game producer, and to help in achieving this I will be pursuing a masters in business (possibly through night school). I also plan on finding a job in the industry and working while going to school in order to gain at least two years of experience by the time I graduate. Would you consider this a wise course of action or would you suggest something else? Do you want to be a producer or a designer? Be clear - some studios call designers producers, which is wrong IMHO. If you are interested in being a producer (ie. administer the schedule, make sure people show up for work, work with the publisher) then go for the MBA if you have the strength. Unfortunately, getting an MBA while working in the industry might be difficult (exhausting). My suggestion would be to spend time getting management experience in a similar industry: software development, QA management, larger team-based organizations. From there, try to break into the industry with management experience. The MBA is something you can get under your belt later, once you've build up some real career experience. I don't think anyone other than our studio head really needs to know that much about business - more about soft skills, mentorship, risk assessment, teamwork and general scheduling strategies. 6. If you answered yes to question 5, and keeping my career goals of a producer in mind, what would be the wisest entry-level position for me to pursue while going to school? (i.e. art, QA, etc.) And why? Please note that the position of a programmer is not an option with my skill set. See #5 - don't focus just on the games industry. Not only will it suck up all your spare time, you'll not gain a lot of useful experience being a tester. Contrary to popular belief, I feel the stigma of being a tester in a company will haunt your resume for the rest of your career. The impression is that anyone who is willing to do the frustrating job of testing can get a job in QA, so what makes you special now that you have it on your resume? I've seem people come to the industry ice-cold experience wise and get hired of testers because of that stigma. I'm not saying it's fair - but it's true. If you can, you'd be better off trying to get an unpaid internship as an associate/junior producer, or designer. People in QA seem to just be on a three or four year journey where eventually they drift off into something unrelated. 7. In any afore-mentioned entry-level positions, how much can I expect to earn as a yearly salary? And how many hours a week can I expect to work? Intern? None. QA? you won't work yearly; it's all contract work and low wages. In either case you'll work 40+ hours a week, plus weekends for QA, as long as your contract lasts. If you look for a job outside of the industry, you'll make more. It's going to depend on the market you live in. 8. I currently have several games and numerous art assets in my portfolio. Keeping my career goals of a producer in mind, what should I push in my portfolio to speed myself along that road? All the good stuff - keep it small and succinct. If you are looking to be producer, highlight those examples where you managed the group, or facilitated dialog. If you did scheduling or task breakdown, highlight that as well. If, on the other hand, by Producer you mean Designer, then highlight all the design-related tasks. Don't put anything in there that uses unauthorized content (ripped, or copyright) and make sure it is solid. If you put executables in there, put videos of the game running too, since I won't ever run an untrusted exe. 9. Do you have any advice or comments that you would like to add? If, by Producer, you mean Design, call it Designer from now on. In the film industry, it is a bad sign when Producers start telling the Director how to make the film - we need to break that habit in this industry as well. If, by Producer, you mean team management, then I would suggest reading up on all the different management styles (agile, scrumm, etc), and then throw out any conviction you might have that any of those are right - it's a dance where you work collaboratively with your team and sometimes management styles change. Furthermore, gaining the trust of your peers comes through gaining their respect by being honest, accountable and transparent. Producers fail because they cater to the boss instead of their team. No game can be made without the producer - true - but without engineers and artists no producer can keep his job for long. Best of luck. S.
  5. We have a number of graphic designers who work in a couple of interesting ways: 1. As a concept artist who does a lot of design-related work for presenting a homogeneous art aesthetic through solid graphic design work. While most of this time is spent doing concept work, some of his time involves good old fashioned typography, page layout and 'design thinking'; ie. color theory, composition, and aesthetic problem solving. In this role +1 for being a good drawer, obviously. 2. As a front end artist who does a lot of design-related work presenting an integrated, thoughtful user interface to the end user. Our company uses a custom front end tool that requires bitmaps to be exported from Photoshop and composed in the tool. Sometimes the source of the images is Illustrator. Mock ups are usually done in Illustrator or InDesign. With the widespread adoption of ScaleForm, all of this is done in Flash, so if you have solid design skills, a good understanding of typography and a passing knowledge of using Flash, you might land well there. 3. As a Graphic Designer, working on pitch documents for publishers, or doing marketing work. Obviously, if you are good at 1 or 2, you'll be able to do 3 - which is how it works in our company. Sometimes we get the front end designer to do some straight up print or electronic design work at the right time in the project. Like everyone in the gaming industry (including programmers) your value comes from the mixture of your skills. Straight up graphic designers will struggle to find work, but combine that with Flash experience, or concept art, and you'll find work no problem. This is true of game designers: if all you can do is write paper-based game design, you'll have a hard time cracking the industry, but if you also have experience testing, or are also a screen writer, or a level designer, you'll get more attention. Best of luck. S
  6. Quote:Original post by jjd So about a week ago I gave two weeks notice to my current employer, so this is my last week. Last week I took a half day using 'personal time'. This is distinct from 'vacation time'. Whereas vacation is accrued over time according to the number of days you work, personal time is a fixed amount alloted for each year. Now I am getting a letter from HR asking me to convert this personal time to vacation time because 'it is company policy'. The difference to me is that I get paid out vacation time when I leave but not personal time. So they're screwing me out of half a days pay. Sure, it's not a lot, but why should I lose half a days pay? So my questions is, is this legal? Can you take away a benefit like this because I have resigned? I think the question might be - how much is a good reference worth to me? The last two weeks at any job can make or break your ability to depend on that employer as a good reference for future jobs. From my perspective, I'd take the high road and eat the losses.
  7. I hold a Bachelors of Fine Arts (BFA) and the equivalence of a BSC. After being in the industry for ten years, I find that everything I learned in the BFA is relevant to my job as a technical director. It helps with the communication with art directors but it also breaks down barriers between technical and art sides because different disciplines can't hide behind the language. Fundamentally, any time you come to the game with more skills than less, it's a win. S
  8. Quote:Original post by stupid_programmer Quote:Original post by yaustar Quote:Original post by Jonny_S I chose to do vanilla Comp Sci and I'm glad I did now, cause I ended up working for a bank and I wouldn't have done that with a specific games degree ;). Why not? Because game schools still really aren't viewed as 'real' schools to companies outside of games. The resume would probably be tossed if a bank saw you graduated from Full Sail (or whatever) with a degree listed as 'game design' or whatever it is they call it. To re-iterate Jonny S's point, I would invest in a true Bachelor's degree for two reasons: you can build on a Bachelor's degree with more education that can take you into very different places (MBA, etc), or you might hate the game industry. Ironically, game schools can often leave your resume in a pile of 'maybe later' as well. I have had a lot more luck with hires that did a comp sci/comp eng degree compared to a game school. In fact, we've had more luck with 20 year old kids who programmer all through their teens than some of the guys coming out of game schools. My impression is that the game schools are kind of like buying a really expensive ticket to a job interview that often the candidate is not ready for. Of course there are exceptions, but I believe those candidates would be exceptional even if they graduated with a BA in English history. I would suggest contacting local studios and asking if you can do information interviews. Get as much information from them as you can about the business, and what it involves. First off, you'll get tangible information about the industry, but also you'll start building a network of potential employers once you are ready to enter the job force. Best of luck with your career! S
  9. Rubicon, I think architecture is a great idea. A lot of our level designers and 3-D modellers would benefit from having a better grasp of formal architectural design theory. However, I also feel that solid understandings of colour theory, art history and critical insight are also beneficial. I would recommend a Bachelor of Fine Art, where the focus is on 3D modelling courses and architecture. Not only can you build that degree into a masters, if you ever want to, but you also prepare yourself for becoming an Art Director within the industry by having a broader understanding of how visual art functions both within games as well as in the general popular culture.
  10. Quote:Original post by Gumgo Hm, that sounds pretty bad. I think I'll just stick with serial operations then. That's my bet too. We just went through this process at work, and ultimately decided against SSE - it's impact on readability and usability can negatively effect developers in the general case. Instead, we profiled the code and rewrote one or two key places specifically to solve those cases. Best of luck. S.
  11. While I am late to the table on this debate, I'll throw in a couple of pluses and some minuses for XML. Here's the context we use it in: we use XML in our content toolchain, with our inhouse level editor reading/writing XML for level data. Our level editor is not a geometry editor, it is only for composing scene logic, so we never store a lot of vertex data in XML. Minuses first: - Not human readable. Just because it uses characters we understand does not mean a 200MB file is human readable. MSDEV almost dies just loading the thing. The only upside of it being human readable is that you can, if you need to, search and replace if something is horribly broken. And human writable? Forget it! - Slow to load. Parsing XML is slow. There's no way around it - at some point a 200MB file is going to load a lot slower than a 20MB binary memory imaged alternative. But as others have said, this minus is somewhat negated by the use-case domain - ie don't put model data in there you expect to load into the game. Pluses: - XPath queries. XPath queries allow us to perform compound, conditional selects on some of the nodes in the XML document. Since an XML document represents all of the content in the level, we use XPath queries all over to pull out specific object types and pass them on to other sub systems. XPath is nice because it is documented, supported by all language domains we use XML in, and there are great tools for building up XPath queries interactively, such as XPathmania. In our company, where everyone is responsible for the build pipeline work, this kind of standard really saves us. As the engineer responsible for designing the pipeline, I'm glad I don't have to implement a node find function, nor support it, nor document it. Engineers are still coming to me to show how the expressed some XPath query to simplify reading data back that would have been a big mess to write in C++ as conditionals on data. - Cross-language domain standard. Our level editor is C#, the build pipeline is Python, our converters are C++. With XML, each of those languages already has an XML API that supports XPath. As a result, we can emit data from C#, and perform the same XPath queries whether they are in C++ or Python. Furthermore, in Python, the XPath queries are defined in Python, but the conditional matches are performed in C++, which gives us substantial speed gains in our pipeline. I can't imagine writing read/write code for all those languages, or making a lib that can be linked from all those languages. I can't stress enough the benefit of cross-language support coupled with a standard - we get immediate comprehension of our system because people have used XML before with some language. - The data tree is dynamic once loaded. We do some steps in the pipeline that are as simple as loading the tree, find elements of a certain type, putting those in a new tree, and writing it out. Sometimes our manipulations are far more complicated, such as completely replace specific nodes, or changing the types of all instances of a specific property when the sibling property of some other object has a specific value. While this is more about the APIs developed to support any load/save format, I know that if I had to roll my own around a memory imaged binary, and just binary stream, I probably wouldn't have written something as effective as this. Furthermore, the tree manipulate is done pretty quickly on all languages, again in C++ when called from Python, or any other binding. - Downstream clients can infer structure of the data. While I argue that XML is not human readable, it is readable enough that downstream clients can infer structure from the XML, effectively writing consumers without going back to the original source that generates the data. We make use of a lot of type descriptors as attributes to properties in the XML, and often engineers never look at the level editor to see what data it generates, instead only looking at the XML. With binary formats, this would be impossible. I will admit I was skeptical at first of XML, but the time we've saved on adopting it as the transport for our level editor is staggering. In fact, the adoption of a number of third party tools and languages has saved us on the tool, but that's another story. I'm with all the people who point out that XML is ugly, and hard to read, but the bottom line is: if you don't need to look at it too often, isn't it about the ability to make the job easier? Ultimately, that was the final criteria for us. S.
  12. Quote:Original post by Ariste Quote:Original post by Kylotan If you can do away with Entities entirely, then it seems like a very clean approach. Just update each subsystem and each one updates the components it knows about. Why have it iterate over entities which typically have a one-to-one relationship with the components of interest? Couldn't all this per-entity data just become another type of component? The thing is, some properties need to be visible to nearly every component. What's the point of sticking them in their own component? What do you gain? Note that Entity doesn't even need to be updated. In my implementation, it's not. It's essentially a container for positional and rotational data with some metadata attached. Entities don't act; they're acted upon by their components. Moving Entity's data into its own subsystem would only complicate this process. I also find it convenient to use Entity as an interface for component retrieval. If one component needs access to another component, it queries its Entity. This makes sense conceptually, and it's really easy to implement. You don't need to pass around pointers to every subsystem or some other such mechanism. In your engine, you've made an assumption that every entity has a position. Consider for a moment that you have an entity that simply plays music. It's not environmental - it just plays music at an adjustable volume. It has no spatial location, so why suggest that it does by including position in the Entity class? If you have an Entity class, I believe it should be as light weight as possible, presenting the bare minimum required for finding components and identifying them.
  13. I think you might get more benefit from implementing two data structures: One is a structure that is owned 'per team', and has a list for each type of ship. This simplifies the process of 'selecting all of the frigates' of a team. You can iterate over all of the lists if you ever need to traverse the entire fleet (expensive, but once and awhile required). I feel you would rarely use this structure, and it could really just be a doubly-linked list of all the ships a player owns. The second structure is a spatial grid that allows you to do localised queries very fast. You want to perform actions like this: Find all the fighters that are visible to render - Intersect the frustum with your spatial grid, collect all the entities, render them. Rendering doesn't care about who owns what ship. Engage nearby fighters - Intersect a sphere with a given radius with the spatial grid, collection all the entities. Filter out friendlies and capital ships, sort the result by 'priority of attack' and go. You'll want your query functions to take a function object that lets you test whether the object should be returned or not, allowing you to pass in filters for enemy v. friendly. You could also break each grid cell into friendly vs. enemy lists to minimize the filtering of each type, but there I would probably do some profiling first. As far as the grid goes, you might want to use a uniform grid, quad tree, octree or a more dynamic system like a collision detection's sweep-and-prune. Ultimately, the cost of moving the objects from cell to cell must be low, with the emphasis on speeding up the queries. If you use some of the 'loose' versions of grids or quadtrees, you end up spending a lot less time rebuilding the tree/moving entities. If your ships, when created, are put into the first list, and whenever they move, they are moved inside the grid, you'll get both cases handled. I think with these two structures, you'll get everything you need out of the data. S>
  14. Quote:Original post by Hodgman Z-pre-pass was originally used in non-deferred renderers (i.e. without a GBuffer), because the pixel shaders were ridiculously expensive. In a deferred renderer, most of the pixel-shader cost comes AFTER GBuffer generation in the lighting passes - so to reduce pixel-shader costs you should be targeting these passes with optimisation techniques like scissoring and stencil tests. Most Unreal Engine do not use a GBuffer or deferred lighting. I'm in agreement here - with a deferred rendering process, are you not already limiting the costly pixel shader operations to once-per-pixel? The generation of the GBuffer data should be pretty lightweight in comparison to the deferred step. If it is not, isn't one of the benefits of a deferred renderer lost? In any rendering environment, you'll want to make sure you have a system that keeps as much complexity off of the visible area as possible. That means culling it somehow. Occluders and z-prepass can help you with what's in the visible frustum, but you'll need to give the gpu a hand trimming down the amount of data you are sending, since you'll most likely be vertex bound during gbuffer generation.
  15. I thought I would update this in case anyone searches for the topic. While I did end up getting the funnel algorithm to run on incomplete costs, I achieved almost the same results by subdividing long edges into three nodes: both end points, and a midpoint. It increased the number of nodes potentially searched but was ultimately faster than performing the funnel at every step.