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

frob had the most liked content!

Community Reputation

44847 Excellent

1 Follower

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

  1. Algorithm

    Agreed about the 200 objects being small. If they're cache friendly and arranged linearly you could iterate over them all faster than you could jump around a tree with the corresponding cache misses. For timing approximation, iterating over a cache-friendly array takes around 0.5ns per item since array traversals are prefetched to L1 cache. Jumping through a tree takes about 10ns (or more) per lookup as they're usually in L2 cache (or worse, L3 or main memory). My search skills is failing right now so I'm not finding the links, but I believe it was the DICE Battlefield 2/3 team who basically abandoned the traditional spatial trees in favor of cache friendly objects in flat arrays because they were faster for their work.
  2. Just realized I forgot to mention: Instead of distributing a drive with music, give links to your YouTube / SoundCloud / Whatever account that features your music. I don't want to directly plug in anything that you've got, but I trust the major web sites to give me a stream of your recordings. I won't look at them from a spam, but if I'm in the market and looking for you, I'd expect some way to hear some demos of things you've created in the past.
  3. Probably easier to ask what you don't understand about it. Do you understand what the basis vectors are? Do you understand what the cross product operations do? What about the function is confusing to you?
  4. 1) No, but I also have spam filters. I suppose it is possible they could be sending me things I'm blissfully ignoring. 2) Everyone should present themselves professionally. I expect that if I have a need to hire a composer, I would be the one contacting them. I don't expect to have a steady stream of composers marketing themselves through spam or other email in an attempt to get business. 3) I've worked with people we have worked with in the past. It is rare to need someone new. Note that we're talking about composing a small amount of music perhaps only a single time every year. 4) I would almost certainly not listen to it. If I get a business card I might file it. If I get a USB drive I'm probably just going to format it and use it for temporary, throw-away storage. 5) When I am working with them I engage in a steady stream of email and video chat meetings. Depending on where we are on the project that can mean anywhere from daily face-to-face meetings to weekly face-to-face meetings, and email messages as needed but at least weekly in the most extreme case. One key thing to remember is that most games don't have a steady need for original composition. It is a rare event, and when it is needed the job is almost always filled either by people who've been used in the past, or by people who are connected by friends or friends-of-friends. I've never heard of people reaching out to unknown strangers as music composers, that has ALWAYS been through existing connections, or through reaching out to known composers, or with friends-of-friends as the most distant for the hunt.
  5. 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.
  6. 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.
  7. The FAQs went away with the forum software transition.
  8. 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.)
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.