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

wildbunny

Members
  • Content count

    303
  • Joined

  • Last visited

Community Reputation

550 Good

About wildbunny

  • Rank
    Member
  1. Hi and welcome back! This time I'm going to talk about a trick I used on the old PS2 game '24 The Game' to save over 30% of a frame by hacking the game's monolithic entity system. The monolithic entity system You've probably all seen this design before: Entity manager, stores a list of all entities Each entity implements an Update() function Every frame, the manager loops through all entities and calls Update() on each one The primary problem with this design is it's polling nature; each entity is polled to do work, even when that entity may not have any work to do. This doesn't start out being a problem at the beginning of the development of a game when there are only a handful of entities, but it sure is when the game is full of 1000s of them! In '24 The Game', entities were any object which you could interact with, which included: doors, characters, cars, guns, pick-ups, boxes and any other physics objects. They soon started stacking up in numbers, especially when you consider the game's draw distance. Event driven In an ideal world, the system wouldn't have been designed like this in the first place. Something event driven would have been more appropriate for the majority of entities - so entities just sleep until they are acted upon by an incoming event, such as being shot, or collided with. While asleep an entity would have done no work and therefore taken no CPU time. However, this was not to be since the game was in beta and rewriting the entire entity system seemed like a bad idea(!) Hacking the monolithic entity system So a more achievable method was needed, one which could be plugged right into the existing system without breaking everything. The solution was discovered after making a key observation about the nature of the variable time-step we were already using in game. In a game where the time-step varies from frame to frame (like nearly every game in the world), entities must adjust their behaviour to cope with a differing frame rate - for example, animations move forward a differing number of frames, characters move across the ground differing amounts per frame and so on. This being the case, calling Update() on 'unimportant' entities every 2nd or 4th frame wouldn't break anything and would save a bunch of CPU time. Unimportant entities So, what is an unimportant entity? From the point of view of this system, an unimportant entity is one which is not currently interacting with the player, or is very small on screen, or completely off-screen. Mitigating edge cases Unimportant entities could temporarily have their importance increased after receiving an event, such as being shot, or collided with. This mitigated the problem of 'dumb entities' which would take a long time to react to events in this new system. Screen-space size should be used rather than just plain distance when calculating importance, otherwise zooming in on a far away moving character would reveal jerky animation, as the animation controller only got updated every other frame. Importance overrides will always be needed in some cases, like if you have a bunch of AI companion team-mates who are following behind the player. Very unimportant entities could volunteer themselves to be excluded from Update() completely if they did no work there, such as most physics objects. Results In the end this system saved 30% of a frame in general across all levels, sometimes a lot more which was a definite result. However, if possible don't design a monolithic system in the first place! That's all folks Thanks for reading, hope this post gives you some ideas! For more ideas check out my blog at http://www.wildbunny.co.uk/blog/. Article Update Log 10 Aprl 2014: Initial release
  2. Hi there,   I wrote a series of articles about the process of creating a 2D platform game which uses AABBs exclusively for collision detection. Here is a link to the article which covered the collision detection and resolution:   http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/   There is some free downloadable source-code linked in the article as well which should get you off to a good start :)   Cheers, Paul.
  3. Hi guys, Just written this article that you might find useful; 10 things which have helped me become a better programmer and be more productive in general: http://www.wildbunny.co.uk/blog/2012/11/01/10-steps-to-becoming-a-better-programmer/ Hope it helps! Cheers, Paul.
  4. Hi guys, Just written a new blog post intended to provoke discussion on ways to deal with internal edges in 2D polygonal collision detection: http://www.wildbunny.co.uk/blog/2012/10/31/2d-polygonal-collision-detection-and-internal-edges/ Cheers, Paul.
  5. I wrote this primer / reference material a while back: http://www.wildbunny.co.uk/blog/vector-maths-a-primer-for-games-programmers/ Cheers, Paul.
  6. First of all you'll need an equation which lets you remove velocity in one dimension via an impulse. If you have frictionless collision resolution working already, you have this equation to hand (you're using it to remove velocity in the contact normal direction). So, next step is to find the velocity component in the tangential direction that you want to remove to create friction. * Form the tangent vector using the perp operator on the contact normal * Get the relative tangential velocity by dotting total relative contact point velocity against the tangent vector * Now, you can then generate an impulse to remove some or all of this tangential velocity (most text books say the magnitude of this impulse should be bounded by the magnitude of the normal impulse, but if you just want infinite friction, remove the whole lot) Job done [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  7. Take a look at my little multi-player version of Asteroids, the mechanics are actually quite similar to a racing game where the cars have weapons: [url="http://mmoasteroids.wildbunny.co.uk/"]http://mmoasteroids.wildbunny.co.uk/[/url] If there's anyone else playing when you try it you might be able to see the mechanics you're after working. My server is authoritive over everything except the position of each player; but to mitigate the inherent problems with that, the server simply clamps the maximum speed of each player so no cheating is possible. I simulate on client and server - the only thing I don't do that you'll require is collision between players.
  8. This problem is quite hard - you need to have the client tell the server how many fixed sized time-steps there were between key-actions, then the server can correct forward or backwards (by rewinding time).
  9. [quote name='Hcwool' timestamp='1347531395' post='4979654'] Hey, im trying to figure out collision resolution in as3. I have detection and stuff working i just cant figure out how to resolve it!?! any ideas? [/quote] If you're looking for polygonal collision detection and resolution in AS3, I have a couple of articles which might interest you: http://www.wildbunny.co.uk/blog/2011/04/20/collision-detection-for-dummies/ http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/ Cheers, Paul.
  10. Hi there, Sure, you need to design your constraint so it works in 'relative space' and pushes on object A while pulling on B. I wrote just the article which should help you out with understanding how to design a constraint: http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/ It starts off dealing with simple concepts and builds up to designing a constraint Hope that helps! Cheers, Paul.
  11. [quote name='WhatWhereAmI' timestamp='1346226248' post='4974345'] Thanks. Is detecting desync ever accomplished using some kind of [url="http://en.wikipedia.org/wiki/Locality-sensitive_hashing"]locality-sensitive hashing[/url]? My concern is that if I'm using a physics engine like box2d then there's no guarantee that the two simulations will have strongly similar results even given the exact same beginning state and inputs. The more I think about this problem the more incredibly complicated it becomes. Also, what the hell happened to gamedev.net? [img]http://public.gamedev.net//public/style_emoticons/default/ohmy.png[/img] [/quote] Yes, this problem is hideous. You may have to author your own engine to get the guarantees you need.about the determinism. Alternatively you can use a non deterministic engine and send correction vectors along with the keyboard inputs.
  12. Its very, very hard to get right. Some tips: * use a fixed time-step on client and server * send player inputs and correct for latency - keys must be down for the *exact* number of time-steps on both client and server The goal is to try and get exactly the same results on client + server given the same inputs. You'll probably need to hash the state of the client and compare that against the hashed state of the server to detect desyncroisation issues. Cheers, Paul.
  13. [quote name='Inferiarum' timestamp='1344727569' post='4968558'] I guess each physics simulator works with impulses implicitly because of the discrete nature of the simulations. The forces under consideration are used to keep bodies in resting contact. [/quote] Certainly it used to be the case that most simulators would treat collisions via impulses and then resting contacts via a force/acceleration model, but things have come a long way since then - these days its popular to treat collision and resting contact via impulses only - if handled correctly they are just visually stable, handle stacking very nicely, can treat friction without having to linearise and are numerically stable and you'll never end up in a situation where your LCP solver suddenly explodes due to an 'infeasible solution'. For research, I suggest googling 'sequential impulses' ref Erin Catto. Cheers, Paul.
  14. I strongly urge you to discard the force/acceleration model in favour of impulse/velocity. The later is a million times easier to implement and to find up to date tutorials / example code. Have you seen my 'Physics engines for dummies' article? http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/ It should give you some pointers Cheers, Paul.
  15. I wrote a series of articles about making an old-school 2d platformer using modern techniques, including a physics engine: http://www.wildbunny.co.uk/blog/2011/12/11/how-to-make-a-2d-platform-game-part-1/ http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/ http://www.wildbunny.co.uk/blog/2011/12/20/how-to-make-a-2d-platform-game-part-3-ladders-and-ai/ Hope they help! Cheers, Paul.