Thread: [Discussion] The Game Process
View Single Post
  #8    
Old March 3rd, 2013 (02:52 PM).
Java's Missingno.'s Avatar
Java's Missingno.
Notoriously Overscoped
 
Join Date: Jan 2010
Location: Lincoln, NE
Age: 20
Gender: Male
Nature: Quiet
Quote originally posted by Maruno:
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'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.


Quote originally posted by Koran:
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.


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.


Quote originally posted by kudoms:
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.
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.


Quote originally posted by audinowho:
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.
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.
__________________

Currently working on UNITE. Will create a thread when a playable demo is out.
Reply With Quote