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

King Mir

  • Content count

  • Joined

  • Last visited

Community Reputation

2490 Excellent

About King Mir

  • Rank
    Advanced Member
  1. This must be a relatively new thing. I haven't tried this in years, but there was a time where stack space had to be preallocated and going beyond the stack caused a crash. My information may be out of date. A dynamic stack really doesn't make much sense though as that is basically what the heap is or was. Maybe the line is being blurred?     Global variables are not on the stack. This means that they can indeed be arbitrarily large without compromising stack space. It's allocated in the ,data segment, not the stack.   However, the line is indeed blurred with respect to dynamic stacks. Compilers support segmented stacks, which are just that. This is often turned off by default, because it does have add performance cost to pushing and popping things from the stack.
  2. I don't think it makes much of a difference from a performance perspective if your memory pool is global or on the heap. From an operating system perspective, both are just memory requested by the application, the only difference being when. Therefore I would use the heap because it allows you to have a more modular and reusable design. You also get the capability to ask for memory in blocks, so that your memory pool is aligned with the os page size on both ends, but this shouldn't matter very much, especially if your application isn't expected to page fault.
  3. I use pre by default for the reasons Hodgman described.   With regards to data dependency, it only applies if the result of the increment is used. So using increment at the end of a for loop does not use the result in an expression so there is no data dependency difference. However, if you are using the result of the operator, the the point is marginally valid. However I still don't find it too compelling for the following reasons: 1)the choice between pre and post increment can effect the readability of the algorithm, so this micro-optimization is less important than those considerations. 2) Rewriting code to avoid the use of preincrement may not actually reduce data dependency because the data dependency can be unavoidable. For example, moving a pre-increment to it's own line and making it a post increment does not reduce data dependency.   I'd say that avoiding data dependency is a good idea in designing algorithms in general but using post increment more misses the mark.
  4. I think of more importance than the implementation of a function is having a the interface of this function be clear. So the problem is less too many variables and more too many function arguments. An object the more elegant solution to that.   Now I do agree that you describe an elegant and extensible way to implement this attack function. Having the skill weights separated from the computation like that is a flexible design. But If I used it I would have a segment that converted the player object to a list at the start of the function.   With regards to indexing and accessing by names, what you usually want to do is not index, but iterate. A dictionary in python does allow you to do this by allowing you to iterate over all the keys to a dictionary. So an alternate design here is to have a dictionary/map of skills to player skill value(or an object as described above), and a dictionary of skills to weight in the combat calculation; and iterate over both. Something like this: skill_weights= {'combat': 0.20, 'weapon': 0.20, 'arm': 0.55} def attack(player, style):     total = 0.0     for skill in skill_weights.items():         total += player[skill] * weights[skill]     return int(total) (Warning: code for demonstration purposes only; I have not verified that it works or even parses)
  5. That sounds like a workaround too.   I actually have the opposite annoyance in my game in firefox, but I'm not using Constuct2: pressing ctrl+F fails to pop up the find menu. So it's definitely possible to prevent key-presses to be grabbed by the application and prevent firefox from picking them up for search and keyboard shortcuts. But I don't know how it's done or if it's possible with Construct2.
  6. I would just have an object like "PlayerSkills" or just "Player" that contains the list of skills for a particular character and is passed to the attack function. The contents of attack would be basically the same, but it'd clean up how you call it.   Basically, the strength of an attack is based on the style, and who's doing it, and this makes that much clearer. I'd recommend this over Albeth's solution, because of that clarity, but you can still his technique to simplify the implementation of your attack function, if useful.
  7. If you want to use the same language for the backend and front end, I'd suggest Javascript over C++. The reason is two fold:   1)Using emscripten you still end up calling javascript libraries, for example for the filesystem, so it falls short of requiring no javascript to use. 2)Javascript has a single threaded architectural model, and even if you're compiling c++ to javascript, your c++ code cannot ignore this. Whereas a C++ game may have background tasks, and worker threads*, everything in javascript is done in what in C++ would be called your rendering loop. This requires an asynchronous programing style, which should be easier to do in javascript than c++. Actually this is a way around this, but it requires running an interpreter in javascript; this doesn't give you multithreading, but it does allow you to have long sections of synchronous code that don't cause your browser to hang.   I say this as someone who is actively working on making a webgame in C++/emscripten.   *there are actually such things as web-workers, but they are heavily restricted compared to c++ threads.
  8. Don't do this; it's not type safe. There is a type-safe alternative using variadic templates. However, you may still be better off with a function that takes a container or range.
  9. If you're working with fixed size arrays in modern C++, I suggest using std::array over that bracket syntax. It makes arrays act like every other object in C++, This mostly has stylistic advantages, plus it allows you to pass and return arrays by value, if ever needed.
  10. You could use one member unions to force class members not to be implicitly initialized in the constructor. Then in the constructor body you can use placement new to initialize that member late. Then, if member field is not trivially copyable, you also need to provide a copy constructor, destructor, and assignment operator.   It's ugly, so only use this technique for measurable performance gain.
  11. That's still not correct. Essentially, if you have a non-trivial type in a union, you have to explicitly call constructors and destructors. Calling mObject in the initializer list does this for object, but then you cannot store an ArrayInfo there, without first calling the destructor. So instead, you should not construct either object in the member initializer expression list, instead using placement new in the constructor body. The code looks like this: Type(const Type& that) : mKind(that.mKind) { if ( that.mKind == eArray ) { new (&mArray) ArrayInfo{that.mArray}; } else { new (&mObject) ObjectInfo{that.mObject}; } } (I also made this follow normal copy constructor semantics, which your code didn't do)   Likewise, you need to define a destructor, that will destroy the correct union member explicitly.
  12. It is good advice to prefer interfaces over inheritance, but there are uses for inheritance too. Inheritance does get over used, probably because it is often taught too early to new programmers.   Personally, I reserve the word "evil" for things that are anti-patterns in all cases. For example, in C++, NULL is evil and can get you into trouble; prefer nullptr in c++11 and later or 0 in C++03 and earlier.
  13. Your getting into implementation details of std::vector by using _Myfirst. That kind of code isn't portable. Why can't you just call m_vComponents.data()? as in: <Item Name="Components">m_vComponents.data()</Item> Of course I'm not familiar with how natvis works, and there are peculiarities related to it.
  14. There's a TS. It will not be in C++17, but possibly C++20.
  15. I told you the rule that is applied, but I cannot cite the standard. If you require that level of rigor, I recommend reading the standard yourself.