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

Telgin

Members
  • Content count

    171
  • Joined

  • Last visited

Community Reputation

200 Neutral

About Telgin

  • Rank
    Member
  1. [quote name='ApochPiQ' timestamp='1318804324' post='4873241'] [quote name='markr' timestamp='1318803254' post='4873231'] Code which does useful stuff, mostly does not look beautiful. Aesthetics is not its primary concern. [/quote] This. Most production-level code is actually pretty hideous. Of course, it can be hideous because it's truly [i]bad[/i], or because it's full of tiny considerations for really obscure cases. Hmm, I smell a journal entry :-) [edit] [url="http://www.gamedev.net/blog/355/entry-2250790-there-are-many-kinds-of-ugly/"]As threatened![/url] [/quote] I'd like to think this means my code is actually not as bad as I think it is. But I know better, my code is hideous because it's usually tossed together without a large amount of thought. It does work most of the time, but I feel bad for whoever has to maintain this stuff if I leave my current position. I do feel a certain amount of pleasure in actually producing elegant code that is maintainable and scalable, but it just doesn't happen often. My code usually looks clean up until it's about 50 lines long. It's all downhill from there.
  2. I'm reminded of the Ecco the dolphin games. They had a pretty simplistic model of swimming, but it felt solid overall. There was a definite sluggishness to starting and stopping, but it was subtle and didn't overpower attempts to get out of the way of things. Most of the time. There was more focus on turning around underwater, which was either slow (to turn tightly) or dangerous (a wild wide high speed turn). Of course, that was all from the perspective of a dolphin, so if you're going for humans I would probably just introduce a small drift when starting and stopping. Turning around probably shouldn't be instantaneous either, but it should be fast enough that players won't feel frustrated. In the end, whatever you do, players are going to want to feel like they're in control. Ecco was a very difficult game, mostly because of the level design, but the control restrictions definitely made me froth at the mouth a few times when I failed to avoid something and died. Level design is going to interact a lot with the controls in this case, don't make the same mistakes Ecco did (such as requiring you to be very agile at high speeds while not knowing what's coming half the time).
  3. Everquest first and foremost. 7.5 year love hate relationship with that game. Otherwise I'd say Dwarf Fortress. I only wish I'd discovered it years ago. I recently had a dwarf go insane, bite the feet off of a wolf pup before biting it by the neck and shaking it until it bled to death. She was promptly killed by another dwarf who wandered in and kicked her skull in. Oh, and there's lots of magma for melting goblins. And it's free to boot. You can't put a price on this sort of entertainment.
  4. [quote name='Acharis' timestamp='1317320731' post='4867286'] OK, maybe let's ask about it from another side since many people mentioned it. Assuming there is no need for the second coin type at all (there are no these small wares), would you, as a player, still want it for the immersion purpose (the game is advertised the way it indicates increased level or realism/immersion)? [/quote] To me it wouldn't be a big deal, unless money comes up a lot. For example, if I'm frequently buying and selling things as part of the game, and throwing around a lot of gold as a lower class person, it would feel strange to me. I would probably dismiss it in the end, but I would certainly chalk it up as the game lacking accuracy / detail by devaluing gold so much. A nitpick, nothing more. If economics are rarely encountered, I probably wouldn't really care. If you're high class and buying expensive things, then this is of course completely reversed. If silver and copper coins are only there to... just be there... then they are a needless distraction. If you're only buying things that are on the scale of gold pieces, then sure, drop the smaller denominations. The more I think about it though, the more I realize it's not such a big deal to me if something costs 5.25 gold. If it's clear that it's an abstraction it's not a big deal really.
  5. I don't use any sort of prefix for member variables. I suspect this may be because I use PHP more often than anything as of late, and it requires that you use $this-> syntax to access class members. Since you have to do that, what's the point of adding m or m_ to a variable name? Of course C++ or the like is a different story, but learned habits are hard to break. I don't like to use prefixes anyway because they offend my stylistic sensibilities. I suppose it does add some information at a glance, but it's not a habit I've managed to convince myself was worth the trouble to get into.
  6. I don't even know what my card supports anymore, considering it's like 5 years old. I can't play any modern games on my computer at all. I wouldn't place a requirement for 8x multisampling anyway. Why would you mandate something like that? Are you going to hard code your game to use 8x mutlisampling and nothing else? This is a prime example of the sort of option that PC gamers expect to be able to adjust to meet their hardware's abilities. Needless to say, I'd be pretty ticked if I had a graphics card that was otherwise able to run your game but didn't meet that requirement and so I was unable to play the game.
  7. I too don't see a problem with introducing the whole copper -> silver -> gold paradigm. I wouldn't add in platinum pieces though (like Everquest does), that doesn't make any sense historically as far as I know. Furthermore, recognize that a gold coin was extremely valuable in the eyes of non nobles. From what I understand, many peasants may have never owned one. Adventurers might be more wealthy than that, but if you're really going for realism, don't start with gold coins as the "dollar" and silver / copper as change. Most commodities would be a few copper, things like furniture would probably be a piece of silver or so, and only when you bought things like a carriage or a full suit of armor would gold pieces really be reasonable. Anyway, that gives you some flexibility in fractional charges for large costs. For low costs, perhaps you could just have half pieces of copper or something, along the lines of the suggestions above. Lastly, just because you've got 2 or 3 types of coins to keep track of doesn't mean things have to be complicated. You could automatically consolidate coin types when making transactions or looting money, for example. Under the hood you could just keep track of how many pieces of copper (or half pieces) a player had, and do all transactions from that pool. Just display the calculated amounts of copper, silver and gold on their character sheets and for merchant prices. Doing something like the way Everquest used to would introduce more realism, but might not appeal to everyone. In old EQ, coins did not consolidate and they had weight associated with them. Carrying around your entire fortune would weigh you down and made travel risky if you got killed and couldn't get back to your body. Thus people would actually go to the bank to have their coins exchanged for more valuable types, or to store them for safe transfer. Selling at merchants would still automatically consolidate coins though.
  8. This is something that irks me more and more as I see it and think about it, so I'd say, no I don't like women fighting in bikinis. Of course, it does always come down to context. Always. If a woman is fighting in melee combat among others who are well protected by plate armor and is wearing nothing but straps of cloth, it's going to bug me. If she does this when armor actually makes a difference, I'm going to think she's stupid. If she does this where she's somehow as tough as those others, I'm going to think the game is stupid. This also applies if she wears plate, but only small pieces that leave vulnerable bits of her uncovered (such as the abdomen). On the other hand, it seems to be a requirement for women mages to wear as little as possible in most games so I've grown somewhat numb to it for those archetypes. It still seems very strange if you think about it, but at least it's not jarring like being able to take a great axe to the chest without armor on. It still makes me wonder just what type of person she is if she thinks she needs to walk around in all but nothing. I like realistic and practical characters above all else. Unless the setting is intended to be over the top, at which point the rules change a lot.
  9. To me it would depend a lot on [i]what[/i] exactly we're talking about. You say that you're playing an animal, and so I presume that enemies are animals too, so what are they dropping? Teeth? Bones? Skins? Magical items they managed to make somehow? I also skew toward the realistic camp here in that while it doesn't bug me overly that I can carry 5 guns, all the ammo I want and still be able to pick up a candy bar, I like it when the designers do make this more realistic and force me to choose what to carry. For an animal, this would probably be pretty jarring. If magic is involved, then yes, you can pretty much explain away anything. Maybe they have a magical pocket dimension they dump stuff in? As for what they might equip... that's tricky and falls under the same question of what items enemies might drop. If this is a world of animals with shamanistic type beliefs and magic, then it's probably not overly outrageous to have things like skins of enemies worn as clothing of some sort. Maybe even head dresses or masks, but that's pushing the ability of most animals' dexterity to create. Then again, there is magic involved. Tattoos is definitely an option, but it's hard to rationalize collecting something like that from an enemy. You could also go with special effects. Say you picked up an enchanted rock that adds to your strength or something. Maybe this leaves magical wisps of energy as you swipe at foes, or enshrouds you in a faint aura of glowing magic. Or maybe it provides a tattoo or other marking to signify its presence.
  10. The answers so far are pretty relevant, but I'd like to add in that you may have some difficulty getting the RAM maxed out. In particular, don't try to allocate a buffer the size of your entire RAM size, because the OS probably won't give it to you. malloc will fail or operator new will throw an exception, because the OS probably won't be willing or able to allocate a contiguous memory chunk that large. Maybe on an older computer with <1GB of RAM it might, then page most of it out, but I think even on 64-bit computers allocations of several GB may not work. So instead, in your loop where you're wasting CPU time, just malloc or new a few MB at a time and throw away the pointer. It shouldn't take too long for that to eat up your RAM. And page file.
  11. I too would love for this to be confirmed, because that would open up the future for quite a lot more science and understanding of our universe. Not that I suspect we're running out of ideas on how to improve our understanding, but jarring results like this are always fun. I just don't see it happening, really. It's such an unlikely thing to be true, given what we know. And since it's only happened in one instance that we've set up, I strongly suspect that it's really just a fluke in the experiment. Not being a quantum physicist, I can't begin to conjecture what they messed up, but that's definitely where I'd start with the finger pointing. Of course, it would be amazing if we did end up discovering a way to communicate FTL or develop FTL drives based on this somehow, but that's a pretty lofty hope indeed.
  12. [quote name='frob' timestamp='1316999796' post='4865918'] Sure, we could pick topics that we find interesting. But they are probably not topics that YOU find interesting. Also, they are probably not topics that YOUR THESIS ADVISER would find interesting. If you hate the topic before starting, you won't get far. If you can't find an adviser who wants to help on the topic you also won't get far. I suggest you talk with the various teachers you are considering for your advisers. Pick people who you can comfortably work with because you will be working very closely with them for several months to years. Ask them what topics they would want to work on with you. They probably have other students working on related topics, and you will be working with those students as well. Pick those topics and research areas that interest you from among those topics. Then figure out your topic based on that. [/quote] This has exactly been my experience in graduate school so far. Fortunately I have a communicative and helpful adviser, but in general it's going to be your adviser's ideas that will get you started. In my case at least, I started graduate school after having taken some directed study courses under my adviser (who had been my undergraduate adviser too). It turns out I liked the projects he put me on, and we worked together well so we continued on with my in the Ph.D program and him as my graduate adviser. He suggests topics, and I work on solving them. It's our goal that eventually something dissertation worthy will stem from those research projects. To directly answer the question though, well, we can't. There are quite an immense number of open research areas that you could pursue. It's also pretty critical that you do like what you're doing, as frob said. You're going to end up hating your research at one point or another as you work on it (trust me, staring at the same code for hours straight for the 3rd day on end trying to find a bug will make you rage). It's best if you don't hate it to begin with, else you'll probably really want to quit when you do hit such a stumbling block.
  13. [quote name='phantom' timestamp='1316726739' post='4864865'](And I don't know where Telgin got the idea that AMD don't support their graphics cards; I've had functional OpenCL support on mine for some time now. They don't support ALL of them, I think they focus on CL1.1 spec cards but you can certainly run OCL code on CPU and GPU with their drivers installed).[/quote] I could have sworn I read this on AMD's forums somewhere. I think it was even one of their developers that wrote the comment. Granted, that post may have been years old and quite irrelevant by now, I didn't check. The hardware we have in our computing lab is all GeForce cards so I don't have any exposure to AMD's GPUs with OpenCL. [color=#1C2837][size=2][quote]Branching code on a GPU isn't a waste, however this depends on the branching pattern for current hardware and work loads, however branching can and will improve performance if used correctly.[/quote][/size][/color] [color=#1C2837][size=2] [/size][/color] [color=#1C2837][size=2]I can also vouch for this. The compiler / hardware are generally quite good at reducing the impact of branches. Unless you're using some very deeply nested branches and / or branching in a way that most threads take different paths, it doesn't matter so much. Memory throughput is a much bigger bottleneck in my experience.[/size][/color]
  14. [quote name='ConorJH' timestamp='1316553181' post='4863966'] Im intermittently taking reference from Andre LaMothes Game Scripting Mastery, and Im at the stage of creating bytecode from an AST, specifically the activation records Iv created for each function. From what I can tell in the book, the whole stackframe is pushed onto the stack at runtime, and local variables of the function are accessed from the stack with a relative index. Now, although Iv only half used code (mainly because I dont have the CD ), it seems that Ill be pushing either redundant or excessive declarations onto the stack. Consider [code] int var1 = 666; void foo() { if(var1) { return; } int var2=667; return; } [/code] surely im pushing var2 needlessly? Must I just push everything in order not to break the relative indexing system, or is there another way? [/quote] I haven't read the book you mention, so I'm not really familiar with the methods presented therein, but assuming I understand your question correctly, then no, there is no need to push var2. Since var1 should evaluate to a truthy value, the function will always return before it could ever need var2. Further more, you're creating the variable var2 as local to foo and not using it, so it is never needed elsewhere, and so is completely unnecessary anyway. Some code analysis and optimization passes could determine this and you could remove var2 from the AST before doing any code generation. This case is pretty simple, but compiler optimizations can be very complicated and involved.
  15. [quote name='Servant of the Lord' timestamp='1316670588' post='4864550'] [quote name='J-dog' timestamp='1316668625' post='4864544']I am actually going to try and brave playing more than 30 minutes into Invisible War because I really want to see the plot... have been inspired to do so now [/quote] Invisible War is [i]fun[/i], give it the time it deserves. [img]http://public.gamedev.net/public/style_emoticons/default/biggrin.gif[/img] Haven't played Human Revolution yet, but added it to my wish-list after skimming this thread. [/quote] In a way I agree that Invisible War gets more hate than it deserves. It wasn't really a bad game, it was just too different from the first Deus Ex. I'll admit that I don't recall a whole lot about the plot, but I did find the ending satisfying. Well, the ending I chose anyway. As for Human Revolution, I finally got a chance to play a bit of the beginning of the game at my brother's house. To put it mildly, it felt very much like Deus Ex. More so than I would have expected honestly. The music matched it nicely, the character interactions were meaningful, nonlethal combat was a viable tactic and the objectives were well laid out and included XP granting optional objectives. I'm definitely looking forward to seeing how the story plays out and how well it meshes up with the first game. Of course, I did die pretty quickly on my first attempt. It took a while to get used to the cover system and aiming, which I kept trying to do like Gears of War. All in all, I like the fact that a few bullets kills you though. Playing through the first Deus Ex on the hardest difficulty was about the only way to make it feel believable.