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

me22

Members
  • Content count

    314
  • Joined

  • Last visited

Community Reputation

212 Neutral

About me22

  • Rank
    Member
  1. Yes, I definitely meant "P_t^0".  Apparently I only fixed one when I noticed it :|   Good point on the possibly-infinite (in floating-point) t_max.  I suppose another possible parameter would be D_b, the range of the bullets, which would bound the B part of t_max by D_b/S_b.  In 2D I suppose that D_b is the diagonal of the screen, but if you have gravity, then (without air friction) D_b = (S_b)^2 / g.  Or of course it can be an arbitrary choice to get the weapon feelings right (no pistol sniping).   Have you compared convergence of the binary-search method with other options?  Once you're allowed iterative methods, there are some unsophisticated options.  For example, figure out how long it would take for a bullet to get where he is.  Since you're pretending he's not moving, this is trivial.  Then figure out where he'd be then, and repeat until you're close enough either in time or in space.   I'd be curious how the costs in iterations and complexity compared.  One advantage of the above approach is that it works best when the target is stationary (only one iteration), whereas a divide-and-conquer approach takes the most iterations at the edges of the range.
  2. There's a simple way to get t_min and t_max usefully bounded: think in 1D.   t_R is easy to bound, since it's between 0 and the time it takes to turn 180 degrees.   t_B is smallest if they're moving straight at you, and largest if they're moving away   So that means the following sound like good starting values: t_min = |P_s - P_t^1| / (S_b + |v_T|) t_max = pi/w_r + |P_s - P_t^0| / |(S_b - |v_T|)|
  3. As mentioned in another thread, it was missing two options: - Variadic templates, provided in C++1x to allow something like type-safe varargs. - Heterogeneous lists, which Erlang uses in io:format.
  4. Quote:Original post by nobodynews You didn't mention what language you're using, but I'd also recomment memory pools. That said, if you are using c++ you could maybe even get by with just using std::queue or maybe a std::priority_queue (both of which are just adapted from std::vector, I believe) depending on what criteria you have for a command to be removed from the container. std::queue defaults to a std::deque, since it needs pop_front. std::priority_queue is a wrapper around the various _heap functions in <algorithm>, so it doesn't need _front operations, so it does default to std::vector.
  5. A nice trick to initialize a "2D" vector: vector<vector<int> > v(height, vector<int>(width, default_value));
  6. Quote:Original post by DevFred In C++0x, move constructors will remove any severe performance penalties of copying the objects into the vector (provided MyObj has a move constructor). No need for "provided" -- move construction and assignment are the C++1x requirements for valid element types in containers. (And since move defaults to copy, those types are a superset of those allowed in C++98, so it's a Liskov- and backwards-compatible upgrade.)
  7. - Heterogeneous lists, like in Erlang - Variadic templates, in C++1x
  8. You should never make a class that forces itself to be a singleton. The usage pattern in the application may, if it so desires, provide the "single point of access to an instance" the pattern intends. Life is full of examples of places where "of course there's only one" becomes untrue not long after, and that change should only need the users to change, not the class itself.
  9. Quote:Original post by srikanthpv 1. Write a function that given a string of digits and a target value, prints where to put +'s and *'s between the digits so they combine exactly to the target value. Note there may be more than one answer, it doesn't matter which one you print. Examples: "1231231234",11353 -> "12*3+1+23*123*4" "3456237490",1185 -> "3*4*56+2+3*7+490" "3456237490",9191 -> "no solution" Not unlike problem 5 in the North-East North America Regional contest this year for the ACM's ICPC: http://www.cs.rit.edu/~icpc/questions/2008/NENA_final_2008.pdf It's one of the easier ones in that file, doable with brute-force and some clever recursion. For this version, since you know the order, it'd be interesting to try some kind of backtracking recursive subdivision. Or even DP up the sets of all possible answers over given ranges, cutting off answers above the target number to keep things from getting completely out of hand.
  10. Quote:Original post by Telastyn Quote:Original post by brainscrape I don't think this is the case, but if you mean that a Square multiply implements interfaces, such as Growable, then that violates the OCP and allows 'grow' access to the class' state, and doesn't narrow the interface any--so no forward progress is made there. I don't see how a generic grow interface (in the C# sense) implemented by Square and Circle and ... is any different from a free function that operates on a Square/Circle/etc. Indeed, the original article you mentioned deals specifically with making methods that can operate only with a Class' public interface as free functions rather than member functions. The difference is that to do polymorphism in C#, you either need to make it a virtual function -- and thus a member -- or use the visitor pattern -- with all the annoyances that come with that. The big problem is the fundamental limitation of th eOOP paradigm: "Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names" (http://www.paulgraham.com/reesoo.html point 9). What you really need are proper Multi-Methods, like Dylan has, and those can even be efficiently provided in C++: http://lambda-the-ultimate.org/node/2590 Oh, and brainscrape, in C#, how about implementing it like this: private class SomeObjectImpl { ... } public class SomeObject extends SomeObjectImpl { ... } where SomeObject can only use the public interface of SomeObjectImpl to implement its functions, and separate the implementation-knowing from the convenience stuff that way? I don't like it, but it might be the most acceptable way in an "Execution in the Kingdom of Nouns" language. (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html)
  11. Quote:Original post by Sneftel The proper place for someone to learn the domain of a function is the function's documentation. Types are a weak substitute.Fundamental types are a weak substitute. Types are a better solution than documentation, since they're runtime-verifiable documentation, and in C++, need not impose a runtime cost in release. In fact, given pervasive use, impose only slight cost at runtime, too, since assignment between instances of the type need not re-verify invariants. They could even lead to less cost at runtime, by moving the precondition check into the construction of instances of the type, which is only done once, rather than every time a function takes the value as an argument. Imagine something to be the equivalent of GLclampf. sqrt? Stays in range, no checks on either end. Cubic spline sampling? It's in range, no checks. Etc.
  12. Quote:Original post by Sneftel Quote:Original post by me22 It's quite possible that (new int[5])[-1] will pass at runtime without visible complaint. (new int[5])[unsigned(-1)] is almost sure to fail loud and hard.Nope! [grin] Signed and unsigned addition are identical, and you're passing in identical bit patterns. Not on my 64-bit box. size_t(-1) != size_t(unsigned(-1)) when sizeof(size_t) > sizeof(unsigned). (Yes, I know I've just opened myself up for criticism about containers with 2**32 or more elements. I don't have any. Files, sure, but that's why std::fstream::pos_type exists and is bigger than size_t on many platforms.) Quote:Original post by Sneftel Quote:I use it like a kind of poor man's dimensional analysis.Why act like a poor man? You've got <cassert>! You're rich! Compiler warnings test every line. I'm not going to cassert every line, and if I did, I'd probably forget at least once. When was the last time you wrote a program that checked every single printf, or checked for fail on std::cout?
  13. Similar to Extrarius, you can get an iterator range that iterates over the keys using a boost::transform_iterator (http://www.boost.org/doc/libs/1_37_0/libs/iterator/doc/transform_iterator.html) and a functor like the one mentioned. (Or, in a year or two, a nice C++ lambda: [](std::map<K,V>::const_reference p) { p.first })
  14. Quote:Original post by Sneftel It always amazes me that otherwise competent programmers have such a stiffy for unsigned. Is that extra bit reeeeally worth losing so much assertability and running into so many more edge cases? Given a compiler that will warn whenever I mix them (even in harmless cases), I like using unsigned. It's quite possible that (new int[5])[-1] will pass at runtime without visible complaint. (new int[5])[unsigned(-1)] is almost sure to fail loud and hard. I use it like a kind of poor man's dimensional analysis. If I use unsigned for my sizes and indicies (like the standard library does), then any attempt to use them as a proper variable -- where I just use int, because of the conversion and math scariness in unsigned -- will get the compiler mad at me.
  15. Quote:Original post by DevFred Quote:Original post by MadKeithV The first big question is how do you define OOP? - data abstraction - inheritance - polymorphism I can do all that in C89 without that much trouble. Ever used sockets and stuff? Amazing how that write function is polymorphic on file handles, socket handles, ... Inheritance? If I make the first element in my struct of the "base" type, then I can just cast the pointer and it works. Works great with a linked-list node type -- add it as the first element of various types, and all those types can use the add_to_linked_list function and friends. Sure, there's no MI, but the OOP fanatics never like that anyways (until they start inventing mixins and interfaces and other things that are all just MI). Date abstraction? What's in a FILE*? I have no idea. I spell "new file" as fopen, but it's basically the same. Relevant (and short): http://www.paulgraham.com/reesoo.html Quote:Original post by DevFred Polymorphism is quite a pain in C++ because class types have value semantics and you have to emulate the required reference semantics yourself which introduces ownership problems. Not that those problems couldn't be solved in C++ (boost::shared_ptr), but it's not "pretty". Normal objects are quite a pain in Java because class types have value semantics and you have to emulate the required value semantics yourself which introduces GC overhead. Except in Java the language isn't expressive enough to let you solve that. Quote:Original post by DevFred Quote:Original post by MadKeithV - C++ encapsulation is easily broken. Which is not a bad thing. Access modifiers are supposed to help the programmer, not prevent fraud by hackers. You can also access private variables in Java by some reflection magic, but who cares? If you do that, you haven't understood what abstraction is all about - that you really do not WANT to worry about implementation details. Ignorance is bliss ;-) In C# you can instantiate classes which only have private constructors through reflection too. It's one line of Spring.NET code to get around any access restriction. Compare that to pImpl (not that I'd actually suggest pImpl in most real cases, but). Or hell, since it's all obvious bytecode, you can just open dotNet Reflector, copy the code, and change the visibility. You can even just write a simple program to automatically change all the private and protected stuff to public, inside the shipping DLL.