• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

1418 Excellent

About S1CA

  • Rank

Personal Information

  1. As above, there is no OpenGL implementation for the PS4...   Direct3D 9 gets you WinXP+. Direct3D 11 gets you WinVista+. Direct3D 11.1 gets you Win8+. OpenGL 2.x/3.x/4.x gets you Linux/Mac/Windows. GNM gets you PS4. GCM and/or PSGL gets you PS3. GXM gets you PSVita. DirectX 11.x gets you Xbone. DirectX 9.x gets you Xbox360. GLES 1.x/2.x gets you Android/iOS. WebGL gets you HTML5. GX gets you Wii. GX2 gets you WiiU.   If you want a cross platform graphics API, you've got to make your own wrapper around most of the above... or you can use an existing game engine that's already done this work    And Mantle gets you AMD. Yep. On PC. Similarly (only slightly tongue in cheek) Glide gets you 3Dfx. PVR SGL gets you PowerVR PCX. On PC ;)
  2.   I haven't made any games of my own, but I have been thinking of some ideas. ... Yeah I guess I need to make more games of my own. Definitely! Most ideas sound good. Most look good on paper too. In reality most have major flaws. Whenever I tell people (outside the industry) that I make games they tell me their 'great' games ideas (that are usually "it's just like XYZ but birds instead of planes") or how the film script they have in their head would make a great game. Sometimes (rarely) people even have ideas about actual gameplay mechanics. Everyone who plays games has some ideas and things they'd do differently. Talk is cheap, ideas are cheaper - but how do you know an idea is going to work or be fun to play? Turning those ideas into a reality by actually making something is how you prove your designs work. It's ok if your ideas fail - it's actually good if they fail - that's good experience, and if you get used to failing early it saves you time (and money once it's a job). An incredibly important skill for a games designer is to work within constraints (time, hardware power, etc). You only fully realise the constraints inherent in your ideas by putting them into practice. You might do some of that stuff on a degree course, but it's really not enough - your peers are coming in with completed games, mods for existing games and lots of little side prototypes that they've done across multiple genres simply because they love doing it not because they were required to do that as part of a course. This isn't an industry that does apprenticeships - you have to do that part on your own! BTW to prove things like core gameplay mechanics ideas shouldn't need too much technical or art skill. 2D prototypes or simple boxy 3D are sufficient to prove most. On a related note, when something's actually playable, that itself generates new ideas and improvements.     Yep, I work at Reflections The universities we work with change from year to year, and the level of connection varies and involve more than just placements (e.g. guest lectures), so "all of the local ones" is the most accurate answer.
  3. I agree with what Tom and ambershee said.    At the studio I work at: We DO take on a very small number of interns each year. NOTE this is for university placement years, not for short term school "work experience". It's done in partnership with universities close to our office. The best N students are chosen from CS or games courses. AFAIK we don't take on design interns, only programming and art. The most successful candidates have a real passion about games and making games; they do a lot of stuff in their own time. As Tom says, expect to apply to a lot of companies to get an internship (all of them if you have the time!:)). Expect to apply to even more to get a placement as a designer - there is no shortage of good ideas (and more people queuing up with good ideas) in the games industry - what is needed is people who can make those ideas a reality - that's why people who get the pure design jobs tend to have experience. You may find intern roles as a "level builder", but quite often that's considered a branch of environment art so unless you have a qualification in say architecture or town planning, or are good at art, that might be out.   The competition for intern and entry level games positions is fierce - think about it, everyone in the world currently doing a games course at university or college wants those positions, so do a large number of the people on this board and similar. So as well as a lot of luck, you need to stand out from the 1000s of people you're in competition with.   How many games have you made yourself? Do you enter competitions like Ludum Dare? (etc etc) How many mods/levels have you made for existing games? Have you learnt to do any programming and/or art? Have you showcased your games (and other creations) much on forums such as this one? Have you covered a broad range of game genres in the stuff you've made (when it's a real 'job' you have to produce good work even for genres and IPs you hate)?   The people who are getting those intern roles are doing all of those things and more, if you aren't you should be! Those things are also major points in your favour for when you apply for non-intern entry level roles.   If you have stuff to show, then include links when you're contacting companies. Local games industry networking events can be a mixed bag - they're a good place to meet student, indie and hobbyist developers who you can collaborate with on more games. They can be a good place to get advice of people in the industry. If you have a good portfolio of games (and related things) you've made, it can be a good place to show people (to get feedback, and to ask if companies have any intern places available).   Game development conferences are good for similar reasons if you can afford to go and have a higher proportion of companies and professional developers.   As a group, the company I work for now also has a graduate scheme that might be of interest to you: https://www.ubisoftgroup.com/en-us/careers/graduateprogram/
  4. Dreamcast 'supports' DirectX too :) http://msdn.microsoft.com/en-us/library/ms834190.aspx   Thing is, because console hardware is fixed, some of the abstractions in the Direct3D you find on PC are unnecessary, so even on the Xboxen (and Dreamcast) there's D3D and another API that lets you get at some of the lower level aspects of the hardware directly - people tend to use a mixture of both.   Regarding PS4, this article: http://www.eurogamer.net/articles/digitalfoundry-how-the-crew-was-ported-to-playstation-4 covers a talk I co-presented at the Develop conference last year and has the few details that Sony allowed us to talk about publicly - as frob says, everything else is still covered by NDAs so isn't open for discussion.
  5. Regarding the job availability question - most of of the available games jobs are not entry level and require some amount of industry experience in a real production environment (ideally with shipped product).   However, there are still some junior positions out there, particularly at indie studios who don't have the budget to pay for senior people. That's one way to get some industry experience (on top of your degree and portfolio of personal projects mentioned above).   The other common route into the entry level jobs is internships, usually at the larger companies but sometimes at smaller ones too (budget reasons as above and external funding is sometimes available to studios for taking on interns). The best performing interns are often offered permanent junior jobs. As an extension of the traditional intern intake, the company I work for has also started a graduate programme which may be of interest to you in a few years: https://www.ubisoftgroup.com/en-us/careers/graduateprogram/index.aspx
  6. I've been reviewing a lot of CVs and interviewing people recently (for senior engine programming posts) but if I were reviewing for entry level jobs my order of preference would also be 100% with what Hodgman said. 
  7. "hello world"   /relurk
  8. Premature optimisation of CODE is bad, but optimisation of code is only a small part of achieving good performance. Ideally:   0. At the start: Ensure the scope of the design fits with the reality of the hardware. 1. Very early on: Ensure the architecture of the engine + game will give the expected level of performance. Comes from understanding of the hardware and experience. 2. Early on: Set some rough budgets. "We're aiming for 60Hz so that's 16ms of GPU time to play with, world rendering must happen in around 8ms, post process in 2ms, etc". Same for CPU and memory. Have in-engine profiling for each system that shows how well each system is doing. 3. Throughout: Design and implement systems with performance in mind ("Cool, so algorithmically this O(blah) but what effect is that having on the cache?") 4. Throughout: Profile systems and check how close they are to the budgets you set. Adjust budgets if necessary. Analyse any systems that are wildly over to see why.  5. Later (alpha-ish onward): Profile systems against the budgets. Analyse all that are over. Optimise the ones that are over or borrow budget from a different system if you can't optimise any further.   Mindset is hugely important. Performance is a whole team thing not just a programmer thing, that's important to get across to everyone - have budgets for design ("you can have N cars on screen"), art ("main character models must fit within X MB, use no more than Y textures and have no more than Z bones"), audio ("must fit within N MB and use no more than M DSP effects at any one time"), etc.   [That's from my experience of shipping console, PC and handheld games, including a few that ran at 60Hz]
  9. 1) What frob and Tom said : work out your requirements first! You need to do some proper project planning... 2) From your planning you should realise that most projects naturally break into phases (e.g. concept, pre-production, production, marketing, debug, ship, post-launch). 3) You'll probably need both artists, but not for the entire project - so work out what phases you need each for and contract accordingly. It's likely you'll need each multiple times - for example the concept artist can help prepare your marketing materials. 4) If you have a genuine tie-break situation (e.g. two 3D artists who are equally as strong on paper and at interview), go for the one who's personality will best fit with the personality of the team (the whole team - even a team of remote workers),
  10. I agree with Tom about networking and when to start applying. There are a couple of other things to bear in mind:   1) Internships are in sync with semesters, permanent jobs are not. Games companies may offer promising interns permanent positions but generally they hire all year round based on project demands. If you have a particular company in mind, keep an eye on what they're up to for clues: if they've just shipped a game it's likely a new project will start ramping up a month or two after. If they've just announced a game, there's a chance they're moving from pre-production into production which can need new staff.   2) Most universities have a computing or games course. Even discounting the people who didn't take it seriously, that's a hell of a lot of new graduates for very few junior jobs and on paper at least most of them look the same - no real job experience and a bunch of education grades. You need to stand out from the crowd - develop some polished portfolio demos that show off your programming abilities - it also makes the interview process a lot easier for both you and for the interviewer because they can ask you questions about technical choices you made and you get to talk about something you know (and get to prove you've not just rote learnt the very basics).
  11. #1, what frob said. In particular, do as much and learn as much as you can about graphics programming before you try to make the jump. For junior roles and for people with no proven graphics or engine programming experience in the games industry, a good demo that shows you have a good understanding* of the core algorithms and techniques is the only way you can differentiate yourself from all the other people who want to transfer from other industries to games. [* When I say understanding, I mean it - if I'm interviewing you for my team I'll want to discuss the details of the techniques you chose and what the alternatives might be - from the interviewer's side it's easy to spot the difference between "copied from a book but doesn't understand how it works" and "understands"].     #2, AAA teams and projects are big enough these days that graphics programming and renderer programming are increasingly two separate (but of course closely related) specialist areas. Many big games use graphics engine middleware or already have their own proprietary engines, so there will be more demand for graphics programmers in the future than there will be for graphics engine programmers. Entry level low-level engine programming jobs are also very very rare. I've worked on a few games now that have had people who spent the majority of their time writing shaders...     #3, what to learn? I think writing a game or graphics engine you'd spend as much time bogged down with software design issues and platform APIs as you would learning actual transferrable techniques. Use an off the shelf engine and skip the low-level stuff unless that's really really what you want to be doing.   Writing a software rasterizer is a good one for understanding a lot of underlying principles. Be careful not to get carried away with 1990's optimisation techniques and methods though, I'd advise Fabian Giesen's series of articles for an up to date look at the pipeline and rasterizers: http://fgiesen.wordpress.com/category/graphics-pipeline/   I'd learn the common basics such as lighting (the illumination/reflectance part and the implementation part), shadows (it's a start having an idea what a shadow map is, but do you know how to fix the aliasing issues?), skinning/animation, particle and other effects (a common entry level task), HDR (fake vs real).   Have a rough understanding of common visibility algorithms (PVS vs Portal, etc) can be useful.   A good book to read for ideas for topics to learn? Realtime Rendering.   Look at some of your favourite games - can you explain how everything is rendered? If not, start learning, start guessing, start experimenting.   Given the higher than average volume of data in graphics, good choice of data structures and algorithms can matter. Good choice means understanding some underlying CPU concepts (Big-O isn't everything!).    Knowledge of how GPUs work and where the performance bottlenecks are in the pipeline is quite an engine-y thing but frame rate is the whole team's concern.   Maths, maths and more maths. It's useful for a graphics programmer. SIGGRAPH papers tend to be much easier to read when you understand at least some of the Greek bits ;)
  12. 'MIN_MAG_MIP_LINEAR' is a DirectX 10/11 style sampler state (part of the D3D10_FILTER and D3D11_FILTER enums). Xbox 360 is Direct3D 9* so doesn't support those things. Look at the filter names in the D3D9 enum and you'll be safe. "LINEAR" for a mip filter (tri-linear) is supported right back to D3D7. [* The hardware, the native D3D9 API, and the HLSL support on 360 do have a few D3D10 features, but it's expressed as extensions to the D3D9 API].
  13. Comments rather than an answer to your specific question. I've been programming as a full time job for 16 years, and a hobby for 25, I can empathise (also in my mid 30s). Som of this comes about when your hobby is the same as your job, I go through similar down periods. Some of the issues you list are just the realities of the commercial world, if what you made at home had to be commercially successful there would be equally annoying (but maybe different) problems. Quote:1) No control over what I make Like the person working in a factory or a bank. Your home programming is more fun, there are no constraints, so is more fulfilling - and that makes what you do at work feel too restrictive. At work you have to program whatever your immediate boss wants. You get more seniority in the company and you have to program whatever the directors want. You become a director (or more commonly, start your own company) and have to program whatever the customer who's paying the bills wants. More seniority gives you more control over how but not what. Quote:2) Finding bugs More preparation == fewer bugs Testing after every change == bugs much quicker to find More experience == less pain; it's just another form of problem solving, it can actually be fun! Quote:3) The continual process of trial and error involved in fixing bugs There shouldn't be any trial and error TBH! I think this is again an experience thing. Most bugs are easy to find. A small handful of bugs are tricky to find, but experience gives you tools, techniques and intuition to track them down more quickly. Fixing bugs should be easy too, in my experience if a bug is difficult to fix it's usually because of bad design or bad implementation based on an incorrect assumption. Quote:4) Trying to work out what someone else's code is supposed to be doing Yep. Been there. If the comments are crap, what's written doesn't conform to any of the coding standards and the person who wrote the code left years ago. Don't try to read the code, just put test functions and breakpoints in and see what comes out the other end in the debugger. NIH Syndrome is a demon in most programmers though, it's difficult to resist at times (sometimes what's there works and is algorithmically correct, just different to the way I'd have done something - in those cases it's better to grin and bear it - maybe adding a few comments to the code to clarify it and keeping a few notes on how it works). Quote:5) Making things that are of no interest to me Same as #1 really. Even things that once were interesting lose their interest and fun. Quote:6) Feeling like a replaceable cog in a machine True for most jobs where you're not at director level really. I've found less of this feeling at smaller companies (I've worked at 3 and 8 person startups as well as multinationals), but that's replaced with more uncertainty because smaller companies usually have a single big customer/job that's keeping them going. Quote:7) Getting no thanks for completing a project. (All the praise goes to the producers and sometimes the artists). Your salary is your thanks. Anything more is a bonus. Just be proud of what you did. Plenty of people don't get credited for hard or even creative work (how many buildings have the names of the builders or even the architects on them?) Quote:It seems there are two kinds of people. People who work as programmers, the ones who love bugs and the ones who swear at their computers. I have worked in web programming, game programming and flash programming and hated them all! Yep, does sound like while you can program, it might not be something for you. I've hated some of the corporate and political aspects of most of the programming jobs I've had, but not hated the actual programming itself. Quote:What I do like is talking to the artists. That's quite fun. I like writing too. And am average at drawing. Now I'm in my 30s and I feel like I don't have any transferable skills to do a different kind of job. Plus I've got loads of gaps in my CV since I keep quitting jobs because they drive me stir-crazy. I think I would like a job organising and helping people in some way. But I don't know what. Producer? (or similar project management). You could capitalise on your existing experience (maybe there are jobs at your own company - talk to your boss, maybe there's an intermediate role without changing company) and make sideways moves. Being a producer (or something like a lead programmer) will have more paperwork, more meetings, more politics, etc, but none of the code woes you hate. Even less creativity, certainly, and still equally stressful, but that's work... If you can improve the separation between work and home, you can be more creative at home. Sideways moves are less risky (but ultimately less fulfilling) than radical ones. Quote:Maybe a conference organiser or something to do with the environment. Your description might also be a sign of being burnt out and/or depressed. Alternative idea: grin and bear it (the job market is too difficult/competetive to be looking at the moment), save up some money, go travelling in some far flung place and work as a volunteer - come back recharged and with a better idea of what/were you want to be in life. Quote:My question is: Has anyone here quit the IT industry and found that they are happier in another job. If so what was it? Not personally (yet? ;)), but a number of friends who have. One qualified as a personal trainer and runs a gym. Another makes giant robotic sculptures and makes money from performance art at festivals and other events. Others got into different fields within IT (i.e. out of making products and into stuff like support and consultancy).
  14. Quote:Original post by Moe I haven't hung out here in a while because I'm finding my interests are shifting and I don't have nearly as much free time as what I used to have. Perhaps that is true for more than just myself? Yep. Developing games is my full time job; other aspects of 'real' life and other hobbies/interests have grown and absorbed what little free time I spent participating on sites like this.
  15. you woulda loved copperlists :-) (video hardware programs with a wait for scanline instruction and a register poke instruction, and due to the timing you could set a video hardware register to different value multiple times across one scanline - palette register poking, bitmap start position poking, and even blitter transfers running asynchronously to the cpu - with the CPU left to do fun things like re-write the copperlist on the fly. Jay Miner deserves a sainthood for services to the demo scene! </nostalgia>