• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Which Pokémon Masters protagonist do you like most? Let us know by casting a vote in our Masters favorite protagonist poll here!
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

[Discussion] Where to start on a game?

Whitney's Shaymin

Creator Of Pokemon Grace
    • 596
    Posts
    13
    Years
    Hey Pokecommunity, I'm Whitney's Shaymin (or as other's know me as pokemoner2500) and as some know i've had a few games that have gone into beta but have really haven't gotten well, anywhere. I'm wondering where someone should start on a game. Should it be maps, or characters, tell me please.
     
    In most Console/Handheld Game Companies, it goes like this.

    CONCEPTION:
    1. Gather a group of people in the company you work in, and assign roles (Programmer, Designer, Artist, etc.) to each person.
    2. Get an idea together.
    3. Give your Team tasks: Designers write a Game Design Document, Programmers build a Framework, Artists draw Concept Art in 2D, and Producers make a Schedule, Budget Plan, etc.
    4. A Designer turns most of this stuff into a Pitch, and go to their Supervisors and/or Publishers (if any). They will give you a Red, Yellow, or Green Light. Red means "NO!", Yellow means "Yes, but change a few stuff", and Green means "Yes".

    ALPHA:
    5. Now the Programmers try to complete a feature-complete build before Beta, Artists help making the necessary Art (2D and/or 3D), Composers make the necessary sound, and Designers think of how the final product should look and feel like.
    6. Show it to the Supervisors and/or Publishers (if any), which will yet again serve you with one of the 3 coloured lights.
    It's always a good idea to let your Team test this build before going to Supervisors/Publishers.

    BETA:
    7. Programmers add any new features to turn it into a complete game, Artists and Composers complete all their Assets, and Designers take the final decisions.
    8. As soon as the game got completed, let QA Testers go through the game over 9000 times, make them catch as many Bugs as possible, and let them tell you what they think of your game.

    RC:
    9. Appoint all the required legal stuff with the Console Makers (Age Ratings, Contracts, Translations, Guidelines, Tests, etc.), and submit the game to the Console Makers (or Publishers, if you're not self-Publishing).
    10. Make sure you wake up the Press by announcing it.

    ---------------------

    As for the fan games, you should better ask the other people here instead.
     
    Here is a guide to help you get started with Game Development.

    As for where you want to start your project, such as mapping, scripting, etc/ That depends on your skills and how you want to go about it yourself.

    In the world of design, you have people who work better top down and some who work better from the bottom up. I touch on this a bit in my short bit about World Building.

    I should probably update that guide with some new links and pieces at some point, a project I would not mind working on again.
     
    I'd recommend working on what's called a Game Design Document. In a professional environment, the GDD outlines exactly what you want out of a game:

    1. High concept(a quick sentence summing it up; in most cases on PC, it'd go something like "Pokemon ____ is a top-down, turn based 2D RPG revolving around capturing and battling Pokemon")
    2. Summary(how you plan on releasing it, touching lightly on the plot, and how long you intend gameplay to last for the average player. You don't need to know this, but sometimes it's nice to have an idea of it)
    3. the overall game story(I split this into a general overview which talks about the overarching plot, then write the rest in smaller chunks, based on key plot events. For AWAKE, there's an obvious cutoff for each episode, so that's usually where I'll split the Story section)
    4. Game Flow(There are a bunch of ways to do this - I usually split it based on game screens. In the case of a Pokemon game, I'd spend half of the section describing overworld gameplay and the other half describing battle gameplay. Game Flow should generally incorporate a start-to-end experience. This generally means, in the case of a Pokemon game, describing the sort of power levels you expect Pokemon to have at different key points of the game)
    5. Game Mechanics(Hoo boy, how to describe this? Well, since a Pokemon game traditionally has a bunch of in-depth mechanics, I'd say you don't need to do much here. Maybe list the mechanics that you plan on changing? Personally, with the prototype I've got stowed away somewhere, I threw out IVs entirely since they weren't needed and made the game a lot more complicated than necessary)
    6. Characters(This is pretty self-explanatory. You have your protagonists, your antagonists, and your supporting cast.)
    7. Game Resources(In this case think the Pokemon, Items, Moves, and HMs. Depending on what your supporting characters do, you could also mention them here)
    8. Game Environment(The setting of your game, as well as a bit about your graphical look. What's your region like? Are you going for a look similar to a particular generation of games, or something entirely new?)
    9. Multiplayer Design(This one's a tricky one - odds are you won't want to work on multiplayer design; it's complicated and tedious to balance. However, if you plan to do any sort of multiplayer functionality, mention it here.)
    Now the main point of the GDD isn't to commit to anything - if it doesn't work, throw it out! It's not set in stone. The point of the GDD is so that you have a comprehensive list of everything you've thought about when it comes to this game. Also remember that the GDD isn't really meant for your audience. It's meant for you(and your team) to understand and use as a guide while working. Finally, the GDD is only as useful as you try to make it. If you slop it together without caring, it's going to be useless. If you keep it well-maintained, you'll have a relatively organized list of things your game needs done.
     
    Java's Missingno. said:
    The point of the GDD is so that you have a comprehensive list of everything you've thought about when it comes to this game.
    Click to expand...
    This includes ideas you've rejected. It's useful to keep a list of those, along with reasons why you decided against them, so that you don't keep thinking up the same ideas again and again. It also means that, if you want to revisit an idea, you know immediately why you originally rejected it and what you were originally envisaging for it.
     
    I call my GDD a style guide, which is another term for it.

    Inside of it, I also keep track of the visual style I want and I change it accordingly. I keep a visual document which is a PSD file, where I will stockpile mocks and store it in a folder with current style resources to build off of. This works well in conjunction with notes to create fluidity and a uniform feel to the visual aspects.

    I think a GDD or Style Guide is generally what more advanced developers will do and I think it can be pretty overwhelming for a new player to try to tackle it alongside a project.

    I would focus on trying to get a project under development and find some level of devotion to it before even bothering with the implementation of a GDD or Style Guide.
     
    ЩѻƦḽᶑʂḽдƴƹƦ™ said:
    I think a GDD or Style Guide is generally what more advanced developers will do and I think it can be pretty overwhelming for a new player to try to tackle it alongside a project.

    I would focus on trying to get a project under development and find some level of devotion to it before even bothering with the implementation of a GDD or Style Guide.
    Click to expand...

    Focusing on getting the project underway prior to beginning a GDD is also a valid method; personally I've found that I prefer to start with the GDD, but a lot of students at DigiPen like to start by making rough prototypes of gameplay ideas which then begin to develop and later require the creation of a game design document. The main reason I think this works for our game project classes is because we have to start from near-scratch and come up with suitable gameplay and mechanics for a wide variety of games and scopes(a JRPG like Pokemon, for instance, is a poor choice for our game projects because our grader will likely spend 1-2 hours on a game at most). With a clear-cut template like Pokemon Essentials to start out with, it can probably go either way - it all depends on how you work best. It's more of an art than a science; find the workflow that suits your needs and organizational style and go from there.
     
    Most fan game developers, especially in the Pokemon world, do not ave the discipline to handle something like a GDD or Style Guide as well as a project launch, I think at some point, you need to level with people wanting to begin a project. Glorifying the level of ease with something like a GDD is a bit misleading to the average person.
     
    Well, GDDs aren't really required, but it's always handy to have one, especially if you're working on a Project that's not Pokémon (something with a USP), you go on a holiday to a different country, lay down on the beach there for 10 days, arrive back, and totally forgot where you were working on, what you were supposed to do, etc.

    Also, when working in a Team, it's also a good idea to have a Google Spreadsheet on Google Drive, with all the stuff you have to do.
    If you're done with something, don't delete it from your TODO List, just mark it as done, it's always handy for future references (Interviews, Changelogs, whatever).
     
    ЩѻƦḽᶑʂḽдƴƹƦ™ said:
    Most fan game developers, especially in the Pokemon world, do not ave the discipline to handle something like a GDD or Style Guide as well as a project launch, I think at some point, you need to level with people wanting to begin a project. Glorifying the level of ease with something like a GDD is a bit misleading to the average person.
    Click to expand...

    I wouldn't say that I'm glorifying the ease of a project with a GDD. I'm just suggesting it as it's a way that has helped me consistently. Your mileage will vary on this - a lot of professional companies skip it entirely, but I personally have never found a GDD to be wasted effort, even in fangame projects.

    MKGirlism said:
    Well, GDDs aren't really required, but it's always handy to have one, especially if you're working on a Project that's not Pokémon (something with a USP), you go on a holiday to a different country, lay down on the beach there for 10 days, arrive back, and totally forgot where you were working on, what you were supposed to do, etc.
    Click to expand...

    This is the angle I was coming from. A lot of fangames will likely go on hiatus due to the fact that they're simply a hobby - other stuff will likely come up that has to be dealt with first, and so having an organizational tool of any sort will allow you to hopefully go back into your project more smoothly.

    MKGirlism said:
    Also, when working in a Team, it's also a good idea to have a Google Spreadsheet on Google Drive, with all the stuff you have to do.
    If you're done with something, don't delete it from your TODO List, just mark it as done, it's always handy for future references (Interviews, Changelogs, whatever).
    Click to expand...

    I hadn't ever considered that, actually. I think I'll probably try to make a habit of not deleting things out of my Trello lists in the future.
     
    The first thing is planning. As I wrote in my guide, try to think (almost) all places in the game, the main features of each one, the bosses (yes, I am talking about a pokémon game) and some interesting ideas that you have. Write these things (even only few words for every idea), or do other measures don't forget these things. A GDD may be too advanced for people there, but if you have a team with a good experience level, you may try.

    I particularly use a big TODO list. I describle the features in few words (that is enough for me remember after years), except the most complex ones. Current my TODO list has more than 400 lines only with new features.

    MKGirlism said:
    Well, GDDs aren't really required, but it's always handy to have one, especially if you're working on a Project that's not Pokémon (something with a USP), you go on a holiday to a different country, lay down on the beach there for 10 days, arrive back, and totally forgot where you were working on, what you were supposed to do, etc.
    Click to expand...
    10 days aren't a huge time, so a reminder is enough. For a bigger time gap a TODO list should be enogh.
     
    Still, a TODO List alone is no guarantee you will know what to do, for as long as the Project is still going on.
     
    Maps would be a nice place to start. Add towns and routes next. Then decoration. Then Pokemon and the Characters
     
    You must log in or register to reply here.
    Back
    Top