|
Let's Team Up to Game On!
|
|
Posted on 6 September 1998
The following text was written by Alan
Wong: In my last article, What Makes a Good
Game, I made several suggestions to improving the games made for TI graphing
calculators. One of those that got people angry was that of the engine idea. Although some
people liked the idea, many others opposed it, due to its non flexibility and lack of
feasibility. But here's an interesting note on that idea, the ones that liked it the most
were mostly the ones that could not program, and the ones that opposed it were mostly the
ones that could program. But this article is not about engines. Its not about fun. Its not
even about replay value. If you do not know what this article is about, then I suggest that
you read the title once more. This article is about the one idea that I barely touched on,
but most of the people liked. It is the concept of team. In the responses of my last
article, nearly everyone liked this idea, and in my opinion, most poeple think it is the
next logical step in the world of TI calculator gaming. But are there downsides to what
seems like the best way to go? And what does it take to bring a team of programmers and
artists together to make a game? Read on for my opinion of the issue. First of all,
the team approach does not guarantee good games that are fun. They just give us more chances
to see good games that are really good. A team is also not made up of 10 full time
programmers and artists. In this small world of TI calculators, a team of 3 is about the
right number, but any where from 2 to less than 10 people is good. I would prefer 3 people
if I had a choice, since you have 2 programmers that can help each other and a full time
artist making what the programmers need, or the other way around. This team is also easy to
manage, since there are only 3 people, and basically all of them have to do the work for it
to be successful. If you have too many people, some will slack off and still take credit. If
you have less, then it may be a fuller load of work for both of you. Anyway, let us look at
more of the good sides of the team approach. You finish games quicker than if one person
were working on it, since you have, well, more people working on it. This is a plus if you
do not want to be bored by the same game for months on end, since your finished in a couple
months if you have great partners. Also, you can share ideas and skills. If its a small
group, then maybe the programmers can teach the artists, and the artists can teach the
programmers, then each can have a better understanding and respect toward whatever they do.
Plus, they learn something new that they may have had to slave over for a long time if they
did not get the lesson (but there are exceptions to this!). Anyway, this could also increase
the amount of games that appeal to more people, since you have more than 1 person's opinion
going into the game. This is all very positive, but when you have the good on something, you
also have the bad. The most obvious negitive to the teams approach is that you have
different people in the team. Even if you knew each other for a long time, you still have
your differences. These differences get increased when each member wants to do something
differently, and argument breaks loose. But this can be worked around by including
everything (which is a bad idea to start with) or by knowing ahead of time that this is
going to happen and plan a plan. Second, when you have a team, you have to manage it
somehow. One person does this and that person does this and you do that. This is hard to do
though, since in real life, people have different and varying schedules. You must compensate
for this, and make sure you can cover for that person to get the game out on time. And what
if someone just does not have the time? Well, that person should not have joined in the
first place. This sounds harsh, but it has to be done. Even if that programmer is the best
in the world, just quiting (except for extraordinary reasons. which should be created prior
to the team being built) is not good, and really gives the rest of the team (or that one
remaining person) a lot more to do. This could cause the game to be rushed (the "who cares,
just get it done" phase). There are more bad things I could say, but we all know these do
not happen everyday, and those that actually have the motivation will get it done no matter
what (almost). Well, we have the programmers and the artists. These guys are the
most important in the TI calculator game world (sorry music guys), but some other people
that we may not think of as part of the team are part of the team. These are the testers.
They have the tedious job of playing the game a million times and tell the programmers (or
artists) whats wrong with the game. Sometimes, having a lot of these guys helps, since bugs
can come in the strangest of places. The more people that test (full time, not just 10
minutes a day) the more chances you the programmer can find and fix a bug. A 3D shooter that
is now being made for the TI-86 has a large testing team, and I believe this will quicken
the development time by shortening the testing phase, and also have the luxury of testing as
they program, not test all at once in the end. This could also get rid of the need of betas,
which I never download by the way. Finally, this team has got to work together.
Everyone that is in the team, no matter how trivial the task they are made to do must work
together. If this does not work, the team will not work. If the team will not work, the game
will be doomed to be one of the millions of never released but promising games. Oh,
and to the maintainer of the site, could you make a new little page that allows us to post
information on gaming ideas for the TI calculators, and ask for programmers and artists?
This could allow us to better get in touch with each other, allowing teams to form, and
games to be made. The new game ideas list: - Pinball (suggested in a comment
on my previous article, but physics may be hard to do but would be similar to Vertigo)
- Warcraft, Starcraft, Diablo, Command and Conquer type game
- Street Fighter type games
- Zelda overhead type adventure games
- 2-player linked games (card games, puzzles,
etc.)
So far, I believe teams are the way to go. And to all you game makers
in the TI world, keep up the good work!!
|
|
|
Reply to this item
|
|
Re: Article: "Let''s Team Up to Game On!"
|
Killer2
(Web Page)
|
|
I have thought about creating Diablo for the 89. It is not all that impossible, with the 89's memory. It would, of course have to have link play, maybe even with 4 players (2 to each calc) to be truely an awesome game. While I have seen CnC RTS-type games on the calc, I think that they would be totally useless without the link play. Personally, I would maybe _try_ to beat the game in single player mode, enivitably failing, and deleting it off my calc, unless possibly to play it against one of my good friends.
I can tell you one thing: There will not be a single game of mine that will not use the link port.
-Miles Raymond
|
|
Reply to this comment
|
27 June 1999, 06:11 GMT
|
|
|
Re: Let's Team Up to Game On!
|
James Hu 
|
|
I was thinking that Starcraft might be a good idea, it's just that we will need to learn assembly code to make it work efficiently. I am working on a beta version right now, so anyone want to help, just email me.
|
|
Reply to this comment
|
6 May 2010, 01:22 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
John "Cryect" Rittenhouse
(Web Page)
|
|
I agree with you. Teams aren't always a good idea. You need a good project leader else nothing will be coordinated a good example of a good team would be my Q2 mod WF Reno Brothers and me join together are mods to make a new mod that people would like even more. It was kinda nice when it was the 3 of us but popularity has a price mainly in lots of email. I have had taken a lot of time answer emails(Thats good! But sometimes I get behind =-( .) I'm currently working on a Zelda type game(just started yesterday) and I need a couple of people to help mainly a programmer and a artist(believe me my sprites suck). If you wish to know more contact me. Here is some of my webpages if you wish to get to know me a little more. http://www.captured.com/weaponsfactory/ http://www.captured.com/startc/ http://www.planetquake.com/qdevels/ http://www.ritualistic.com/urban/
and some others I don't feel like listing
John "Cryect" RIttenhouse
cryect@captured.com
cryect@planetquake.com
cryect@ritualistic.com
|
|
Reply to this comment
|
6 September 1998, 03:08 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
Matt
(Web Page)
|
|
I think Teams are a great idea, although I don't call them "teams". I call them "Groups". So that's what I'll call them. In groups you can have talented people working on one project together, so you can have a crappy artistic-lacking programmer and a great artists that doesn't know what the heck programming is, and they can make an AWESOME game! Another good thing about groups is that you can learn from other programmers, just think if Bill Nagel needed some help with a program (Yeah, Right), but anyway, and you were on his team, you'd learn a great deal of stuff...so that's what I think about "teams"...Check out my page above...
|
|
Reply to this comment
|
6 September 1998, 04:07 GMT
|
|
|
Teams / Zelda
|
Harper Maddox
(Web Page)
|
|
I call 'em teams. I like the idea of teams, since there are certain gaps that every programmer, yes every programmer, needs to overcome. But the teams should be made up of people with the same abilities. If a good programmer and one not as good started working on a game, then the better programmer would do 90% of the work, and spend the same amount of time explaining to his partner how he coded what he did. This is not a good team situation. Teams help *both* parties.
About Zelda... as some of you may know, im responsible for a pretty good game, Legend of Zelda for Ashell 83. Since this program is only a demo it needs to be completed, but quite frankly I don't have the time or motivation anymore. So, if anyone wants to finish zelda (not just play with the source) please send me an email with your "application" Please only serious replies!!! I do not want a bunch of newbies asking me for source. I am not going to answer any questions about it, so you better know what you are doing in asm. and most of all have a good amount of free time to program it.
|
|
Reply to this comment
|
6 September 1998, 06:50 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
Master Nick
(Web Page)
|
|
I don't like the idea of working in teams. I, personally like to work be myself on a project. If I do anything on a team it always seams to take longer to get it done. I also think that games written by a single person are usually better than team games. The same goes for applications. The only way I would work on anything in a team would be with an artist. I can't draw, I program, so if I need artwork for my program, I'll team up with an artist. This is better than teaming up with other programmers. The artist draws, I program, we never cross paths and we won't argue about how a routine could be further optimized or something like that because neither of us knows how to do what the other person does. We just stick with what we know. That way, the program gets done faster and better.
|
|
Reply to this comment
|
6 September 1998, 15:50 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
|
Peter O''Neal
|
|
I agree to the fact that a team gets the job done. I think that if everyone in the development area pulls together, then a great game can be made. I personally am a beta tester. If there is anyone considering the idea of making a game as a team, then count me in.
|
|
Reply to this comment
|
7 September 1998, 01:55 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
Ed
(Web Page)
|
|
I think that teams would help a growing problem of people who have talent but not time. Many people start with a good idea, but after programing the core of the game or maybe the first level, quit becuase they are tired of it. Then we get these "0.03B Nuclear Annilation" or whatever. The programmer never finishes, so you keep wondering why he never came out with a version to fix that annoying bug that keeps you from moving left when you fire. (This is just an example. If there actaully is a game called Nuclear Annilation, sorry. :) ). The programmer then releases the source and says the customary "I've gotten bored with this, see if you can do whatever with it." Then another good idea goes down the drain. If only he had been part of a team, then he might have recieved a little encouragement.
Also, I like two player games. I have to say, Ztetris86 is about the most played game at my school because of its fun two player mode.
--Ed
|
|
Reply to this comment
|
7 September 1998, 07:13 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
|
Cody Zimmerman
|
|
I agree wholeheartedly. I'm trying to do this right now. I'm making a game and I want different programmers to make different parts of it. One person has already responded and will begin work but I need 3 more programmers and a graphics artist. Everyone will get credit for their parts in the game and it looks to be an awesome game. I nedd a racing programmer, a shoot-em up programmer and a puzzle/graphics programmer. PLEASE I need programmers quick or all production will have to cease!
|
|
Reply to this comment
|
7 September 1998, 20:15 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
|
Jeff Tyrrill
|
|
Teams are a good idea for making games, if they are organized well, and that is the critical point. Some of you may remember the Flight Simulator idea from long ago when a bunch of people on the Assembly-85 mailing list joined a group to create a Flight Simulator game. People were really excited, but there was no organization, so not a thing got done!
The only way I can see a team of more than two or three people working is if a management system is created to assign people jobs. However, with the following proposed idea, teams of even very large amounts of people can be workable.
First, a single person (maybe two) can decide to start a new project. They'll announce it and then people can sign up to do specific tasks. Probably those one or two people will do most or all of the major planning and design, but anybody could sign up to create specific program routines, graphics, do testing, or other jobs. There would be no problem with people slacking off because they know in advance what they're signing up for, and they can sign up to do as much or little as they want. The head(s) of the project would give specifications for the different routines so people know exactly what to do.
Lastly, I propose that ticalc.org considers creating an interface on their web site where people can create projects, list the tasks that need to be done, allow people to sign up for tasks, and manage everything. This will allow work to be divided in an organized fashion. If somebody wants to see a game released sooner, they can sign up to help write a routine for it. If somebody has a great, detailed idea for a game but not enough time to program it all, the person can create a "project" on the web site where others can write most of the code. In the final released game, a credits list can list all those who contributed, with the head designers and programmers at the top of the list, and maybe another listing of minor programmers.
I think ticalc.org (or anybody) creating this automated system would be very helpful to encourage more good ASM programs and games to be written. (Of course, there would have to be a rule that the project creator has to contribute something of value, he can't just say "I'm announcing a (insert game here) project and people can sign up to design and program it.")
|
|
Reply to this comment
|
7 September 1998, 22:48 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
Will Shaver
(Web Page)
|
|
The two ti-92 basic games that I have published -- Sting Ray 2 (sr2.zip) and Stratega (stratega.zip) -- were both programed in a team of 3 people. In fact, because of how complicated programming a 2 person and 2 calculator game is, there is no way that I could have possibly not programmed it with the help of my teammates.
Ohh and if you havn't tried programming a game for 2 calcs, with the game running on both at the same time, then try it. I'll be the first to warn you though, bring some asprin.
-Will Shaver
|
|
Reply to this comment
|
9 September 1998, 07:12 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
|
Joakim Back
|
|
I like the thought of teaming up, but the groups shouldn't be larger then a couple of people.. If it is, it must have a leader or someone to be responsible. If not, people would ask everyone and they will all have own ideas and some might complain about it.
I myself, is a grafix-guy, but I am trying to learn assembler for my ti 86.
|
|
Reply to this comment
|
9 September 1998, 12:20 GMT
|
|
|
Re: Article: "Let''s Team Up to Game On!"
|
|
Rahil Khalik
|
|
Your idea is okay but I think people should first gather their ideas about programming. This way group members can share ideas that will make games more interesting. I agree in your statement proving teamwork can create faster work, but without teamwork you can make better games dealing with your own ideas. Also there is a competition for great games.
If you dont understand me, please e-mail. Thanks for reading.
|
|
Reply to this comment
|
9 September 1998, 22:28 GMT
|
|
1 2
You can change the number of comments per page in Account Preferences.
|
