Jump to content
  • Advertisement
  • 07/19/11 04:00 AM
    Sign in to follow this  

    Game Pitch - Bioshock

    Game Design and Theory

    Gaiiden
    [size="5"] About Game Pitches Welcome to Game Pitches! This site serves to be a free resource to game designers offering them the web's largest single collection of game design documents and game pitches. Be they famous or obscure, big or small, successful or not, this site is intended to be a resource for learning how better to design and pitch games in the spirit of sharing information and improving the state of the art through freely available knowledge. Let's make great games!"

    - Jon Jones Founder, GamePitches.com

    Here is yet another really cool online resource we're happy to feature by reposting one of their more popular design pitch documents here on GameDev.net for everyone to check out. There's plenty more over on GamePitches.com and new ones are being added constantly. It used to be that design documents were the popular thing to post online for budding developers to read through and see how a professional game was organized on paper, but once you get the hang of that how to you seek out financing from a publisher to produce your game? Now you can see how well-known studios have convinced people to give them money to make their now well-known games. Learn by example with this great resource!

    - Drew Sikora Executive Producer, GameDev.net

    [size="5"]Irrational Games - Bioshock Pitch Document

    [media]http://www.scribd.com/doc/32211144[/media]



      Report Article
    Sign in to follow this  


    User Feedback


    "Make you own Weapons" - I don't remember that part. Would be interesting to know why some ideas are scrapped exactly.

    I mean, I can understand - I'm happy with guns I pick up, crafting weapons sound more like work than fun - but I don't know.

    Share this comment


    Link to comment
    Share on other sites
    Well it was possible to [u]upgrade[/u] weapons... Maybe they initially wanted to let the player construct the weapons from scratch? That would be a little far fetched, i think...

    Share this comment


    Link to comment
    Share on other sites
    The story itself, about being a deprogrammer and rescue an heiress sounds closer to what they are using in Bioshock: Inifinte.

    Share this comment


    Link to comment
    Share on other sites
    Funny, the main character Carlos Cuello was the technical lead when I was working on the PS3 version.

    Share this comment


    Link to comment
    Share on other sites
    I notice there're a few pie-in-the-sky features in this pitch that never made it into the final game. I'm interested to know, did they have a proof-of-concept prototype to go with this pitch, or were they able to get initial funding purely off their reputation and this document?

    Share this comment


    Link to comment
    Share on other sites
    This is a great service to current and future game developers everywhere! I really enjoyed reading through this!

    Share this comment


    Link to comment
    Share on other sites
    Hinch, I doubt there's ever been a game pitch that didn't promise the moon. Sometimes it's hyperbole, sometimes it's ideas that don't work with how the game evolves, sometimes it's just lying to get into a funder's pockets. In any case, you'd have to ask Ken Levine that question.

    Share this comment


    Link to comment
    Share on other sites
    I love of idea of controlling the game world. If that made it into the full game that would of been awesome. Still bioshock was and still is an outstanding game.

    Share this comment


    Link to comment
    Share on other sites
    I feel like the weapon customization they've promised was perhaps too close to the Deus Ex franchise. Maybe it did not stand out enough to make it into production. Still, I'm curious how far along they went with that idea... alpha? beta? who knows...

    Share this comment


    Link to comment
    Share on other sites


    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
  • Game Developer Survey

    completed-task.png

    We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a $15 incentive for your time and insights. Click here to start!

    Take me to the survey!

  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By Loosearmy
      Concept for Delayed Shots in a Fast Paced Shooter
       
      The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?
    • By mujina
      What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
      I'll be more specific about my design issue:
      I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
      My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
      for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic `get_collider_of_entity` function, but rather a function `get_circle_collider_of_entity` and a separate one `get_line_collider_of_entity`, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
      I am in need to write a system as the one in the snippet above. I can write several overloaded `check_collision` functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic `get_collider_of_entity` function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
      One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
      get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
      Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual `collide_with(const Collider& other)` method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
      A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
      I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!