Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Community :: Articles :: Let's Team Up to Game On!
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!"
(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  Account Info

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: Let's Team Up to Game On!
Sam-ming  Account Info


Reply to this comment    8 May 2010, 10:40 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

Reply to this comment    6 September 1998, 03:08 GMT

Re: Article: "Let''s Team Up to Game On!"
(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!"
The Great aArdvark!
(Web Page)

Flight simulator...

Reply to this comment    6 September 1998, 07:51 GMT

Re: Re: Article: "Let''s Team Up to Game On!"

I don't know what flight simulator is but I'm guessing that its a jet game. I like that idea.

Reply to this comment    15 October 1998, 18:18 GMT

Re: Re: Re: Article: Let''s Team Up to Game On!
Axalon  Account Info

A flight simulator would be cool. Then we could have a 3D flying game. It would take someone who knows how to make things 3D (not me) and would take some awful physics calculations.

Reply to this comment    23 June 2004, 16:53 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: Re: Article: "Let''s Team Up to Game On!"

I couldn't agree with you more. Right now I've teamed up with an artist to work on my current project. It's working great! I believe that this is the best team: one programmer and one artist. The only thing that could make it better is a strict routine person who was on the edge of the team, sort of a big member but sort of attached. Then the programmer can feed any routines that absolutely HAS to be fast and/or small to the "routiner", who can optimize it to heck. The routiner will get plenty of credit but won't be involved in any hard-core programming.
Thanks all for hearing me out,


Reply to this comment    7 September 1998, 04:49 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!"
(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.


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: Re: Article: "Let''s Team Up to Game On!"
(Web Page)

Hmmmm.... that looks to be an interesting game. How are you planning on integrating racing, shoot-em-up, and puzzle? Seems hard, but if you can.....

Reply to this comment    29 April 1999, 05:16 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: Re: Article: Let''s Team Up to Game On!
Axalon  Account Info

That is a great idea, but it has some problems. Doing it on a large site like this one, it would be virtually impossible to keep all of the projects seperate, although it would be easier to trade around good bits of code...

Reply to this comment    23 June 2004, 16:58 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

Re: Re: Article: "Let''s Team Up to Game On!"
hmm 484


Reply to this comment    25 May 2003, 01:40 GMT

1  2  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2012, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer