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

F1N1TY

Members
  • Content count

    223
  • Joined

  • Last visited

Community Reputation

478 Neutral

About F1N1TY

  • Rank
    Member
  1. Just wait until I start a Journal <br>
  2. Quote:Original post by DrHalan I would reccomend trying Ubuntu as live CD it is the easiest way. I agree, if you're only trying it out, this would be a truly easy option.
  3. Here's a few tips of general programming practice (in order of importance, in my opinion): #1) Be consistent. Choose a good naming scheme, and stick to it. Having some methods called get_foo(), and others Foo(), and others getFoo() will only cause confusion. #2) Format your code to be clean, and easy to read. This should go without saying, it's hard to get help if the thought of looking at your code makes people want to puke. #3) Comment things that aren't completely obvious. A tiny paragraph at the top of a method, is more helpful than commenting what each line in that method does. Some lines might be hard to decipher (esp. when dealing with C++) so it's fine to explain those in a comment too. Don't do this: eat_a_bear(); // Eat a bear, because you'll only clutter your code, but also don't do this farsdnlgkg();, without a comment, I'll never have a clue what that function does ;-). #4) Know your compiler and linker well. Understand how object files work, what translation units are, etc. If you don't know how the compiler/linker work together, you'll never have a true understanding about "why does it say this is undefined, when it is", etc. #5) Use common idioms and practices. Pick up all of Scott Meyers C++ books, and read through them. There's no point in reinventing the wheel, and (sadly enough) a lot of people should read it for it's explanation of const-correctness alone. #6) Learn the differences of pointers, and references. Understand what each is, and take the time to learn how everything is held in memory. #7) Learn you target platform. There's two different points of view out there, one is the fact that "because C++ isn't O/S specific, you should consider targeting every platform", the other, more reasonable POV is this: If you're going to develop on windows, LEARN exactly how Windows works (same goes for linux/mac, etc). There's too many inconsistencies to be wasting your time trying to get a simple program running on multiple O/S. If you decide at later point to move it to another O/S. Learn how that new O/S works, and porting should be easy. I'd recommend picking up Windows Internals which will REALLY help you out in understanding a lot of what goes under the hood in windows. There's also various books on the Linux kernel, and I'm sure there's plenty for Mac OS as well. #8) Master your debugger. Period. #9) Use your brain. This is probably one of the toughest ones to get into people's heads. If you have a problem with some code, the first thing you do shouldn't be posting it on a forum, and getting the answer. You'll frequently forget things that way, and probably won't truly understand what's going on (as in how that fixed it). Take the time to step through your code, figure out exactly what the problem is, and try your hardest to determine what's going on. If you use your debugger, the majority of problems will be easy to figure out. If you still can't seem to get it, read the documentation. Read up on the official documentation regarding the API or SDK's you're using. If you've done your research, and debugging comes up with nothing, start asking around. Someone might not have your answer though (since the first two methods have ruled out most problems, and only really specific/complicated problems should be left to ask about ;-)) I'm sure I have many more, but I'm a bit tired, so I'm going to stop there. Hopefully these help :-D
  4. If for some reason you don't want to use the Performance Counters, you can look at this. http://msdn.microsoft.com/en-us/library/ms713418(VS.85).aspx Notably this section: "Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution," If you read into those, you can see that using the timeBeginPeriod, and timeEndPeriod, you can set the precision to a 1ms, but it might degrade the performance of the machine (since it's a system wide setting (note, that this is set to the lowest resolution any programmers, as for, meaning if you set yours to 1, everything will be at 1, and can't make it go higher, until timeEndPeriod is called, at least), processes and such might be switching more often, causing a degrade). But, I'd just use the Performance Counters ;-) EDIT: I'm not going to edit it, but see if you can decipher through that horrible grammar in that second paragraph. XD
  5. Quote:Original post by Westie007 yeah you can do it "in code" by using: #pragma comment(lib, "requiredLibrary.lib") As for the x86 and x64 versions of the library, I'm not too sure actually. I assume the linker knows which platform yu are compiling for from the project settings and selects the correct one. That is an assumption though, I haven't done any non-console coding in a while. EDIT: Ha! Clearly beaten to it there. :P In visual studio, this is determined by the Target Machine options under Project Settings->Linker->Advanced. Also note that '#pragma comment(lib, "requiredLibrary.lib")' is IDE specific, and rarely should ever be used (esp. since the time it takes to get to the additional dependencies isn't much more than the time it takes to type that line). Just my 2 cents. :-P
  6. Hello everyone, this is definitely my first post in the game design section on the forums. I don't plan on being a designer (as I'm very into programming), but I would like to write up a proper design document for the game I'm working on, that way other people on the team have an idea as to what I have in mind for the game. I'm wondering if there are any good resources concerning how to structure the design document, how detailed to be, etc. I pulled up the Grim Fandango Puzzle design document. As interesting as it was, I'm looking for more of a "complete" version. Basically, how to list off game feature, technologies used, etc. If anyone here has written a design document, and is willing to send it to me as an example, I'd very much appreciate it. If not, any advice would help, as to how to manage/properly start this document. Thanks! :-D
  7. No, both methods of code are easy to disassemble, esp. with programs that monitor memory changes in order to find addresses of values, then alter those values themselves. As programs get larger, however, there might be thousands of cases where a value == 5 (within a loop, elements in a string, etc) which would make that exact number harder to pin-point. Honestly, you shouldn't bother trying to make this program hacker-proof, because you'll just give yourself a headache. Single player games, shouldn't really be of concern to you (since who really cares, if some bored hacker gives himself unlimited guys in single player). Multiplayer differences can be caught (by comparing the values against a known good value, etc) and taken care of (usually by exiting with an error).
  8. Quote:Original post by DevFred C++ isn't obsolete, where did you get that idea? It just isn't suited as a first language for beginners. Once you know how to program, learning another language is easy. The hard part for a beginner is to learn two things at once: programming and a language. Programming isn't about a certain language, platform or API. It's a state of mind ;-) I really like this quote. Getting to the point of being an effective programmer takes practice. Jumping directly into games (like I once did), will only slow you down, and you'll lose sight/interest in game development altogether. I really wish they called us "Programmers of Games", rather than "Game Programmers", so that people can see that you need to be a programmer first, one that just so happens to specialize in games. Check out these videos, they'll help you get into the mindset that you need to be in, in order to become a smart thinking programmer. These videos are merely important concepts (you probably won't be writing games in LISP...), but they will help you wrap your head around programming in general. Once you've got that down, any "language" you decide on, will take a LOT less time to not only learn, but also be effective in. Anyway, here are the videos: Videos Here EDIT: Fixed up some terrible grammar mistakes.
  9. Also, make sure OpenMP support is set to No in both Debug AND Release mode (again it's under project properties -> C/C++ -> Language ->OpenMP Support
  10. This might help: http://msdn.microsoft.com/en-us/library/0h7x01y0(VS.80).aspx If not, LMK :-D
  11. Yeah, exactly what Matias said. When you create a new array with a value of 10,000, those 10,000 blocks of memory are allocated up front. When dealing with std::vectors, if you add one at time, you're going to be constantly reallocating memory until you hit your 10,000 (not necessarily every added term, but definitely more than once). If you're having performance issues with STL related usage, you're more than likely using it wrong.
  12. Is there any reason for that div to have absolute positioning? (I'm by far no web expert but) I don't see any reason for that to have absolute positioning. Anyway, first google result right here: http://www.jakpsatweb.cz/css/css-vertical-center-solution.html Let me know if that helps ;-)
  13. http://msdn.microsoft.com/en-us/library/ms645616(VS.85).aspx Cheers!
  14. A lot of people on here will recommend Thinking in C++. It takes a very object oriented approach, which is vital to becoming a good C++ programmer. The best part, is it's free (legally). Here's the link, and have fun :-D Link
  15. That first one isn't an error, it's a warning. Just do like it says, and use that linker flag if you don't wanna see it anymore ;-)