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

xiuhcoatl

Members
  • Content count

    327
  • Joined

  • Last visited

Community Reputation

282 Neutral

About xiuhcoatl

  • Rank
    Member
  1. I've never been a professional game developer but I have worked on/off as a developer/dev manager/etc.. in a professional capacity for many years (more than I like to think of some times). I think the way you want to view this is not "what is necessary and what is crap". Its not really useful to be too polarized in your thinking. All of these 'techniques' are tools - and those are tools that help you achieve a goal or task sometimes good, sometimes not. There have been times where I really over-designed something that didn't need require it in the name of holy OO dogma; It was stupid to do so. The opposite has been true as well on occasion. One of the best qualities you can have is to be aware of as many possible solutions, and to know the strengths and weaknesses of each. Being able to manage up is also a great skill for an engineer - frequently what the boss (usually his boss...) wants is not really what they need. If you can quickly express ideas to code, which many times involves using these techniques, then you are better for it. Just always keep in mind they are tools. If you find yourself spending too much time on a shortcut - cut bait and go with something straightforward. Unless your code is tangled spaghetti, you can always refactor and clean it up as you mature the implementation. As a specific answer - yup all the time. I use Inheritance in everything I write, and as I write more I constantly look for ways to reduce and concentrate the implementation.. I hate duplicate code and attempt to reduce it as much as possible, much less for code reuse - normally for maintenance and "it would be nice if" requests. Polymorphism gets used less - but if it makes sense I use it. Templates I use as often as I can (STL), and often roll up code to a template as pieces start to come together. For instance, if I notice that I have 2-3 areas where a ring buffer is being used - I'll refactor the ringbuffer into a template and write unit test code for it. hth.
  2. I dont know if anyone is still using VS2003, but I ran into a rather odd error today while building some stuff at the office (Its updated..): struct PATTERN { PATTERN(); ~PATTERN(); unsigned int m_offset; void* m_data; }; Thats about as vanilla as it gets in my world and 2003 was essentially coming back with the 1003 - internal compiler error message... which redirects you to paid support (I know you can get a refund if it turns out to be their fault.. but come on...). After piddling around for a while it turns out the PATTERN is defined in wingdi.h as: typedef LOGBRUSH PATTERN; Clearly some namespacing or renaming would prevent this, but since it was esoteric (and the error message was so informative) I figured I would mention it here in case anyone else was running into something similar. cheers. #dth-0
  3. Deus Ex is a great example of alternative (although pt 2 was a horrible game, and those alternatives seemed contrived namely due to level design). The Hitman series is also a good example imho. You can continue to create more incentives for not pulling the trigger in a number of ways that reflect reality: 1. By being stealthy, you enjoy less law enforcement or guards around your objectives. 2. Its easier to get information and data from NPCs, as they are less concerned with getting whacked or the consequences of talking with you (or there are more around to interact with). 3. Interrogation yields more intel and fleshes the story line, opening up other objectives and tasks. 4. By being less recognizable, other avenues of solutions exist. etc... I am not a real fan blanket pacification, as it just seems lazy to me. However if you flip it around and use a 'carrot & stick' approach to the problem I think it creates a much more interesting game-space. Rather than worrying about if its 'right or wrong', I think using a subjective approach can yield more interesting ideas. IE Mob bosses will respect you more, but now you show up on police radar. hth...
  4. doh - Ok that would be the problem. That box is using ATI cards and clearly that would be the problem. If I get a chance I'll run it on the dual-SLI box later in the weekend.. thx~
  5. I have been watching your work here for a while with interest and pulled it down to take a look at it. However, in the initialization part of the process, it dumped. The trace it here: //////////////////////////////////////////////////////////// // Sound devices //////////////////////////////////////////////////////////// 1 = Primary Sound Driver 2 = Turtle Beach Catalina (WDM) //////////////////////////////////////////////////////////// // Setup //////////////////////////////////////////////////////////// display.width = 1360 display.height = 768 display.color_depth = 32 display.z_buffer_depth = 24 display.vsync = auto display.change = true window.width = 1024 window.height = 768 window.x = 0 window.y = 0 window.fullscreen = true window.borders = false window.on_top = false window.center = true sound.enable = true sound.dev = 0 sound.channels = 2 application.fps = 40.00 application.show_fps = false //////////////////////////////////////////////////////////// // Sound: 0 //////////////////////////////////////////////////////////// Channel[ 1] = SPEAKER_FRONT_LEFT Channel[ 2] = SPEAKER_FRONT_RIGHT ERROR: Code failed in file 'D:\Prive\XEos2\C++\lib\modules\gl\program\gl_program.cpp', line 100: Error This is an older video card, if that matters. Let me know if you need something else.
  6. Have you started up gdb to take a look at the spot where the problem his happening? With the amount of information available I can only speculate, but it would seem that either the difference in libraries, compilers, or compiler options (or clearly a combination of these) from windows to *nix is creating the problem (the stack overflow). Starting up gdb and walking through should at least show you where this is happening and give you some clues as to why. That may help someone here diagnose the problem or at least what to research.. hth.. #dth-0
  7. The enterprise management tool will let you do this..
  8. Quote:Original post by Tomokka I have been thinking that maybe the way i am trying to learn isnt the correct one. I have been doing the examples in that book but nothing else really. My orginal plan was to first read the book and do the examples and then try something new, but maybe that is not the best way to learn. Doing programming exercises and writing code IS an important part of the process (its debatable if its the wholly best way to learn, but it is a vital component at a minimum). My points were more along the lines of what do you do with that skill once you have learned it. In a sense, you need to sort out the difference in learning to PROGRAM vice write C++ code - there is a difference. Think of it like learning Spanish (or another foreign language for that matter). Practicing vocabulary all day will NOT teach you how to communicate in spanish - it will teach you spanish vocabulary. However taking that vocabulary for a quick trip to your favorite mexican restaurant, and practicing a conversation, will. The experience you have will require you to interpret someones response and start to communicate your ideas in a different language. That being said, you will not be able to practice conversation without vocabulary skills - so they are both parts of the learning process. Vocabulary is a building block, the real trick is the conversation - but both are necessary components.
  9. Well - the good news, if you can call it that, is that programming is very rewarding because of how difficult it is. One thing you may want to consider (I apologize if I am repeating, I only skimmed the previous posts) is your logic and problem solving process - the way you think. This is independent of programming, but imho a very important part of the process. Try to think of problems in terms of solutions, and better yet small finite tasks of solutions. Think about how to organzie and coordinate these solutions into larger systems. You can do this in every day situations. Go to the video store and watch someone re-shelving videos. Is there a more efficient way to do this? If you needed to programtically solve the problem how would you? How about the organization of the grocery store? Planning your driving routes for a list of errands you need to do. There are lots of examples and ideas. In turn, this process is not much different than programming - with the exception that in programming you need to express these ideas in a language. However, thats much easier to do once you can conceptualize what it is you want to build. As in all things though, this will take time and patience... so give yourself a break and take your time. hth
  10. While this sounds simple in theory, there can be a lot to this. I'll point you in some directions - as I am sure a lot of qualified responses will follow. You want to look into serialization (the process of extracting the data from a c++ object and putting it back in). This is the important first step as all object of your game that have a state you want to maintain will need to be "serialized". If you search on this topic here, there are several great topics of discussion. You will also want to start to identify what objects require saving, and a format for saving. I would opt for a choice of binary and XML. XML being a slow, but easy to edit format that will allow you to quickly work with your data and get things rolling. Binary will be quicker, but obviously harder to work with. Again, I expect you will get some more thorough responses but I wanted to give you some direction to start with.. hope that helps.. #dth-0
  11. Is it the same hardware (or an exact duplicate)? If there's some sort of timing issue or rounding issue it may cause this. My suggestion would be to try an isolate the problem a bit more. Try outputting position and orientation data for both simulations into a log and then compare the outputs. See if there is one particular type of input that creates the difference and then consider how those calculations are made. Without knowing more about how things are computed and their inputs it would be difficult to guess.. Hope that helps.
  12. Interesting... its like a mud that you can interactively build stuff in.
  13. Goal wise I think you may have to take a big sip of Reality Kool-Aid, but I understand the use case you are trying to fill. However, rather than pontificating about what you 'cannot do' what about something that is feasible to do: What about using this instead: http://www.xgamestation.com/ It's already built and designed, newly repriced to $200, has an SDK and some coders already established for it, and just needs a snazzy box to live in. Andre is really big on trying to help young business guys and if you are serious and can make some things happen will probably work with you. Good luck..
  14. Super from eRightSoft is ok...
  15. I agree with the above poster - its probably more work than its worth. Something you can do is thread the actual traversal of the "tree" using a workcrew. If you only detect a single proc on the box then the traversal only has a single thread to walk the graph. If they have 2 dual core procs, then there are 4 workcrew threads. Then, at each node where you reach a "fork" (no pun intended...) in the road, you see if you have a free workcrew thread. If you do - you send him down that path. This would allow your code to be the same with a little extra overhead, and still support threading. This will also avoid having to work out synchronization issues between the whole graph and the rest of the system which would be a real hassle.