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

MoundS

Members
  • Content count

    38
  • Joined

  • Last visited

Community Reputation

162 Neutral

About MoundS

  • Rank
    Member
  1.   I think Sol is talking about the complexity of the library code, not the application code. A very simple IMGUI library isn't much more than an immediate mode rendering library with some fancy mouse logic, so it's very simple to implement. However, an IMGUI library with a realistic set of features (including layout) will be much more complex to implement than the equivalent RMGUI library.   When it comes to application code complexity, IMGUI of course scales much better than RMGUI. This is the payoff for investing the extra effort in the library.
  2. Well, calculating the collision between B and C relies on information that you only have after you've processed the collision reponse from A and B, so I'm not sure how you can calculate them simultaneously. There is some room for improvement in the method I describe though. You don't have to recalculate ALL the potential collisions from scratch each iteration. You only have to recalculate collisions that involve the two balls that change in response to the collision. For example, if there's another ball D that doesn't collide with anything in the first iteration, then after you process the A-B collision, you have to recheck A-B, A-C, A-D, B-C, and B-D, but not C-D. It's extra work to keep track of all this, but in a more realistic simulation with lots of objects, it might be worth it.
  3. If I understand your post correctly, I think your problem is that you're advancing some of your objects to the end of the frame before you even check the rest of your objects for collisions. What I do is search through ALL the objects and find the pair that collides first. If that collision happens after the end of the frame, then you're done. You just advance all your objects to the end of the frame. If the collision happens during the frame, you advance ALL your objects to the time of the collision, apply the collision reponse to those two objects, and then repeat the whole process. Of course, when I did this, it was for bouncing balls. I'm not familiar with cloth simulation, but I assume you can use the same idea.
  4. I have no doubt that languages and IDEs will move in this direction. Even if you are very good at organizing code into files, you're limited by the linear nature of them. Code can be sliced along many independent axes. If I'm working with a geometry library, I might want to see all the functions that take a circle as an argument, or all intersection functions, or all functions that return line segments. It's impossible to structure your files according to all these criteria, but a database can easily support these queries. And decoupling code storage from concrete syntax opens the door for different views of the code. For example, views of code that use mathematical notations might be more understandable to scientists who aren't programmers (Fortress already supports this). Or maybe this could finally end all the debates on proper indentation style by allowing programmers to view all code in their preferred style (as long as you don't look at code on someone else's monitor). And imagine all the benefits of having version control built right into the language. Look at Starcraft 2. Blizzard finally added the ability to view old replays that were recorded on a different version of the executable, but they did so by keeping a full copy of every past version of the executable on the user's harddrive, along with supporting DLLs. Not only is this a massive waste of space, but it means that people viewing old replays don't get the benefit of recent bug fixes and improvements to areas that don't affect the game logic, like the UI or renderer. But honestly, it's hard to blame them, given the current state of affairs. Now imagine that Blizzard was using this language of the future. They could just keep some metadata about what versions of code have been released, match up the replay file version with the corresponding version of the code tree, and invoke that version of the gameplay logic and file parser to process that replay.
  5. Quote:Original post by Way Walker The infinite loop is a consequence of the contradiction and could be seen as the "third" answer. No, there's infinite recursion even without the contradiction. The reason for the infinite recursion is that, in both cases, the function refers to itself unconditionally, just as the sentences do. But you're right that this can be seen as a third answer. In PL theory, there's actually a type called "bottom" that denotes the type of expressions like this.
  6. Quote:Original post by way2lazy2care The original doesn't go on forever it just turns into a contradiction. Evaluating the original, "This sentence is false." you just evaluate it once assuming it is true, and once assuming it is false, and both result in a contradiction. the sentence "This sentence is true" which should evaluate to a non-contradiction using your code: bool statement(){return statement()== true;} would still go on forever, despite its answer existing. What exactly is that answer? Calling the function statement() is equivalent to trying to determine if the equivalent sentence is actually true or false, not just consistent or inconsistent. There's a difference. If you need to assume A is true in order to prove that A is true, then you haven't actually proven that A is true. If you wanted to check for consistency using C++, you would need to represent the statements as data structures and run a consistency checking function on them, but trying to evaluate them would still recurse infinitely.
  7. Quote:Original post by way2lazy2care this would go forever whether or not it was a contradiction. Isn't that true for the English version as well? If you tried to rigorously show that "This sentence is true" is actually true, wouldn't you end up infinitely recursing as you expand "this sentence" into the full sentence over and over? There may not be a contradiction, but there's also no base case.
  8. What makes "this sentence is false" interesting is that it references itself, so you need to capture that in C++... bool foo() { return !foo(); } Or you can be more verbose and try to better match the original structure... #include <boost/function.hpp> struct assertion { boost::function<bool()> premise; bool valid; bool operator()() const { return premise() == valid; } }; assertion this_sentence_is_false; this_sentence_is_false.premise = boost::ref(this_sentence_is_false); this_sentence_is_false.valid = false; It all boils down to the same thing, and either way, evaluating it results in an infinite loop, just as it would if you tried to decide if "this sentence is false" is true or false.
  9. Quote:Original post by swiftcoder It is easy to switch to anything freshman year. Aftyer that, the only subject which is easy to switch to (read: has significant course overlap) from Computer Science is Mathematics.Well, I didn't mean to imply that CS has great overlap with every other major in terms of required classes. I just meant that CS is generally useful in other fields, so if you do decide to switch, and you end up with, say, a minor in CS, it will still be very useful, more so than accounting, I suspect. Quote:Really? Most places computer science is about learning Maths. Logic and problem solving are across campus, in the Philosophy department.Logic isn't limited to philosophical logic... http://en.wikipedia.org/wiki/Mathematical_logic A lot of that stuff is at the foundation of computer science, and at least where I went, all of that was taught in the math and CS departments, not philosophy. Quote:a Computer Science degree is overkill for your average programming careerThat's like saying a college degree is overkill for the average person. It's true that most people get by without college degrees, but that doesn't mean that they're not useful or that they don't open up new opportunities. I don't want to come off too strong here. I'm not saying "everyone should get a CS degree because it's the best and you can get any job with it." I'm saying try it out, and if you like it, don't worry about people saying that game programming is overrated or that business programming is boring, cause you can apply it to anything, and you're sure to find something that interests you. And if you suddenly discover that you have a second passion later in life, there's a pretty good chance that it will synergize well with CS, and having a background in CS will probably make it easier to get into that field. My work involves using high energy protons to treat cancer. There are basically three backgrounds that can get you into this field: high energy physics, medicine, or CS. The first two are obviously relevant from my brief description of the field. CS is relevant because it's relevant to everything. :-)
  10. Quote:Original post by remigius Ideally, I'd try and wrap up accounting and see about diversifying to computer science later I don't agree with that at all. If you don't like a subject, having studied it for one month shouldn't make you feel obligated to stick with it for four full years. And it would be much, much easier to diversify from a computer science degree. Studying computer science is studying logic and computation, how to formulate problems and solutions. It's applicable to absolutely any field in the world. It's true that there are a lot of boring programming jobs out there, but if you look at any field of research or development (or even art) that you might possibly be interested in in the future, you'll find a way of applying CS there.
  11. As someone who's gone a little too far down the template metaprogramming path in the past, I feel I should remind you that one of the goals of a UI library is that applications written with it should compile in less than 5 minutes. :-)
  12. Right, and that's basically what my macros are, a way for the library to reflect on parts of the UI function (control statements in this case). I could add other macros if I wanted, to deal with static sections of code, but the user would have to identify them manually, whereas you could just check for static sections automatically. We both want the same thing - to specify a parameterized definition of the UI. I specify it as real code and have to use macros so that my library can analyze the code. You specify it as data, so it's really easy to analyze, but you're stuck with the fact that representing code as data in C++ isn't as easy as it should be. We're working in a language that's less than ideal for what we're trying to do, and we've arrived at different tradeoff points. In a language like LISP, we probably would've designed the exact same thing!
  13. Well, you're not really retaining what a traditional RM system would retain. An RM system retains the list of scene elements (widgets, shapes, etc) from frame to frame. In your system, that list is dynamically computed each frame using the model data and the bindings, just as an IM renderer would look at the model data and produce a fresh list of shapes each frame. In fact, if you designed a graphics library using your way, it wouldn't really retain anything for a dynamic scene. Maybe IM and RM aren't such great terms for a GUI API anyway, since everything gets kinda blurry when you introduce things like bindings/callbacks or my get_state. What's important is really whether dynamic parts of the UI are specified as functions of the underlying app state, and we clearly agree on this part. The reason people use the IM term for that is because it's in the spirit of IM graphics APIs, but like you said, declarative is probably a better term for it.
  14. Well, we should've done this much earlier. So yeah, I agree that an RMGUI with that level of data binding is much closer conceptually to IMGUI, though I think you need a more powerful mechanism that just "mode" to capture everything you can do with if statements in an IMGUI. For example, what if you have some text that's only displayed when (a && b || c) is true? Or what if you want to display the sum of two numbers in your model? Or what if you want to only bind a subset of the items in a list to a part of the UI? I realize you could do all that with creative use of callbacks and whatnot, but at least in C++, callbacks aren't quite as convenient, so I'd rather use what I'm describing. But as far as I can see, you're right that at that level it's just a syntactic difference rather than a conceptual one. I would actually hesitate to even call such a system "RMGUI", because the GUI library isn't really "retaining" much other than a functional definition of the GUI and how to bind it to the model data, which is basically what the IMGUI UI function represents. What I was trying to get at all thread were the advantages of this method over GUIs where you have to manually create/destroy/update widgets as your app state changes (because the library doesn't understand the relationship). That's what I've been calling RMGUI, and most of the GUI examples I find online seem to fit that mold. I wonder what percentage of GUI programmers actually work with something like what you're describing.
  15. No problem. I don't blame you for not wanting to write the RMGUI code for that example. :-p