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

Hinch

Members
  • Content count

    172
  • Joined

  • Last visited

Community Reputation

244 Neutral

About Hinch

  • Rank
    Member
  1. Dunno about earning more (most games QA jobs in the UK are about £12k [i]before[/i] tax), but yeah I was going to suggest just getting some sort of job at an established game dev and you'll probably earn around that much.
  2. Most game companies I've worked at had a non-compete clause. At my last job I asked the studio manager about it and he said it was just to cover their butts and prevent large groups of people leaving to form a rival studio, or to stop individuals developing almost identical games on the side and basically stealing ideas. Unfortunately as Frob says they're not likely to modify your contract so you basically have to trust that they won't get legal on yo ass (and be pretty sure that your outside projects won't directly compete with them).
  3. WRT what VReality & Serapth are saying about what interviewers want, there's a big difference between what the HR department (sometimes just 1 person, but not usually anyone with actual developing experience) of a company will be looking for and what the person actually doing the interviews will be interested in. Most established developers will get tons of applications, most of them rubbish, and don't have time to go through looking at the details of every single one so one of the first filters will be "does this person have a degree or higher in a related subject?" if not, thrown in the bin. But still home projects are very useful to have something to show and talk about once you actually get an interview, because the interviewer will be trying to find out what you can actually [i]do, [/i]and probably won't care much about your qualifications. All my experience is with established game development companies, so I can't really say what indies & startups will be after, but given that they probably have nowhere near the volume of applications, I guess degrees will be of little interest and they'll be able to cut straight to the interesting stuff and see what you've actually done.
  4. Just FYI, task manager is a terrible way to check how much memory your process is using as the stats displayed by default aren't very useful and it has mixed up terminology. Get process explorer and have a look at the "Private bytes" value if you want to know how much you have requested from the OS. Here's a brief explanation of some of the different stats you will be able to see: [url="http://stackoverflow.com/questions/1984186/what-is-private-bytes-virtual-bytes-working-set"]http://stackoverflow...tes-working-set[/url] . Also taz, some of that memory used by the vectors might not necessarily be "overhead" (by which I presume you mean 'wasted' memory used for book-keeping rather than storing your own data), they can allocate more memory than you actually request so that they don't need to reallocate and move large chunks of memory around every time you want to expand the vector. It's possible to pre-size them by calling vector::reserve, but if you read the docs you will notice that will try to allocate [i]at least[/i] enough for that amount of data, i.e. it could still be more (though usually it's not).
  5. I notice there're a few pie-in-the-sky features in this pitch that never made it into the final game. I'm interested to know, did they have a proof-of-concept prototype to go with this pitch, or were they able to get initial funding purely off their reputation and this document?
  6. Unity's own docs have some of the best tutorials - http://unity3d.com/support/documentation/ They have a few different languages you can choose between for writing your scripts - Javascript, c# or Boo (their own thing), they all provide the same functionality so you can just write scripts in the one you find most comfortable. And yes you will almost certainly need to do some scripting or programming no matter which engine you choose.
  7. Well yeah to do that you would probably need to be able to create your own geometry on the fly, which rules out UDK. Or you could bodge it by spawning another cube inside your already-extruded cube and stretch out the new one along a different axis, if that would work for your design. Basically it's something you'd have to figure out yourself, because I don't know any game engine that has a feature like this built-in. (Think about what tech is needed to build a typical shooter or platformer and that's pretty much what you'll get in most game engines, anything beyond that you'll need to make yourself).
  8. I don't think UnrealScript gives you access to the raw vertex data of meshes, but you could maybe just build the wall out of 1m cubes and change their x/y/z scales to stretch them out. You could do it the same way in unity, and I think unity also lets you build objects from raw vertex data, but if you ask me that's more complicated than just having some base blocks and stretching them about.
  9. Another vote for UDK, and also Unity3d is good. Both have great toolsets, which is very useful for beginners. Ogre3d is only a rendering engine so you would have to implement other parts (input, networking, audio etc) yourself, Irrlicht I *think* does more but I'm not familiar with it myself.
  10. Well, in the usual case I would agree with you Ryan, except the OP stated that he wanted to get familiar with the IDE most commonly used in academia and the games industry, and I'm pretty sure that IDE is Visual Studio. You could however debate the usefulness of that approach given that most IDEs offer very similar features anyway.
  11. Every game dev company I've worked at (5 so far) has used Visual Studio, even for development on (non-Microsoft) console platforms.
  12. [quote name='Zahlman' timestamp='1297246884' post='4771803'] o_O Did something happen while I was not paying attention, such that AMD and Intel are now major GPU manufacturers, but ATI isn't? [/quote] Well AMD bought ATI, and Intel sold millions of motherboards with crappy embedded graphics hardware. Welcome to the future!
  13. [quote name='dpadam450' timestamp='1296604729' post='4768219'] You cant send a packet per-frame or your network goes to 100% usage and basically you will lag in the seconds.[/quote] Unreal Engine usually sends a packet every frame to/from every player and seems alright. Mostly though it'll depend on the type of game you're making whether it makes sense to do that or not.
  14. Depending on which API you use, you might find there are limits such as e.g. 16-bit indices, which would mean you can't have more than 65536 indices in a single draw call anyway.
  15. Yep that's not a bad article. One modern timer that isn't mentioned in that article is the "Invariant TSC", which is available on new Intel and AMD processors (query for support using the cpuid instruction). It's used by just calling the rdtsc instruction, and in terms of overhead should be similar to traditional rdtsc calls (i.e. much faster than QPC), but unlike the old rdtsc it should always increment at a fixed rate. (Just like QPC, which should also be invariant, I have come across some machines that claim to support the invariant TSC and yet rdtsc values jump backwards and forwards in time quite drastically, so whatever method you use you might want to put some sanity checks in your code.)