• 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

509 Good

About Drigovas

  • Rank
    Advanced Member
  1. 2 years ago I made a real effort to eliminate as much paper from my life as possible. The main reason is, while it was easy to read if you had it in your hand, it was hard to find, and I had a tendency to lose things or misplace things. It also ended up taking up an enormous amount of space, and made my frequent moves much more painful. I scanned things that I had to keep, I stopped buying paper books, I stopped magazine subscriptions in favor of online sources, I moved all my banking and bills online. I have a few books that I could not get in digital form [few enough that I can carry all of them at the same time, myself]. I have a checkbook that I haven't opened in about 10 months. I have a tiny bit of cash with me that I carry for emergencies. I have a bit of junk-mail in my garbage. I have paper towels, paper plates, and toilet paper. Other than that, I am 100% paper-free.
  2. Just use the enumerator outside of the foreach construct. Iterate through it manually, and you get indexing.IEnumerable<T> ev = f(...); int index = 0; var enumerator = ev.GetEnumerator(); while(enumerator.MoveNext()) { doSomething(enumerator.Current,index); index++; }
  3. I can certainly see what you're saying. In programming in general, I've seen generally two camps: 1) Don't implement anything that you don't absolutely have to, and 2) Implement everything yourself, from scratch, unless you are literally tripping over an existing solution [just think of how many damn replacements have been written for things like std::vector in c++]. There doesn't seem to be a lot of middle ground. One of the advantages of standard libraries is that you have ready-made solutions to find, that are pretty much in your face. The bad part about large and robust standard libraries is that a lot of people kind of think that this is all there is to the world, and don't really look elsewhere. It sort of fosters this lack of collaboration, because people never really get pushed to the point where they need to choose between either not accomplishing anything at all, or venturing out onto the web to find ready-made third party solutions. Of course there are still problems that need to be solved. But sort isn't one of them. This is sort of the problem that I found with .NET. It has a lot of stuff, which is great. It allows a programmer to not have to go and LOOK for third party solutions for almost everything. If you do use a third-party thing, chances are it also uses stuff from the .NET library, so you don't need to worry about really learning how to communicate with this new module you downloaded [things as simple as a standard implementation/representation of a list or ip address or whatever, is so useful]. The .NET library is however annoyingly deficient in certain ways, but not really so glaringly deficient for you to think "Ok, I really HAVE to seek outside support". Even simple things like priority queues, have been implemented a thousand times, because they aren't in .NET, but are just simple enough to implement that for someone who doesn't really know about any .NET communities, it's easier to just type one out instead of getting involved. If you consider something like C++, it took the failure of the STL to make Boost really interesting, and get people involved in boost, and thus invovled in general. If the STL was better, a lot of people wouldn't have gone looking for alternative container types. Personally I love C#, as a language. I love it partially because of the tools I get to use with it, and I like that it is more structured than something like python, but better defined and less error prone compared something like C++. I honestly don't value open-sourceness in most of my tools. I just want to be able to get them to do what I want to do with them, so closed-sourceness in the .NET library isn't an issue for me. Seriously though, the .NET COMMUNITY is deficient.
  4. So before going into how to do it, perhaps you should consider a hypothetical, to make sure what you're going after is actually what you want. Consider the situation where there is a change in ground level of two pixels vertically. Something like this: x x xxxxxxxxxxxxxxxxxxxxxxxxYour character goes to run over it. How do they make it over? To put it in perspective, two pixels is likely too small a feature for many people to see against a busy background, and the character is likely 100+ pixels tall. And on that note, how do you represent a 'slope', or a 'triangle' in a per-pixel fashion that allows your collision detection scheme to let a player run up and down the slopes? The point is, when a player encounters a pixel-tall collision, should they climb over it, or should they stop just as if they had encountered a 100-pixel tall collision. Also, if your player moves at many pixels per frame [as is completely realistic for a sonic game], should the player be able to run straight through skinny obstructions [being completely on one side in one frame, and completely on the other side in the next frame]. These points are why games typically use geometric shapes instead of pixels. If the character is represented as an ellipsoid, the player can slide up slopes because simple dynamics calculations would allow that. In terms of how to do per-pixel checking more efficiently, perhaps organizing your pixels into a quad tree or some such would allow you to more rapidly cull away pixel regions that will result in no collision detected. That way, you perform fewer checks.
  5. Quote:Original post by chao226 you could also try bloodshed dev c++Really, please don't also try bloodshed dev c++. There is a huge list of reasons why, but really it boils down to two big ones: 1) it is not current, and 2) it is FAR inferior in terms of features compared to vs2010/codeblocks/eclipse, all of which are free.
  6. I wrote a very flexible and somewhat high performance ILP solver in C# over the course of about a week, back in C# 2.0-era, to learn the language. It's my favorite because I've used it in many, many other projects. It has turned into a real work horse for me, and over the years I've improved it greatly and made it more efficient. It is pretty much the go-to tool for about 70-80% of problems that I look at and say to myself "uhg, I really don't want to have to write a solution for this right now. If only there was an easy way that wasn't horribly inefficient". I've used it as the back end for everything from compiler optimization problems, to AI in my game projects, to data number crunching. All sorts of optimization problems, really.
  7. Honestly, my loyalty to my country is flimsy at best, and in most cases, likely nonexistent. I am currently in the USA, and if I thought Canada could offer me everything I have now, plus a ham sandwich, I'd happily turn my back on the US.
  8. Depends on the kind of zombies. If we're talking about 28 days later like zombies, which have effectively human life spans but are crazy, I'd opt for either a boat/bus, followed by a[n] ocean/desert. Drive boat/bus to middle of ocean/desert, hang out for a few weeks. Time and exhaustion will be my weapon. If we're talking those zombies who are effectively invincible [never starve out], save for getting shot in the head, a bus would likely still be my primary weapon. It's big and heavy enough to not really slow down from squishing a zombie. Other than that, pretty much whatever gun I can carry out of a gun shop/walmart and stuff into a bus. A bus is also something that you could likely weld a lot of scrap to, to firm it up a bit. If we're talking the old-style utterly invincible zombies..... not much good weapons will do you.
  9. 1: Operators as part of interfaces, or demands that operators be defined as part of a generic type constraint. Constructors as part of interfaces, or demands that a non-empty constructor be defined as part of a generic type constraint. 2: Either Allow for an interface implementation to be satisfied implicitly if it is marked as an 'implicit' interface type [if it has all the methods for a given interface, it can be treated as being of that type]. Or Allow for existing types to implement new interfaces in a fashion similar to how extension methods can be added to existing types. Honestly, there is a lot with regard to generics that can really use some tweaking.
  10. So in Fable 2, did the npc's hit on you, or wait for you to approach them? Did they initiate the conversation? I never played it.
  11. There are a fair number of games out there where it is possible for a player to have a relationship with a npc. It has been my observation that these games tend to depend on the player to initiate, and largely drive, the conversation relationships. But what about npc's that initiate conversation, or hit on players, or drive the conversation with the player assuming the roll of the person being picked up? On one hand, this seems like an interesting avenue that would add a bit more to a scene. On the other hand this seems like it may be a short cut to weirding players out, or making them uncomfortable, very similarly to how some people get uncomfortable if certain people hit on them in real life. What do you think? And if it were to be written into the game, what could be done to minimize the discomfort the player experiences if they are approached by an npc that they wouldn't like to approach them? Is it best to just leave the player to assume the initiating roll in these things?
  12. People shouldn't learn to program. ....someone had to do it.
  13. Both of those methods will block. Calling lock inside a try-block doesn't make it non-blocking. What you're looking for is TryEnter. The 'lock' keyword is effectively short-hand for something more verbose. See here for details on the lock statement. Lock resolves down to Monitor.Enter() [plus some more stuff]. If you want to attempt to lock something, but detect if it is already locked and then not perform that action instead, use TryEnter.
  14. Personally found this particular pattern to be so common that it was worth just creating something along the lines of a 'bounded value' type, then just making the thing public. So many of my functions were just "assert(x); y = x;", a lot like what you see there. Things that really were effectively public, but resulted in more typing for me [and I hate things that result in more typing for me]. Looked something like this [not complete code, but will express the idea]:template <class T, T lowerBound, T upperBound> class BoundedValue { T value; void SetValue(T v) { assert(v >= lowerBound && v <= upperBound); value = v; } public: BoundedValue& operator = (T v) { SetValue(v); return *this; } operator T() const { return value; } BoundedValue(T v) { SetValue(v); } };Helps out a lot actually in doing bound checking. Got one for lower/upper bounds too. Pretty handy thing to have in a tool box. Real simple too.
  15. I now know to never tell any of you any of my fears. Wow. Took only one post to put up the hugest, nastiest bugs you could muster after, in the original post : Quote:I have a phobia of large insects, I can't even look at pictures of them on the internet.Never show any vulnerability, even for a second.