MSPA Forums
Page 1 of 6 1234 ... LastLast
Results 1 to 25 of 137

Thread: SBURB: The Game

  1. #1

    SBURB: The Game

    To discuss this in real-time, get on Pesterchum and go to the SBURB_Game memo, or pester me (paperAgent) if you have any questions.

    We now officially have a forum specifically for this project. Feel free to discuss the project here if you wish, I'll continue to follow this thread, but if you really want to help out then I'd suggest registering and posting on the SBURBDEV Forum.

    As many of you are probably aware, there's been a lot of talk and pondering and general idea-throwing about an actual game based off the SBURB structure. Now, many of you are probably thinking, "Why did you make this thread? There's already a thread for this!"

    Well, yes, there is a thread, but while there's been a lot of great ideas and theorizing and, "We should do X this way!", there hasn't been anything concrete to come out of it. The reason for this isn't that SBURB as a game is impossible to create, or even that we don't have people capable of making it, but simply that there's no real organization or collaboration between everyone.

    In an effort to rectify this, I'll be taking up the role of project manager. I'm doing this not so much because I think I'm particularly suited for the role (I'm not), but just because someone has to and apparently nobody has yet. So here I am.

    This thread is for the discussion of the game in general, reporting progress on the game, and so on. If you have an idea for a specific part of the game that development hasn't reached yet, then I'll encourage you to post your idea in this thread. There's already a bunch of good ideas there, and I'll be keeping up with it and pulling ideas out of it as they become relevant to the current development of the game.

    If you have a question for me, pester me on Pesterchum, my chumhandle is paperAgent, and I'll be on there whenever I'm online. You can also visit the SBURB_Game memo (chatroom) to discuss the game with me or with anyone else who happens to be there.

    Finally, you can safely ignore SkaiaNet, at least until such time as I can get in contact with laptopPsyche. If you're looking to join the development team, either contact me directly, or get in contact with whoever is in charge of the area you're looking to help with.

    Currently we are discussing the graphics system that the game will use, namely 2d, 3d, or some mix. The discussion will be ongoing for the next few days, so make sure to weigh in if you think you have something to bring to the discussion!
    Last edited by AgentPaper; 04-08-2011 at 10:15 PM.

  2. #2

    Re: SBURB: The Game

    Here's a list of all the various aspects of the game that need work. As various parts of the game are started/progressed/completed I will update this list to reflect the overall status.

    SBURB in pieces:
    • Character:
      • Stats
      • Background?
      • Appearence
      • Inventory
      • Fetch Modus?
      • Strife Specibus
      • Tiitles
    • Items:
      • Alchemy
      • Database(This has to do with the server)
      • Attributes
      • Grist and costs
    • Incipisphere:
      • Worldgen:
        • Landscape
        • Consorts
        • Denizens
      • Kingdomsgen? Maybe we could give some starting internal conditions that could lead to different interactions in each play.
      • The Veil
    • Interface:
      • Controls
      • 2D/3D
      • Quests (All that beautiful idea you have AgentPaper)
      • Battles? Should they be turn based or action RPG? (I favor the latter)
      • In-game communication (Be it P2P or P2Consort or whatever)
    • Server:
      • Whatever the server needs I really don't know


    Plus anything that me and codingTornado didn't think to add to this list. If there's something we're missing feel free to point it out so I can add it to the list.

    Other than working on specific parts of the game, we're going to need people with expertise and hopefully experience to help organize various aspects of the game:

    - Project Manager (aka: Cat Herder): This would be me. My main responsibility is to keep everyone productive as much as possible. Other than that, I'll also serve as a final word on any questions about how the game should be built, if we can't reach a consensus. I'm not a dictator though, this is just so we don't spend three months trying to figure out whether to turn the sweet bro menu flipways or turnwise.

    - Lead Programmer: In charge of making sure all the bits and pieces line up. This is probably the position we most need filled at the moment. I can stand in for most of the other positions until we find someone else to do it, but here my expertise falls short. Until this position is filled, we essentially can't get any work done on the game.

    - Lead Systems Design: In charge of all the core systems that make the game actually run. This includes all the various Procedural elements of the game. We may also want someone specifically in charge of a few of the more complicated systems, such as the world generation system, the story manager, etc.

    - Lead Story Design: In charge of constructing the world that the players play in. If we end up using a procedural story system, then this person would be working closely with whoever is in charge of that.

    - Lead Character Design: In charge of everything to do with individual characters. This would include things like the Title system, character creation, stats, abilities, and so on.

    - Lead World Design: In charge of creating the world that the players are running around in. This would include a lot of art assets, more than any other specific role, but would also be involved in things such as procedural world creation.

    And so on. Don't take this as a list to be filled out though, the above are just a few examples of the kind of things we need people to step up and take responsibility for.
    Last edited by AgentPaper; 04-03-2011 at 05:44 PM.

  3. #3

    Re: SBURB: The Game

    Project Members:

    Project Manger: AgentPaper (paperAgent)

    - Lead Programmer: fractalWizard

    - - Programmer: codingTornado

    - - Programmer: Yuutousei (ghostlySamurai/hystericalHistorian/doubtfulStar/flightyTune)

    - - Programmer: immortius (winglessAngel)

    - Lead Graphics Design: Open
    Last edited by AgentPaper; 04-05-2011 at 08:54 PM.

  4. #4
    Mage of Breath introvertedOptimist's Avatar
    Join Date
    Sep 2010
    Location
    Land of Snow and Fog
    Posts
    582

    Re: SBURB: The Game

    I'm in. I'll definitely help out with this as much as I can.

  5. #5
    Scribe of Machinery Biophysicist's Avatar
    Join Date
    Oct 2010
    Posts
    145

    Re: SBURB: The Game

    I can program a server (if you give me one to program - I can't run a server at home because of our firewall and stuff). I can also do other programming, but I'm really slow at that, and busy.

    Also I am pretty good at theorycrafting and gameplay ideas.
    Your chumhandle is sanctifiedSuffering and you = a guy who = obsessed with equals signs.

  6. #6
    I see through your soul Gecky's Avatar
    Join Date
    Dec 2010
    Location
    Geckyland
    Posts
    1,610

    Re: SBURB: The Game

    I am ready to help with art, plot and programming

  7. #7
    spacetimeCounselor -Benedict's Avatar
    Join Date
    Jul 2010
    Location
    Dang roomba
    Posts
    3,302

    Re: SBURB: The Game

    Oh hey, this is an actual thing somehow. I've been looking at the back-and-forth regarding the procedurally generated Land content side of the project, and it's really interesting. I'm more on the side of thinking that nearly any combination of aspects could create an interesting land via the generator- and I have a particular idea for handling really incongruous combinations. Say you had, as was put forward, a Land of Heat and Rain/Land of Magma and Water- or any combination of aspects whose properties were diametrically opposite, and would cancel out their most extreme attributes in the generator.
    Let's say you have one attribute that sets Coldness or something to 100, or some arbitrary number meaning "big". And its other attribute set Coldness to -100 (or Hotness to 100, or what have you). Whenever the engine performs a calculation averaging the values to create a Land, it would first calculate the difference between the values- the Dissonance, or Extremity, and use that to decide what measures would be taken to help such Lands work. For example, a Heat and Rain land, with conflicting water types, would have a massive Dissonance and the generator would divide it up into either a patchwork Land, or otherwise generate landscapes based not on the average of the values but on particular features of the geography colliding.
    Additionally, you can use Dissonance to determine other land features- Lands with combined attribute Dissonance of sufficiently high levels could give the Land an attribute called Bifurcation, which would influence things like story paths and the Denizen in addition to geography.

    On a completely different topic, the "type of game" question is complicated- lands with Clockwork attributes or other descriptors regarding height would be problematic in straight overhead 2D- which calls for a flat landscape- and Sburb's central mechanic of upward movement through a house and towards Skaia is impossible to represent effectively with an overhead view. Similarly, a 2D platforming view is going to negate Sburb's secondary theme of exploration. Any straight 2D game is going to have problems with Upward Movement or Explore-ing.
    I think the path that should be taken to cut down on work (and simplifying procedural generation) is to use an isometric 3D perspective- not free-moving like Zelda or the walkaround flashes, but with all map elements, actors, and objects being part of a 3D grid- think Minecraft without grid-independent entities. Save resources and development time, avoid corrupting the game's themes.

    Also, with regard to procedurally generated content, Squidi.net's Three Hundred Mechanics has a lot to say on the issue, so it'd be a good idea for designers on this project to take a look at the relevant mechanics in there.
    Here is my Tumblr and here is my Dangan Ronpa forum adventure and honestly both of those are pretty interesting you should check them out.

  8. #8

    Re: SBURB: The Game

    Ok, I am calling a general halt of ideas. I should have made this clear earlier, but we don't need more ideas on how the game *should* work right now, we need people to start defining how it *does* work. I would suggest starting with something like a character creator, or the world generator, or the storyline generator, or any of the many many things brought up in the previous thread. It doesn't really matter which, and it doesn't really matter what you program it in, we just need to start getting work done on these problems.

    I will be in the SBURB_Game memo on pesterchum as much as possible if anyone has any questions, and I'll do my best to answer them, or direct you to someone who can.

    I hope nobody takes offense but we really don't need any more ideas now, especially as a lot of them are starting to repeat. If you really have to get your idea off your chest, then post it in the previous thread. If you don't know what to work on, feel free to browse the other thread, there's plenty of good ideas in there.

    Edit: I should note, if you do take up a part of the game to work on, make a note of it here, feel free to ask for help from other people, and generally check in with an update to your progress whenever you can.

    And one more thing: One thing I will encourage discussion is what language we will be programming this in. It would be best to decide this as soon as possible to keep us from wasting a lot of time coding in two different languages. Even so, don't take that as an excuse to not start programming now. If it ends up being in the wrong language, I'll translate it myself if I need to.
    Last edited by AgentPaper; 04-02-2011 at 06:44 PM.

  9. #9
    Scribe of Machinery Biophysicist's Avatar
    Join Date
    Oct 2010
    Posts
    145

    Re: SBURB: The Game

    Put me down as server coder. I'll be doing it in PHP, but that won't matter to the main coder as long as we work out a protocol (which we'd have to do regardless of my choice of language).

    Unless there's something wrong with using PHP for this purpose. >.>

    As for language: I DO know some stuff about non-web-coding, and would recommend C++, or maybe Java if you want to use jMonkeyEngine, which I've found easy to use in the past. Or, it could, maybe, be done in a browser. But that would probably be stupid.
    Your chumhandle is sanctifiedSuffering and you = a guy who = obsessed with equals signs.

  10. #10
    Finally changed my avatar Miff's Avatar
    Join Date
    Jun 2010
    Location
    Huntsville, AL, US
    Pronouns
    they/them/theirs
    Posts
    1,863

    Re: SBURB: The Game

    Quote Originally Posted by Biophysicist View Post
    Put me down as server coder. I'll be doing it in PHP, but that won't matter to the main coder as long as we work out a protocol (which we'd have to do regardless of my choice of language).

    Unless there's something wrong with using PHP for this purpose. >.>

    As for language: I DO know some stuff about non-web-coding, and would recommend C++, or maybe Java if you want to use jMonkeyEngine, which I've found easy to use in the past. Or, it could, maybe, be done in a browser. But that would probably be stupid.
    The thing about using PHP, or any web framework really, is that you're limited to wrapping all communication within HTTP, which would be a negative to preformance.

    A custom server written in-- anything really-- that uses native sockets and a custom protocol would be more apt. In fact, this should be programmed within the same language as the game client, as to facilitate transmission of data in the most effective manner.

  11. #11
    Scribe of Machinery Biophysicist's Avatar
    Join Date
    Oct 2010
    Posts
    145

    Re: SBURB: The Game

    Hm, okay. Didn't realize HTTP was slow like that.

    Guess that means I'm out.
    Your chumhandle is sanctifiedSuffering and you = a guy who = obsessed with equals signs.

  12. #12
    Hacker of Time demosthenes2k8's Avatar
    Join Date
    Jan 2011
    Location
    Land of Bricks and Code
    Posts
    295

    Re: SBURB: The Game

    I still say C++ is the best choice for this project, just because native code will be the fastest. The down side is that it'll have to be recompiled for every target platform, but that's kinda expected.
    (I WOULD join the memo, but I'm exhausted from a long day, and I'll do it Tuesday)
    Your trolltag is chronoCoder and you // c0mment 0ut @11 0f y0ur text

  13. #13

    Re: SBURB: The Game

    Not saying I'm joining, but you're going to need a pretty huge art team to make all the different combinations of weapons, objects and other assorted crap that'll be in it. I'm aware that there are ways of gluing bits and pieces from one thing onto another, but that's still a huge task.

  14. #14

    Re: SBURB: The Game

    I'll help. Spriting, Programming - General planning, all that good stuff.

  15. #15
    Frost's Avatar
    Join Date
    Sep 2010
    Location
    Rolling for aye through Space and Time
    Posts
    2,154

    Re: SBURB: The Game

    I have a few reservations about how this is being organised, but MSPA is like a paragon of innovation, so let's see how it works out.

    I just want to mention one big thing: you need to design the procedural engines and the game itself separately. The extremely technical and advanced programming discussion is going to alienate people who want to design adorable consorts, while the discussion of barely-relevant design issues is likely to irritate the programmers until they say very stupid things like "please stop giving me ideas". I understand that there's going to have to be a fair bit of overlap, but as long as each group gets a vague idea of the decisions the other group is making (without all of the opaque/boring details), synchronisation should be easy enough.

    AgentPaper, do you have a lot of experience designing and programming games, rather than just raw programming experience? If not, I'd advise you to appoint a deputy in charge of anything "non-technical". Maybe have them create a second thread.

    PS: Just to be clear, I'm not nominating myself as the deputy, and this whole post wasn't an unsubtle takeover attempt. I have enough cats to herd in the Nepetaquest thread.

    PPS: My programming language suggestion is to put it together in C++ using portable libraries. SDL for windowing, who-knows-what for networking, and nothing else has to touch the OS. libavcodec and libvorbis can give you portable music, libpng gives you game-appropriate images, OpenGL gives you 3D. For some reason the thought of writing something so programming-focused in Java feels like a death sentence.
    Last edited by Frost; 04-03-2011 at 10:58 AM.

  16. #16
    codingTornado's Avatar
    Join Date
    Oct 2010
    Location
    Argentina
    Posts
    265

    Re: SBURB: The Game

    I do not agree AgentPaper. We DO need to decide what we are going to do in order to get coding.
    For example, it's important to have the 2D/3D discusion and reach a final desition so we can properly specify the challenges to be dealt with and run proper tests and be sure the problem IS being solved.

    I suggest this:
    • We should NOW start breaking the game into all the problems and subproblems it poses and build a list of them all.
    • We list the decitions taken on the various code chunks to do; That way people will stop posting new ideas unless it poses an improvement or is a better, more implementable, solution.
    • Any thing we didn't reach a decition on, should get talked into one OR be solved by making working, extremely simplyfied, examples to test and compare by everyone and take a better desition.


    Concerning the first post, I believe that SBURB had this camera rotating buttons, so as long as we can make a Sims-eske world 2D will work and be like in the comic. If we do there is the problem of the character and fights and shit. That is what leads me to think that 3D is the way to go; We can and should take some liberty when dealing with some problems if it will solve as long as the game mechanics work the same.

    If we go 2D, character and object sprites should be made for at least 6 of the 8 most simple directions, else we would be restraining to much the player in its movement. Also, fights in 3D have much more intensity than fights in isometric 2D.
    3D would solve this issues(in particular the procedural generation of items which IS critical and can't be left out) at the cost of it being harder to code. Well I don't really care it being harder if we don't have to make 6 times the same animation and all that.

    On the players issue, we should go SBURB and make server and client and have players connect in a ring and have them share through that objects data and things like that, maybe torrentlike or someting, servers and networking are not my areas of expertise.


    SBURB in pieces:
    • Character:
      • Stats
      • Background?
      • Appearence
      • Inventory
      • Fetch Modus? I say to hell with it and it's complicated compications
      • Strife Specibus
    • Items:
      • Alchemy
      • Database(This has to do with the server)
      • Attributes
      • Grist and costs
    • Incipisphere:
      • Worldgen:
        • Landscape
        • Consorts
        • Denizens
      • Kingdomsgen? Maybe we could give some starting internal conditios that could lead to diferent interactons in each play
      • The Veil
    • Interface:
      • Controls
      • 2D/3D
      • Quests(All that beautiful idea you have AgentPaper)
      • Battles? Should they be turn based or action RPG(I favour the later)?
      • Ingame comunication(Be it P2P or P2Consort or whatever)
    • Server:
      • Whatever the server needs I really don't know



    EDIT: I fully agree with Frost and in particular with his PPS
    Last edited by codingTornado; 04-03-2011 at 11:25 AM.

  17. #17

    Re: SBURB: The Game

    Pseudo code for world decision:
    /*Very oversimplified*/
    string x[5] = ["Light", "Frost", "Flame", "Desert", "Shadow"]
    string y[5] = ["Song", "Oil", "Razors", "Rain", "Heart"]

    rand()%4 = a;
    rand()%4 = b;

    if(Player_Title = "Space") {
    cout << "Land of" << x[a] << "and Frogs";
    /* send the land x[a] and frogs data to character info */
    }
    else {
    cout << "Land of" << x[a] << "and" << y[b]
    /*Send x[a] and y[b] to Character info*/
    }

    /* the x array decides the base land -> a desert world, an ice world, etc.; while the y array decides qualities of the world. */

  18. #18
    Philosopher of Truth enragedFingernail's Avatar
    Join Date
    Mar 2011
    Posts
    570

    Re: SBURB: The Game

    As for 2D or 3D, why not make the game like it is in the imp battle area in [S] John: Enter Village?

  19. #19

    Re: SBURB: The Game

    First off, thank you both for the input. I know I've probably already made a number of mistakes in organizing this, but I'll always be open to advice and criticism. I'll try to at least explain my reasoning for any decisions, even if I don't change my mind.

    Quote Originally Posted by Frost View Post
    I just want to mention one big thing: you need to design the procedural engines and the game itself separately. The extremely technical and advanced programming discussion is going to alienate people who want to design adorable consorts, while the discussion of barely-relevant design issues is likely to irritate the programmers until they say very stupid things like "please stop giving me ideas". I understand that there's going to have to be a fair bit of overlap, but as long as each group gets a vague idea of the decisions the other group is making (without all of the opaque/boring details), synchronisation should be easy enough.
    A very good point. I was planning to re-open any discussion or idea-throwing once we had even a working prototype of the game running, but telling people not to contribute isn't exactly kosher. Instead, I'll request that any ideas on how the game could/should work be posted in a separate thread from that of any discussion about the gritty inner workings of the game system. We can probably use this thread for the latter, and either use the old thread or make a new one for the former.

    Quote Originally Posted by Frost View Post
    AgentPaper, do you have a lot of experience designing and programming games, rather than just raw programming experience? If not, I'd advise you to appoint a deputy in charge of anything "non-technical". Maybe have them create a second thread.
    I have some small experience programming games, but it's hardly worth mentioning. I have more experience in designing games, though, and I have a good handle on how computers think, though, so I'd like to think I'd serve best in a managing role. That said, this is too big for one person to manage alone, so if anyone is willing to take responsibility for some part of the game or another, that would be extremely helpful.

    Example Positions:

    - Lead Systems Design: In charge of all the core systems that make the game actually run. This includes all the various Procedural elements of the game. We may also want someone specifically in charge of a few of the more complicated systems.

    - Lead Story Design: In charge of constructing the world that the players play in. If we end up using a procedural story system, then this person would be working closely with whoever is in charge of that.

    - Lead Character Design: In charge of everything to do with individual characters. This would include things like the Title system, character creation, stats, abilities, and so on.

    - Lead World Design: In charge of creating the world that the players are running around in. This would include a lot of art assets, more than any other specific role, but would also be involved in things such as procedural world creation.

    And so on.

    Quote Originally Posted by Frost View Post
    PPS: My programming language suggestion is to put it together in C++ using portable libraries. SDL for windowing, who-knows-what for networking, and nothing else has to touch the OS. libavcodec and libvorbis can give you portable music, libpng gives you game-appropriate images, OpenGL gives you 3D. For some reason the thought of writing something so programming-focused in Java feels like a death sentence.
    And this is where my area of expertise falls flat. I'm fine with the theory on programming, but not any of the real nitty-gritty details on the subject. The biggest obstacle to work getting done on this game would probably be the lack of a Lead Programmer. If someone is willing to take responsibility for this area, by all means let me know.

  20. #20

    Re: SBURB: The Game

    Quote Originally Posted by codingTornado View Post
    I do not agree AgentPaper. We DO need to decide what we are going to do in order to get coding.
    For example, it's important to have the 2D/3D discusion and reach a final desition so we can properly specify the challenges to be dealt with and run proper tests and be sure the problem IS being solved.
    My biggest fear with this project is that a lot of talk will happen and nothing will show for it. I certainly understand the importance of planning things out, but there was already a lot of that done in the previous thread, and it ended up getting us nowhere. I was encouraging people to just get working in the hopes of kick-starting the project into some real motion. Even if we spend a month writing ultimately worthless code, my hope was that it would get people thinking about the game as something that's actually happening, and thus lead to actual useful work getting done.

    Quote Originally Posted by codingTornado View Post
    Concerning the first post, I believe that SBURB had this camera rotating buttons, so as long as we can make a Sims-eske world 2D will work and be like in the comic. If we do there is the problem of the character and fights and shit. That is what leads me to think that 3D is the way to go; We can and should take some liberty when dealing with some problems if it will solve as long as the game mechanics work the same.

    If we go 2D, character and object sprites should be made for at least 6 of the 8 most simple directions, else we would be restraining to much the player in its movement. Also, fights in 3D have much more intensity than fights in isometric 2D.
    3D would solve this issues(in particular the procedural generation of items which IS critical and can't be left out) at the cost of it being harder to code. Well I don't really care it being harder if we don't have to make 6 times the same animation and all that.
    Those are some good arguments for 3d. Just the idea of gods flying around in a 3-dimensional Land of Glass and Clockwork almost makes me want to say yes to 3D, but the logistical and stylistic issues are still there. If enough people want 3d though, and more importantly enough people are willing to tackle all the additional hurdles it will add to the game development process, then by all means we'll do 3d.

    Quote Originally Posted by codingTornado View Post
    SBURB in pieces:

    * Character:
    o Stats
    o Background?
    o Appearence
    o Inventory
    o Fetch Modus? I say to hell with it and it's complicated compications
    o Strife Specibus
    * Items:
    o Alchemy
    o Database(This has to do with the server)
    o Attributes
    o Grist and costs
    * Incipisphere:
    o Worldgen:
    + Landscape
    + Consorts
    + Denizens
    o Kingdomsgen? Maybe we could give some starting internal conditios that could lead to diferent interactons in each play
    o The Veil
    * Interface:
    o Controls
    o 2D/3D
    o Quests(All that beautiful idea you have AgentPaper)
    o Battles? Should they be turn based or action RPG(I favour the later)?
    o Ingame comunication(Be it P2P or P2Consort or whatever)
    * Server:
    o Whatever the server needs I really don't know
    That's an excellent list there. I'll add that to the main post as well as a list of positions people can volunteer for. Unfortunately I've got something I can't really put off any longer so I'll have to do it later today.

  21. #21

    Re: SBURB: The Game

    I'm not sure what exactly I would be good for, as I likely have even less programming experience than you, AP, and am not a graphic designer. I suppose I could be a beta tester or something, buuuuut yeah. I'm more than willing to help, though.

  22. #22

    Re: SBURB: The Game

    All I'm going to add now is that 3D will take a considerably longer time to design for. In 2D, you can basically just draw things out and have them rerady in within 10 minutes, but 3D will take hours, the more complicated objects could take up to an entire day to make, not including all the complicated stuff needed to bring it into the game. 2D in my opinion would be a better way to go with this, because as awesome as 3D would look, I wouldn't want to be one of the people who dedicates the better part of a year to make all the required models.

    I'm not claiming to be an expert at this, but I have done basics of modeling and from seeing the effort people have to put into making this stuff on relatively easy to modify game engines, I think it would be too big of a challenge to make everything and not get tremendously bored. Also, I understand other aspects of why 3D would be better, but you're adding maybe up to a year's worth of production time, which is good for no-one.

  23. #23

    Re: SBURB: The Game

    Quote Originally Posted by Nurdock View Post
    All I'm going to add now is that 3D will take a considerably longer time to design for. In 2D, you can basically just draw things out and have them rerady in within 10 minutes, but 3D will take hours, the more complicated objects could take up to an entire day to make, not including all the complicated stuff needed to bring it into the game. 2D in my opinion would be a better way to go with this, because as awesome as 3D would look, I wouldn't want to be one of the people who dedicates the better part of a year to make all the required models.

    I'm not claiming to be an expert at this, but I have done basics of modeling and from seeing the effort people have to put into making this stuff on relatively easy to modify game engines, I think it would be too big of a challenge to make everything and not get tremendously bored. Also, I understand other aspects of why 3D would be better, but you're adding maybe up to a year's worth of production time, which is good for no-one.
    Depends on how big of a development team we have. If we've got a bunch of graphic designers, they could be working on their stuff while programmers work out the code. It could work out just as easily, depending.

  24. #24

    Re: SBURB: The Game

    Quote Originally Posted by Cute_Riolu View Post
    Quote Originally Posted by Nurdock View Post
    All I'm going to add now is that 3D will take a considerably longer time to design for. In 2D, you can basically just draw things out and have them rerady in within 10 minutes, but 3D will take hours, the more complicated objects could take up to an entire day to make, not including all the complicated stuff needed to bring it into the game. 2D in my opinion would be a better way to go with this, because as awesome as 3D would look, I wouldn't want to be one of the people who dedicates the better part of a year to make all the required models.

    I'm not claiming to be an expert at this, but I have done basics of modeling and from seeing the effort people have to put into making this stuff on relatively easy to modify game engines, I think it would be too big of a challenge to make everything and not get tremendously bored. Also, I understand other aspects of why 3D would be better, but you're adding maybe up to a year's worth of production time, which is good for no-one.
    Depends on how big of a development team we have. If we've got a bunch of graphic designers, they could be working on their stuff while programmers work out the code. It could work out just as easily, depending.
    If you hired most of the people on the forum who could model and texture then you'd probably do it within a sensible timeframe, but otherwise it would take forever, even with a base for the weapons which might cut about half an hour out of each.

    I'd also like to say again that modelers have to know how to import their stuff in-game, which usually manifests itself in extra files that give objects properties (unless you want to build the whole thing in a 3D modeling program). The team has to work together, you can't throw uncompiled models at the programmers and hope that they can do something with them.

  25. #25
    Philosopher of Truth enragedFingernail's Avatar
    Join Date
    Mar 2011
    Posts
    570

    Re: SBURB: The Game

    2D would be simpler, closer to the comic style, and have more available helpers.

Page 1 of 6 1234 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •