• 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

  • Days Won


frob last won the day on July 20

frob had the most liked content!

Community Reputation

44842 Excellent

1 Follower

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. It should be interesting, with points over the years coming from the really old system of voting pepole rather than posts, the article submissions, the voting of others, and so many other factors. Points don't matter in the real world, but in some ways it feels like we've all been put on a roulette wheel, waiting for the spin. I'm curious and also trepidatious about the whole thing. Let's see what shakes out.
  2. The typical approach is to have data that gets swapped out. You might pass an index to a table for the source or target, you might pass an object for the source and the source for the target, or something else. For example, adding that information to the object itself and accessing it generically: force += Combat._attacker.Attr["alacrity"]; or perhaps: force += Combat._attacker.CurrentAlacrity(Combat._defender); or accessing it through another table: force += CombatAttribs[Combat._attacker].["alacrity"]; I prefer the function version above, since it more easily allows you to add modifications based on the source and the target, such as a bonus versus dragons or penalty versus shopkeepers or whatever fits your game.
  3. It isn't a bad thing. It introduces a slight cost but keeps options open for extension later through dependency inversion. If everything is implemented against the base interface the concrete type doesn't matter. If the cycles were critical then I agree it is wasteful, but for what was described that won't be a concern.
  4. That looks about 15 years old, maybe a little older. It will work if you use software from about 15 years ago, maybe some software from 2005 or 2007 at newest. The big difficulty will be getting modern software that works on that machine. Few development tools will run well on it, and modern compilers often assume SSE3 or SSE4 are present, but they probably aren't on your machine. You can probably pull down old versions of tools, old compilers, old software. You will need to search the web for them or find old open source projects from years ago. Most major vendors removed that software from their listings many years ago, so all I can recommend is that you visit archive sites.
  5. Unreal

    Many ways to do it. The first and most broad may be a flag that fragments don't collide with other fragments containing the same component. Another may be to maintain a list of non-destruction objects, or perhaps destruction-causing objects, on your component. When fragments break off, mark their parents ID on the list. When it comes time to collide, if any ID matches both lists or each other's IDs, the damage doesn't happen. Depends on how they are moved in your game. Immediately coming to mind, if they're physics driven, set them far enough apart they don't collide with each other, then apply forces along your plane. There are many different representation of a plane and rotation by positions, some make this work easier than others. Again with the first solution that jumps out at me, start with an axis of rotation through the explosion point. For example, if you want to spread them on the XY plane pick the Z axis, or the XZ plane pick the Y axis, if you've got some other plane pick the orthogonal axis. Select any angle of rotation around that axis for your directions. After that apply a rotation matrix for the direction you want to travel. If you're spreading in n directions you may want to subdivide it into n blocks then pick a random angle within that block.
  6. Make hobby games because you want to. When approached as a business, with actual business plans, with market research, with business contacts, and with ensuring you have experienced people doing the job, in that case the odds are far more favorable. Most hobby and amateur developers make the games they want to play for fun, model them after existing successes, and never fully develop the ideas, let alone fully develop a product. Usually the products have no niche to live and are instead dumped among mass-market products. Usually they have no marketing, no distribution plans or processes. Or in other words, they're like the kids selling lemonade from a card table on a day too hot for people to be outside, on a dead-end street in suburbia, wondering why they have no sales.
  7. Use whatever you want, just be consistent. The I prefix is fairly common, such as IWidget. A suffix is also common, such as WidgetInterface or WidgetBase.
  8. Doesn't really matter. As I wrote above, it is going away, the language committee is dropping the old form and moving to something different that satisfies those requirements. The current feature work on metaclasses includes a new metaclass called "flag_enum", which should satisfy what you're looking for. It is planned to be inside the std:: namesapce. It does several things outside what enums do, and does the things people want with the flags mentioned above. The generated values are constexpr. It respects type safety, prevents mixing with other types including integers, and all the rest. It doesn't help today, but it is the direction the language is moving.
  9. That means with the constructor initializer list. That is the constructorname : variable(value) thing you've got up there. Be certain they are in the same order as they exist in the class. Initializing them inside the body takes place after the others, so putting it in the body also incurs the cost of multiple initializations for types that have initializers/constructors. Initializing them the way you are doing it now does have the benefit of ensuring a value is assigned, at the risk of potentially paying the cost multiple times. If you're fine with the cost and don't trust yourself, what you've got can work.
  10. Note that the initialization has a cost. It is small, but it exists. You can often do the initialization at the same cost -- and possibly at a lower cost -- with your constructor. Why do you need to initialize mWindowCaption? It is a std::string, it comes properly initialized to empty all by itself. Are there items on that list that are initialized or set to specific values at other times? For example, you probably are setting the application pointer, the width and height, and a few other D3D values immediately after construction. Why do you blank those out and pay the cost of assigning to them twice? If proper usage requires you to set them to a value before they are otherwise used, initializing them to a value such as zero or null and then immediately writing to them a second time with the expected value is wasteful.
  11. Both toward the original topic regarding the bitwise or operations no longer working for enum types, and toward your concerns, it seems a history lesson is in order. Back in the 1980s when C++ was created, people already knew this was an issue with enum. That is why every language that branched out from the proto-C of the 1970s has implemented different forms of enum. Back in 1994, Stroustrup wrote in his famous book on the history of the language, that "C enumerations constitute a curiously half-baked concept", then described various ways that they were broken in regards to C++. The use of them as a container for flags was one of those flaws described 23 years ago. The use of enums to wrap flags as a type has been considered a defect in the language since the language came out of Bell Labs, and was considered by a few people to be a defect in the C language before that. The C++ standards committee debated and discussed how to fix what they considered flaws, and to do it in a way that did not break legacy code. Some of the proposal attempts are documented on the committee's official site: N1513 N1579 N1719 N2213 Note how in several of the documents it is described as the first and biggest flaw, the compelling reason to get rid of it. Note the names on those proposals: David Miller, GCC steering committee founder. Bjarne Stroustrup, creator of C++. Herb Sutter, C++ language committee convener. There are other high-profile names in the discussion notes, but those three as the change's sponsors are critical. The most influential people on the language and its future features all consider that patterns as a defect. Yes, many code bases rely on the behavior. That is why the many people and organizations that direct the language's growth over time cannot get rid of the behavior. But the compiler creators, the language standard committee, the compiler steering committees, various compiler vendors, and many professionals all feel this is an abuse, misuse, or otherwise a flaw in the language that should be avoided and eventually removed. So attempting to keep it back on topic, the operations are no longer defined. They will not be returning. You can write code to coerce the operations to exist using code as others have described, but the language has been slowly moving away from that construct over the past 20 years, and it will become less and less supported over time.
  12. Regardless: First, I have been bit by those rules Hodgman mentioned before, where enums were no longer equal because they were automatically different types, and because of the new type promotion rules. Nothing's better than looking at subtle errors spread through an enormous code base as what used to be a 32-bit compare became an s32 and u32 silently promoted to 64-bit and compare unequal. Trust me, there are better things to do with your time. Second, none of them really matter because that is not what enums are meant for. There are many things you can do with things in the language, and there are things the language was meant for. The fact that you need to do all that typecasting is a clear sign that they are being used incorrectly. Third, while enums have been used as flags in the past and C uses them that way, the C++ language diverged from C nearly 34 years ago. People still get them confused as "c/c++" and other nonsense, but the two have been distinct for longer than many of the site's visitors have been alive. Just because something happens to work one way in one language does not mean it applies in another language. Names can mean different things in different languages. Enum is a great example. An enum type is different in C, C++, C#, and Java. There are a few superficial differences, but the implementation of each is quite different. Ten years ago the standards committee had tons of discussion and looked at a lot of code from a lot of experts. Then C++11 implemented the additional type rules on enums. In 2017 if you use a C++ enum type for anything other than named enumerated values, and that includes bit flags, you're probably using them wrong. The language has moved on, possibly leaving you in the dust of history.
  13. The term is what, 8 weeks? 10 weeks? That is not much time. Get your information together and begin applying for jobs immediately. Include your expected graduation date in the applications. Start networking and tell people your expected graduation date there, too. Talk to your school about what employment options they can help with. Don't wait until graduation day to line up your first job. Tom Sloper has several FAQs about this in general on his site, start with this one then keep reading. As a fallback plan, also start applying to non-game jobs. That is one of the biggest reasons against a game-specific degree, there are times when finding a game development job that is a good fit is hard, so you'll need to find employment outside your preferred industry. But you are where you are, so hopefully it will all work out well.
  14. Using GraphDB for your game's spatial queries and Redis for game data lookups, I look forward to seeing what you can create. It is not that the choices cannot do the things, it is that you are doing things at a breathtakingly wrong scale. Imagine going fishing with grandpa in a small lake but instead of a rowboat and poles you've got a battleship and explosive depth charges. Or wanting to find a path to the corner store by bringing in an army of scouts and pathfinders to make sure you've got the path down the street safely and securely. The tools you are discussing are capable of doing the things you describe, but they are for radically different purposes. At this point I hope you go forward with your project. It will serve as an enlightening learning experience.
  15. Nope. It is implementation dependent size if none is specified, and on most major compilers defaults to a 32 bit signed integer usually, but sometimes defaults to a 32 bit unsigned value or a 64 bit signed or unsigned value, and may potentially be something else entirely. No. An enum is not "just a stupid integer". At no point in the language history has it ever been "just a stupid integer". Even going back to C, an enum was something more specific than the two things it replaced, a stupid integer constant and a macro-defined value. An enum is more than either of those things. By calling it an enum you are assigning it specific meaning which the compiler can use. You are -- as a convenience -- treating it as an integer. You are also treating it as a plain int, which, by the way, is also mostly going away. If you have a plain old int in modern code then you're doing something wrong. Specify the width and signed-ness. You have been told why, and provided with THREE alternate solutions to do what you are trying to do. The language is trying to protect you. If you are dead-set on removing those protections you are free to do so, but it is not a wise decision. Telling the compiler you have one intention, then moving on with a different set of uses that violate those intentions, that is a sure-fire way to introduce bugs in your program.