• 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

456 Neutral

About Shiny

  • Rank
  1. How's your math? If you're planning on moving onto Direct3D stuff in the future, it's never too early to brush up on your linear algebra :-) (I would recommend 3D Math Primer by Dunn&Parberry).
  2. Visual C# is Microsoft's flavour of C# --> so, an implementation of the spec of C#. The great majority of people use it through Visual Studio because not only do you get a language that makes sense (everything works the way the spec says it should...) -- but you also get access to a massive and really useful library framework (that being the .NET framework). To clear up possible misconceptions -- C++ is in many cases faster than C# to run (C# generally has an intermediate layer that helps prevent you from screwing up important operating system stuff). But I guarantee you'll write code faster in C# than you ever will in C++. For most, this is a massive boon. I personally hate taking ages to do simple things...and if you pick C++ you will end up doing that. It has a robust standard library -- but it pales to insignificance when compared to what you get with .NET. Bemusingly enough, you can actualy use .NET through C++ -- but it is a nasty Microsoft hodge podge. I'll admit it is better than it used to be in its current iteration -- but ugly as sin compared to C# :) ~Shiny
  3. It's about being polite and not polluting the global namespace. Just because you know where this header is going to be used (for now), what if someone else had to use it? If you've imported a bunch of names, that limits what names you can use in units that include your header... ~Shiny
  4. I only beef I used to have with code::blocks was the way they didn't have set stable release versions (they had one old one, and nightly versions that were hypothetically stable). I think this has changed more recently...but er, to be honest I use VS at work (and eclipse) and I paid money so I could use VS at home too. I found a few things missing from the express editions that I really liked having (conditional breakpoints, the little threads window etc). That said, if you haven't used either enough to become really familiar with them...there's no harm using code::blocks :) ~Shiny
  5. Quote:Original post by BenThereDoneThat Also, you say Ubuntu won't cause any noticeable slowdown on these specs? Not even while gaming? Alarm bells ringing. Games will be slow depending on your hardware & libraries they call into. However, that said; Linux is not made to play Windows targeted games. Using Wine is a perfectly good way to play games on linux, but you -will- get a performance hit most of the time, and occasionally, a game just won't work under Wine. If you want the most out of your hardware in -windows- games, buy a windows license. On the other hand, if you want to make games -- nothing wrong with doing that in Linux. I vote for Python if you do ;) ~Shiny
  6. Quote:Original post by gregs Quote:Original post by Edward Ropple Quote:Then we come to math, I can't say much about this, I have never needed to use any advanced maths until I wanted to start doing graphics programming. Even then at this point, usually there are libraries that take care of 90% of this, and you really only need to understand whats basically going on. I would say math is useful though.Of course crap like calculus will be useless, but you're trivializing mathematics quite a bit. Calculus can be quite useful you know, especially when doing simulations. THIS! If you want to be a programmer of any kind -- I don't care if you go to University for CS or a tradeschool for 'game programming' -- do yourself a favour and do some math courses :) ~Shiny, BSC CS (hons) & BA -- why? Because it is really useful knowing about something other than computers :)
  7. int logins() { int attempt=3; if (! security) { cout<<"Username was not found on the servers! You have "<< attempt--<<" more attempts left!"; logins(); } if (! security) { cout<<"Password was not found on the servers!"; logins(); } return 0; } Please use the source /source tags when posting code snippets. That said -- I think you need to take a look at your code. First of all, you are using an integer as a conditional -- which makes me suspect you've used C before when you didn't have a boolean datatype. Use bool if you have it available to you! Next thing -- this function I've copy pasted is invoked many times in your code. Are you even sure what it is doing? The reason you're getting an infinite loop (and eventually a stack overflow I bet) is because inside the logins() function, you are again calling that logins function once over. This is a method called 'recursion' -- and when solving simple problems is worth avoiding in nearly all cases. It complicates code and makes things difficult for other programmers to read. Wikipedia explains it better than me: Recursion. I'm not going to explain how you ought to write your program, but by avoiding recursion you'll a least be a little closer to your objective ;) hth ~Shiny [edit] beaten darnit.
  8. I really wouldn't recommend rolling your own unless you are pretty confident with linear algebra. That said -- you can always get previous versions of the DirectX SDK (so you can have the managed stuff you pointed at, which was August 2005). Meanwhile, you could always try slimDX that was created by some gamedev regulars after MDX went belly-up :) hth ~Shiny
  9. On a side note about the hard-drive thing: hard drives come in many flavours. Mechanical ones -- being the majority of drives these days -- are rated up to a certain RPM. This (among other things) is an indicator of how fast you can find your data on disk. Low RPM drives should be avoided like the plague unless performance -really- doesn't matter. Most desktops will ship with a 7200 RPM drive in them these days; but 7200 RPM usually eats battery really fast. Hence laptops might come in 5400 or even 4500 RPM forms. Folks say notebooks and laptops are becoming the most purchased PC these days -- and numbers seem to support that supposition (too lazy to go find them right now). Luckily, hard drive speed won't affect game performance -too- much, except when loading resources from disk. It -will- affect your productivity, however...nothing worse than waiting forever for things to copy or load from disk :) ~Shiny p.s. If you want to be a programmer, consider getting as large a monitor as you can afford -- the screen real-estate can be really useful.
  10. I second the point about getting enough background in comp-science stuff if you intend on being a game programmer. Note that there are several disciplines within game programming that you might do, however. Engine, gameplay, physics, shaders, tools -- all require you to know different things -- but the base assumptions for your programming knowledge will generally be the same. On a side note, one cool thing that game trade schools like digipen and fullsail often have are decent contracts within the industry. They often have the ability to help out when applying for internships and that sort of thing -- not saying this is a great reason to go to one (I didn't, I did comp sci), but it is -a- reason :) ~Shiny
  11. I second the point about using any language to write the game server. And I poke my tongue out at the generalisation of them being too slow. I'm willing to bet that most server-class hardware computes simple stuff much faster than network communication happens ;) Meanwhile; do not expect decent answers to questions like 'how does WoW do X' -- because the folks at Blizzard did not just think up the answer in a jiffy...would have been carefully considered and plotted over. You've got some suggestions -- time to start using your head -- because if you -are- making an MMO, you're going to have solve a -lot- of problems that have solutions that are dependent on how you've designed things or planned for stuff to work. Anyway, that's my two cents, good luck ;) ~Shiny
  12. Hm, I too am wondering what you mean by not flexible enough...considering how easy it is to do certain things in graphics these days (compared to before XD), excuse me for being skeptical ;) Meanwhile, to semi-answer one of your points: a Scene graph is a way of organising (logically) the relationships between items in 3-space. One particular kind of implementation could be envisaged as following a tree data structure model. Given some node A, it might have several child nodes B, C & D. If you compute a transform for A (perhaps you want to move the things that A refers to 6 units along the X axis), it may be that you want to pass on this translation to A's children. If you're not understanding where I'm coming from, I think perhaps you'll want to read up a bit on basic data structures and programming before leaping into the pool without knowing how to swim (so to speak). Either way, hope that helps a bit :) ~Shiny
  13. Hodgman has beaten me to the punch I see; but it is worth re-iterating what he said. You want to organise things logically in your programs. If you don't learn how to do that straight off the bat, people are not going to want to work with you (or even read your code, to be honest). It's just a case of using the language constructs appropriately so that if you come back to your code in a year or so, it's not a tangled web that you need to fight to interpret. ~Shiny
  14. What you want to do is plan this sort of thing before you start -- but given that you're here post-facto you can probably solve a few issues by refactoring a bit and being smart about where you are putting things. Typically when I work on big things (I mean really big, 5k lines of code sounds nicely manageable to me) I tend to very clearly delineate functionality. All that means is that I try and organise things according to their function. If I do a decent enough job, I can roll related bits and pieces into a library (you'll want to make up projects for this stuff). Making things modular is always a great help -- because if you are strict about the interfaces you provide to other folks (client programmers...), you can screw around with the internals of the library as much as you want and hopefully everyone else's code will work afterwards (it won't, naturally, but that just gives the testers something to do). This method of organisation just means that at any one time you only care about one particular subsystem of the entire system in general. When using your libraries, you end up being exposed to looooots of interfaces, so it can get confusing -- so make sure to name things logically; c++ namespaces exist for a reason :) In closing; always try and write a proper spec. I don't mean buy a book about how to write specs (though that might actually be a good idea), just that you ought to think long and hard about how you want things to work. Then write/type things out so that you have to follow the plan to the letter. Never deviate from the spec unless whatever you put there was totally unrealistic :) hth! ~Shiny
  15. Unity

    Working without a debugger makes you more cautious, IMO (well, makes -me- more cautious). If you ever get stuck working on embedded systems, sometimes the stuff you work on can't be remotely debugged (you write the code, stick it on device, hope it works). This is not always the case, but I have had to do it a few times and it ...well, it is unpleasant, shall we say? It's never nice to see that a simple mistake (overwriting something that you meant to keep protected in memory) can cause your entire system to crash irrecoverably :( I vote for debugger in all circumstances where you can use one! When that fails, formal logical reasoning is your best bet (but only if you really care what happens when you start things up). ~Shiny [edit] Reasons why people still care about formal methods :P