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

frob

Moderators
  • Content count

    10742
  • Joined

  • Last visited

  • Days Won

    4

frob last won the day on July 19

frob had the most liked content!

Community Reputation

44846 Excellent

1 Follower

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. Item 1 is mostly true, they have done what they can to restrict direct access. Many games have various practices that still expose addresses. Hook up voice chat and you can likely see a direct connection either to the player's IP addrss or to a repeater's IP address. Items 2 and 3 seem a little odd, so perhaps some clarification is needed. Severs have a heartbeat to their controllers, but it seems like you are asking about using the server acting as a star, and each spoke in the star being told the status of other spokes on the star. You might be asking something else. Any game can implement their own heartbeats if they want, and many games do. Track the time since last message from the player, and if exceeds a specific time you can take an appropriate action. If you want to spread that among other users, the star's hub could send that out to every spoke or to every leaf node. Details might get more complicated depending on how your game's logical networking works out. If you have a full star where everyone must connect directly to the star's hub, or if you require a complete mesh where everyone can talk directly to everyone, you can require them to all chat occasionally. But if your game allows for other layouts where individual clients can act as a forwarder or repeater, you may not hear directly from another node even though messages are passing through. If you want to pass any of that information along within the game, it will be your game's code doing that, not the API.
  2. And just for clarification, exactly how old are these old phones you are talking about? The official end of support for Android devices is 3 years after product launch or 18 months after first sale, which ever is longer. After that you're entirely on your own. Apple devices are similar, 3 years of support. The are called "vintage" for a few more years, then they're obsolete. Everyone knows it is short, even us as consumers. However, as customers it is clear the devices are no longer supported, and as developers it is unrealistic to expect years-old devices to conform to this year's needs.
  3. The FAQs went away with the forum software transition.
  4. First thought is to use a better texture compression algorithm. The DXT# formats (often called dds format or S3 algorithms) give a 6:1 compression ratio. PVRTC2 gives 8:1 or even 16:1 compression depending on which sub-format you use. Others like ETC and ASTC also have great compression rates but varying hardware support. Make sure you have set Unity to compress those textures. After that, make sure you are actually destroying the textures. It will have some memory that won't instantly vanish but will be cleaned up, but the bulk of the memory should be immediately released. You should be able to load them and replace them all as you go. The resources will be released as you move along, and assuming you've released all the references, the other allocations will be picked up by the garbage collector in due time. (Note: Don't force the garbage collector to run. It is designed by default to run at lower priority during idle cycles, forcing it to run usually means interrupting time-sensitive work.)
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.