Team Ballistic!
Author
Team name:Team Ballistic
Project name: Ballistic
Brief description:
The game is a 2D, side-scrolling game based on Worms. Mine, however, will not be turn based but will be free-roaming (that's probably not the term i am looking for) where players can run around freely shooting at opponents. The level/map will be deformable like in Worms but will also have dirt that can fall down on the players if they destroy part of the terrain. Maps will also have rock which does not fall down but can be destroyed.
Target aim: shareware
Compensation: none
Technology:
C++, Visual Studio (MSVC++), SDL, OpenGL
It will be developed for PC but hopefully ported to other platforms one day.
Talent needed:
Right now, 2D graphic artists and music composers. (you don't have to be professional)
Someone who can help me designing the game
When i get to development, C++ coders.
Help with design; A.I., physics, event system, etc.
Team structure:
no one yet :)
Website:
http://ballistic.sourceforge.net/
Contacts: just pm me or email me at xtal256@hotmail.com
Additional Info:
i would like someone to make sprites for me (see this link), and also sfx/music.
Feedback: ANY, go for it
If anyone would like to help me with any of the above that would be great.
thanx
[Edited by - XTAL256 on April 7, 2009 8:46:52 PM]
Hi, i'm new to game design, but am willing to learn, have reasonable English skills and am highly dedicated. I have had little experience, but I am willing to help with game design. If you are interested you can contact me at: robert DOT o DOT king AT hotmail DOT co DOT uk
Cheers,
Robert
Cheers,
Robert
Author
The latest docs are up for anyone to look at and i would like to hear any comments/suggestions on what i've done so far.
Hi XTAL256,
First of all I love your professional approach to your project and you've already got done more actual work than many of the hobbyist projects ever see.
I'd like to know if there's a good reason why you're doing your documentation the way you are. In game development the SRS (Software Requirements Specification), what you call Requirements Model here, is called Game Design Document. This document is the result of Requirements Analyzis which may have confused you? If you want to go the 'SRS-way' for a game (which you have pretty much done) I think you should take Use Cases -oriented approach (which you've pretty much done also). The problem is that in your RequirementsModel.doc you've used terminology that is used in designing actual businesses which is very confusing.
So what you've done in my opinion is to write a Software Rrequirements Specification for a game, name it like a 'algorithm' with a purpose (compare Waterfall model for example) and use business planning terminology in it. I think you should rename the Requirements Model to Game Design Document (Nobody will complain although the template is from a SRS) and change all the "Buisness Scenario"-stuff into "Use Case"-stuff.
Also your Software Architechture Specifiation or Techincal Design Document in game development is weirdly named as System Model. It also includes a lot of Non-Functional Requirements (from 2.2 to 2.7) which in my opinnion should only be found in SRS. I would have gameplay, story, ruleset and Non-functional Requirements on the Game Design Document, then create a UI Design Document using the requirements formed by the GDD and then write a Technical Design Document which tells how both of them are going to happen.
Don't take my words as the absolute truth. I've never even written as detailed document as you got there, and in the end I might be the one confused (though I highly doubt it :P).
Btw. The gameplay of a 2D multiplayer action-game Soldat should interest you, here's some: ">
First of all I love your professional approach to your project and you've already got done more actual work than many of the hobbyist projects ever see.
I'd like to know if there's a good reason why you're doing your documentation the way you are. In game development the SRS (Software Requirements Specification), what you call Requirements Model here, is called Game Design Document. This document is the result of Requirements Analyzis which may have confused you? If you want to go the 'SRS-way' for a game (which you have pretty much done) I think you should take Use Cases -oriented approach (which you've pretty much done also). The problem is that in your RequirementsModel.doc you've used terminology that is used in designing actual businesses which is very confusing.
So what you've done in my opinion is to write a Software Rrequirements Specification for a game, name it like a 'algorithm' with a purpose (compare Waterfall model for example) and use business planning terminology in it. I think you should rename the Requirements Model to Game Design Document (Nobody will complain although the template is from a SRS) and change all the "Buisness Scenario"-stuff into "Use Case"-stuff.
Also your Software Architechture Specifiation or Techincal Design Document in game development is weirdly named as System Model. It also includes a lot of Non-Functional Requirements (from 2.2 to 2.7) which in my opinnion should only be found in SRS. I would have gameplay, story, ruleset and Non-functional Requirements on the Game Design Document, then create a UI Design Document using the requirements formed by the GDD and then write a Technical Design Document which tells how both of them are going to happen.
Don't take my words as the absolute truth. I've never even written as detailed document as you got there, and in the end I might be the one confused (though I highly doubt it :P).
Btw. The gameplay of a 2D multiplayer action-game Soldat should interest you, here's some: ">
Author
Thanks for your input. The reason i am doing it the way i am is simply because i did it at uni. Yes, it is for a business system but i haven't done any courses on game designing, this is just a hobby.
The reason for actually doing the documentation in the first place is because of promise that it will make coding a whole lot easier. My lecturer said that when he did the course he did all the docs and stuff and when it came to the coding everything just worked! First time! Their design was so good that everything just came together without any bugs. And since i would have no hope of just jumping straight into coding, i decided to give it a go. And it would be good practice for if i ever did have to do some design docs.
I will take your advice and rename the sections simply to make more sense (to me as well!).
thanx
The reason for actually doing the documentation in the first place is because of promise that it will make coding a whole lot easier. My lecturer said that when he did the course he did all the docs and stuff and when it came to the coding everything just worked! First time! Their design was so good that everything just came together without any bugs. And since i would have no hope of just jumping straight into coding, i decided to give it a go. And it would be good practice for if i ever did have to do some design docs.
I will take your advice and rename the sections simply to make more sense (to me as well!).
thanx
Share:
This topic is closed to new replies.
Advertisement
Advertisement
