• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • 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] The Game Process

TBM_Christopher

TBM_Christopher

Semi-pro Game Dev
    • 448
    Posts
    14
    Years
    Hey, I figured I'd try and spark this discussion mostly out of curiosity.

    Being a student in a project-based game design program, our professors have two fairly structured timelines for game development.

    The one my degree program uses:

    • Find a team(within the first 4 weeks) and create a game concept as a team, drafting a document which lists as many planned aspects of the game as possible.
    • Present that game concept to "sell" it to the professors. (Think like a pitch at a major company)
    • Within 2 weeks, create a prototype build or "engine proof" which demonstrates that the game can be made given the tools allowed for the semester, as well as a technical design document, which provides information on the game engine's necessary features.
    • Within the next 3 weeks, create an Alpha build of the game which demonstrates that the core mechanics work properly(or can be made to work with tweaks) and that the game can be built larger with few or minimal changes to the main concept.
    • Within the following 3 weeks, create a Beta build of the game which shows most of the supporting mechanics working and clearly demonstrates that the game is fun.
    • The final 3 weeks of the semester are devoted to a cycle of testing and tweaking, offering your game to playtest and modifying it based on feedback given.


    On the other hand, the students in the art program at my school approach their game projects like so:

    • Within the first eight weeks, build a prototype which demonstrates that the game can be made given the tools given, and draft up a design document which explains what the creator envisions for this game. At the end of this milestone, the individual prototypes are displayed and teams of 4-5 form around projects they like, meaning that 3/4 of the games presented don't get past the prototype phase.
    • In a week, establish the team members' roles in the new project, and begin work.
    • Within the next 3 weeks, create a beta build which demonstrates most of the supporting mechanics and core mechanics working properly
    • The last 3 weeks once again are the testing/tweaking cycle I mentioned in the other timeline.
    Of these two timelines, which do you believe is preferable? I can see the merits of establishing a team before the game concept has been fully fleshed out, but at the same time, having an eight-weeks-done prototype means that the game pitched at that point has made a LOT of progress, and then only the best of those students' games continue from there.


    Times aside, given that we have as long as interest holds on our projects on this forum, what sort of process do you use in creating a game? Do you opt for a prototype before recruiting new team members, or do you prefer to get a team before showing your plans to the world?
     
    Well, this can be quite tricky... I've been involved in MANY projects with the goals varying drastically.

    The problem with acquiring a team first can be that you need to be able to instill the projects goal into there brain 100%. They only know what you have told them about the goal.

    To get a working type first, then look for a team is probably the way to go. Due to the fact people would rather see that you're willing to put out some work and not just be a "dreamer".

    Also, I see you're referring to _weeks_ allot... That's kinda an understatement depending on project specifics.
     
    Koran said:
    To get a working type first, then look for a team is probably the way to go. Due to the fact people would rather see that you're willing to put out some work and not just be a "dreamer".
    Click to expand...
    I've also thought the same way, as I'm more of a results-based kind of person. (Which is why for my first semester, I was reluctant to form a team immediately) But on the other hand, I managed to meet two great teammates and we had fantastic results given the allotted time.

    Another consideration is possibly build a small team of 1-3 that share your vision and then recruit after the prototype is done, so that you can expand your workforce without straying from the goal.
    Koran said:
    Also, I see you're referring to _weeks_ allot... That's kinda an understatement depending on project specifics.
    Click to expand...
    Well, I'm referring to weeks primarily because with our project-based curriculum, we have to produce a "finished" game by the end of the semester. As I mentioned, this is different than the timeframe at PC, as here we have as long as interest holds on our projects.
     
    In that setting, out of those two options, I think I'd prefer the first one (team first, build build build). It's more productive that way, and a game can be developed more by multiple people working on it from the start.

    The second option limits how a game can progress due to being started by just one person. There's not much room to change things afterwards, since by the time other people come along with their (possibly better) approaches, you're over halfway through your allotted time. The presentations are no more than an extended brainstorming-and-team-gathering session that the first option's teams will get done much more quickly. There's also the fact that 75% of the students will end up being forced to abandon the project they've worked for 2 months on, which won't cause good feelings. There's also less opportunity in the second option to make sure the teams are built well - quite aside from the lack of time, projects will gain people based on the project rather than the team members, which means the people could very well not get on, which is obviously bad all round.

    Just as I'd expect from artsy people. They don't think things through.



    Now, let's get more generalised.

    Out here, there isn't a demand that a game has to be made, and there's no expectation that a game will be worked on and succeed, and there's no guarantee of teams forming and help being provided, so the rules are different.

    For game projects here, I would say the best approach is to start something yourself, and gather people along the way to help you. No one's being forced into a project, so you'll only get people who actually want to be there. It's a fact that getting ideas is easy - everyone has a novel in them, etc. etc - so the important thing is to be dedicated, productive and to show progress. You need to attract team members by playing on their desire to be a part of something that gets made, not by getting their imagination going (although that does help). You need to prove to others that your project is actually going somewhere, which means you need to show it going (via screenshots, videos, plans, demos, whatever). If all you have is a two-paragraph plot about saving the world, you're not going to get any help, because everyone can come up with their own idea that they'd rather work on, or at least find a better project to join instead.

    Besides, productivity isn't linear. You can't have a status report every week and show off some new flashy thing each time. In one week you may have added half a dozen important menus, while in the next you may have fixed a lot of bugs which don't sound interesting but just needed to be done. If you announce a game right at the start, progress reports are going to be unsteady at best, and that will put people off if they're naive and expect big new things consistently (which most people do). in their mind, if you've worked for two weeks but don't have something fancy to show off by the end of it, they're going to wonder what you were actually doing and start to think your dedication is wavering (which can only mean that the game isn't that good). That's why you should hold off until you get at least something done, and preferably until you get to a stage where you know you'll get consistent flashy updates (e.g. new maps).

    So yes, in the real world (or at least, in the Game Dev section), the second option OP mentioned is closer to reality. However, reality and OP's game designing course are two different things. Working for a gaming studio is a third different thing, and I have no experience of that so I can't comment on it.
     
    I would have to agree, the first method would be allot better. Generally, it's better to have at least someone who can look over code for you. It's kinda like proof reading a program, because we all do those stupid mistakes sometimes (Wrong imports, etc).

    I'm more of a realist, while the first method is better, it's just not realistic approach.

    Also, there's this lovely source management program called GIT.
    So, if there was an obviously better way to do something, someone could submit a patch for it.
     
    I personally like to do all the coding myself, but something that I lack is man power for compiling info and such, debuggers looking for issues as I code and what not. And ALWAYS get people you can trust with your work, especially if it is something that could be leaked.
     
    The first method is the one I've seen people do the most in real life. Especially the pitch bit. It's different here though, because we don't run on funding of any kind, although one could say that the support of other people is what an idea post (which could be considered a sort of pitch) is really meant to accomplish here.
     
    Maruno said:
    In that setting, out of those two options, I think I'd prefer the first one (team first, build build build). It's more productive that way, and a game can be developed more by multiple people working on it from the start.

    The second option limits how a game can progress due to being started by just one person. There's not much room to change things afterwards, since by the time other people come along with their (possibly better) approaches, you're over halfway through your allotted time. The presentations are no more than an extended brainstorming-and-team-gathering session that the first option's teams will get done much more quickly. There's also the fact that 75% of the students will end up being forced to abandon the project they've worked for 2 months on, which won't cause good feelings. There's also less opportunity in the second option to make sure the teams are built well - quite aside from the lack of time, projects will gain people based on the project rather than the team members, which means the people could very well not get on, which is obviously bad all round.

    Just as I'd expect from artsy people. They don't think things through.



    Now, let's get more generalised.

    Out here, there isn't a demand that a game has to be made, and there's no expectation that a game will be worked on and succeed, and there's no guarantee of teams forming and help being provided, so the rules are different.

    For game projects here, I would say the best approach is to start something yourself, and gather people along the way to help you. No one's being forced into a project, so you'll only get people who actually want to be there. It's a fact that getting ideas is easy - everyone has a novel in them, etc. etc - so the important thing is to be dedicated, productive and to show progress. You need to attract team members by playing on their desire to be a part of something that gets made, not by getting their imagination going (although that does help). You need to prove to others that your project is actually going somewhere, which means you need to show it going (via screenshots, videos, plans, demos, whatever). If all you have is a two-paragraph plot about saving the world, you're not going to get any help, because everyone can come up with their own idea that they'd rather work on, or at least find a better project to join instead.

    Besides, productivity isn't linear. You can't have a status report every week and show off some new flashy thing each time. In one week you may have added half a dozen important menus, while in the next you may have fixed a lot of bugs which don't sound interesting but just needed to be done. If you announce a game right at the start, progress reports are going to be unsteady at best, and that will put people off if they're naive and expect big new things consistently (which most people do). in their mind, if you've worked for two weeks but don't have something fancy to show off by the end of it, they're going to wonder what you were actually doing and start to think your dedication is wavering (which can only mean that the game isn't that good). That's why you should hold off until you get at least something done, and preferably until you get to a stage where you know you'll get consistent flashy updates (e.g. new maps).

    So yes, in the real world (or at least, in the Game Dev section), the second option OP mentioned is closer to reality. However, reality and OP's game designing course are two different things. Working for a gaming studio is a third different thing, and I have no experience of that so I can't comment on it.
    Click to expand...
    I'm definitely glad to be in the Bachelor of Science in Game Design program – As you noted, there are some inherent issues with the BAGDs' game classes. While it is definitely important to recruit team members who are enthusiastic about the project, if they weren't around for its inception, it can be difficult to convince them that your project is more worthwhile than their own. Additionally, having multiple people from the start of a project usually means a wider range of skills are available to the team as a whole. If a single person has to do everything for the engine proof(even using "programmer art" like stick figures or blocks), less can get done before presentations to fellow classmates, so interest may wane.

    I agree wholeheartedly on the method you outlined for starting a game project here – it takes nothing to spout out your latest and greatest idea, and for a long time I fell for that fallacy in my ideas to pitch a game and hoped that attention could gather and a team would snowball. Now, no matter what the project is, before I show it to the public, I try to make sure there's a significant amount of progress shown that will concisely demonstrate what my vision is and why my project needs help over any other.

    Your observations on productivity are pretty much my views entirely. It hurts that game development isn't consistently glamorous, but at the same time, core functionality(such as a working program) has to take priority over polish(such as a flashy new feature, which may destabilize the core functionality in the first place). When it comes to updates, I'd like to say that I prefer to update on milestones that the audience can appreciate. It looks inconsistent to someone observing from outside the developer's standpoint, but at the same time indicates where the game has progressed in a way that I favor over vague things like a random percentage value assigned to a task.

    As an aside, that's one of the things I dislike most in the development process – you can't assign numeric values to tasks like that as they usually mean next to nothing anyhow. Instead of describing three maps as 0%, 40%. and 100% done, for instance, I would much rather see it described as 1 out of 3 maps completed, as in the words of one of my professors, "If you can't show it, it doesn't exist – as far as I'm concerned 90% done means 0% done if I can't see it."

    One of the main reasons that the second method reflects the Game Dev section is that the thread requirements demand actual proof that the game can be done. In that sense, it's forcing a potential poster to provide what isn't necessarily an engine proof, but definitely evidence that, if the project were to go unposted in the forums, it would still keep moving forward. It requires a level of commitment from the poster which keeps the forum from looking like an expanded version of the Idea Thread.

    I definitely agree, reality and my degree program are immensely different, but at DigiPen, the intended result of the programs are as close to emulation of a professional setting as possible for a college, and having talked with my professors who are presently in the industry, it's a pretty close approximation. That isn't to say that DigiPen's courses aren't different from the Game Dev section, but it's a whole different game here as it's a non-profit hobbyist environment compared to a professional one.


    Koran said:
    I would have to agree, the first method would be allot better. Generally, it's better to have at least someone who can look over code for you. It's kinda like proof reading a program, because we all do those stupid mistakes sometimes (Wrong imports, etc).

    I'm more of a realist, while the first method is better, it's just not realistic approach.

    Also, there's this lovely source management program called GIT.
    So, if there was an obviously better way to do something, someone could submit a patch for it.
    Click to expand...

    Getting someone to look over your shoulder is always a great way to keep a program bug-free. Often my classmates and I practice "tag-team" coding where one person codes while the other watches, and while coding, the two will discuss what needs to be done to achieve the desired result, so that two people's ideas are being thrown into the mix and the program refined as necessary.

    Forming a team initially can be helpful, but as you said, often it's not a realistic approach. Team members come and go, and in those early stages of development when a project has yet to take a cohesive form, it can be difficult to find people who share your vision. As a compromise, maybe it's best to find people who can at least communicate the intentions of the project to form a team, and then recruit people as they come to understand that envisioned project.

    Unfortunately, I have not had any experience with GIT, I can't say anything one way or another, but having a means of allowing others to look over what you've done is invaluable for any project. My team uses DigiPen's Subversion server and version control software so that we can work on files individually and submit them to the server for review by teammates, and believe me, it's helped a ton.
    kudoms said:
    I personally like to do all the coding myself, but something that I lack is man power for compiling info and such, debuggers looking for issues as I code and what not. And ALWAYS get people you can trust with your work, especially if it is something that could be leaked.
    Click to expand...

    Firstly, I'd like to mention that it's admirable to prefer to do the coding yourself; a lot of people I've known will attempt to start a game using a robust tool like RPG Maker and then complain when they hit a portion of their game where they have to code something instead of having an easy graphical tool to do so.

    A lack of manpower is indeed a significant issue, but at the same time I sometimes feel as though a Beginners' Showcase thread that I've seen has been overscoped to generate hype and attract new team members; This is probably not deliberate, but by making large promises that the game's lead cannot keep by themselves, such a game is put at risk even before development can occur.

    Getting people who you can trust is unbelievably important - for this semester's project, my team consists of a Product Manager, a Tech Lead, a Lead Designer, and a Producer. I signed on as the Product Manager, a good friend of mine signed on as Producer, and together we recruited a Tech Lead and a Lead Designer. While all of us are supposed to make a significant contribution to the game's code, the Tech Lead is supposed to be the one who manages the code overall, including reading over everything written and ensuring the code works as a cohesive whole. However, my friend, the Producer, is one of those with a more controlling(or pedantic if you want) personality, so after a team meeting this Friday, all of our roles got shuffled; I went from Product Manager to Producer, he went from Producer to Tech Lead, and our Tech Lead became Product Manager. Long story short, our former Producer couldn't do the duties his role demanded, and was more suited to the duties of the Tech Lead. Friends can sometimes make awful teammates, as this project has shown, and sometimes we don't know where our talents lie.


    audinowho said:
    The first method is the one I've seen people do the most in real life. Especially the pitch bit. It's different here though, because we don't run on funding of any kind, although one could say that the support of other people is what an idea post (which could be considered a sort of pitch) is really meant to accomplish here.
    Click to expand...

    That's one comparison I've actually been thinking about - While in a professional, for-profit environment, funding is literal money, in a non-profit, hobbyist environment like here, we have our own sort of funding - the attention and support of fellow forum users.
     
    *whistles*
    DigiPen, eh? Hardcore. Well, it is most certainly interesting hearing the principles and methods that trade school teaches by. I'm sure there's much that this community would benefit from in its teachings. It makes me glad that some Pokemon fans among us decided to carry over their interest to pursue the craft behind the wonders that inspired them to begin with. Make a real Pokemon game, will you? ;>

    ...oops, that's a different topic. Now I'd like to say that when it comes to software design in general, it's a well-known issue that software design is hard to track, with a very vague "solution" condition. 90% syndrome, the "wicked problem", etc. etc. It's a subject of its own to deal with that kind of problem. I've observed that people really seem to like 'agile' around here irl. That being said, subversion, or /some kind of version control/ is really helpful for minimizing mistakes. Subversion is nice, although I tend to lean on the side of Git too, using it mostly for backup (Game project or not). In a nutshell, people tend to like it better than subversion because backing up your changes to a repository is treated as a different action from imposing your changes on other people, and it (sort of) works offline. Some fangames I've seen use it. Pokemon Online (the battle sim) is open source on github actually (which is awesome).

    I kind of think overscoping and hyping is... inevitable here. XD If anything, bringing that to light and learning to get a grip on the proper points through that kind of failure leads to good experience. Not everyone is at the same level in an online community. There's some times when I thought a project was overscoped, but whoever was doing it would prove me wrong by his or her own tenacity. At that point it became a case of proof-of-concept and there's less reluctance against jumping on. That being said, it does seem like a good idea for people to slowly let others in as the time comes. If they want anyone at all, that is...

    Some games have had just one dev here and they've got the consistency of vision and quirk reminiscient of a single-author book. Lol, SPEE...
     
    audinowho said:
    *whistles*
    DigiPen, eh? Hardcore. Well, it is most certainly interesting hearing the principles and methods that trade school teaches by. I'm sure there's much that this community would benefit from in its teachings. It makes me glad that some Pokemon fans among us decided to carry over their interest to pursue the craft behind the wonders that inspired them to begin with. Make a real Pokemon game, will you? ;>
    Click to expand...

    Hardcore is right - I came to Redmond right out of high school, so it's twice as hard for me as it is for others enrolled at DigiPen. I'm glad that you think what I've been studying could be beneficial here - It's actually one of the reasons I decided to come back after such a long absence. In fact, the Game Development forum here is probably one of the biggest factors in my decision to pursue a career in game development; It was amazing to a 9-year-old Christopher what people could do with a tool like RPG Maker, and I wanted to take even that a step further, so I went from RPG Maker to VisualBASIC to Javascript to C and C++, learning everything I could on my own until I found out about DigiPen. Most of the students are even farther along that I am in this journey, so at times it can be overwhelming, but I simply can't give up - I've come too far not to.


    audinowho said:
    ...oops, that's a different topic. Now I'd like to say that when it comes to software design in general, it's a well-known issue that software design is hard to track, with a very vague "solution" condition. 90% syndrome, the "wicked problem", etc. etc. It's a subject of its own to deal with that kind of problem. I've observed that people really seem to like 'agile' around here irl. That being said, subversion, or /some kind of version control/ is really helpful for minimizing mistakes. Subversion is nice, although I tend to lean on the side of Git too, using it mostly for backup (Game project or not). In a nutshell, people tend to like it better than subversion because backing up your changes to a repository is treated as a different action from imposing your changes on other people, and it (sort of) works offline. Some fangames I've seen use it. Pokemon Online (the battle sim) is open source on github actually (which is awesome).
    Click to expand...

    That problem is one that a lot of DigiPen students suffer from when they're starting out here. Of course, when they get demoted points for this vagueness during presentations, the habit dies fast! :P

    I've looked into alternatives to Subversion quite often, actually. My first semester project was actually built using a shared Dropbox folder, as DigiPen's Subversion servers were not friendly to the program we were required to use, "ProjectFUN" (The world FUN is capitalized because otherwise you'd forget how FUN it is. And FUN is mandatory!). Of course, there are alternatives which can be even worse than Dropbox. Coming to mind immediately is communication solely by e-mail or the dreaded "sneakernet" where your version control is a guy running around with a flash drive.


    audinowho said:
    I kind of think overscoping and hyping is... inevitable here. XD If anything, bringing that to light and learning to get a grip on the proper points through that kind of failure leads to good experience. Not everyone is at the same level in an online community. There's some times when I thought a project was overscoped, but whoever was doing it would prove me wrong by his or her own tenacity. At that point it became a case of proof-of-concept and there's less reluctance against jumping on. That being said, it does seem like a good idea for people to slowly let others in as the time comes. If they want anyone at all, that is...
    Click to expand...

    While it is somewhat inevitable, I'd like to say that those more grandiose features should be chalked up as "Stretch Goals" - something to work towards if everything else is in working order. It's helpful sometimes to fly too close to the sun, and learn from those mistakes. It's important to know your own limits, and not to hold yourself to standards you can't hope to achieve in a project(or to someone else's standards if you're on two very different levels of skill). I love that moment when a team I thought had overscoped turns everything around and shows that they were more than capable of accomplishing their goals. That determination is something I take note of for people to work with in the future here.


    audinowho said:
    Some games have had just one dev here and they've got the consistency of vision and quirk reminiscient of a single-author book. Lol, SPEE...
    Click to expand...

    I find those single-dev games impressive if they accomplish what they set out to do, though I also know that often it's not quite feasible. I personally prefer to work as a team, but all too often I've learned that the only person you can hold 100% accountable is yourself.
     
    I think to start with you need a strong vision you can sell to team members and backers to get them excited. Then proof of tech as soon as possible, like minimum viable product, which is playable and demonstrates the key features. The longer it takes to get to this first stage the harder it will be.

    Once you have the minimum viable product then you iterate on it. The game should always be in a playable state but you keep moving it small step by small step to the finished game you want.

    For small teams this is the best way and I've succesfully made plenty of games doing this. Short iterations keep peoples enthusiasm and interest high, long iterations kill their passion and faith the project will get completed.
     
    You must log in or register to reply here.
    Back
    Top