So, after a conversation with my friend and coworker, Brendan, I have some information on the game design I'd like to share with you all!... First off, I am now no longer the only experienced C++ developer in the project, as Brendan is interested in helping out.
Here are the things we've talked about.....
Technical LimitationsWe can't do anything, the sky is not the limit. We're a very small team sparse on talent with no real experience at all. Here are some of the key points we've come up with....
- No 3d at all. The game will be entirely in 2d... That means no FPS's, but still leaves in side scrollers, isometric view, top down... Stuff like that... We have neither the programming nor the art talent to make a 3d game, limiting it to just 2d can give us a better quality end result, because good 2d is better than bad 3d
- No "real time" networking... What this means is that we can have fast netcode, but we're not going to go into the world of lag compensation. The result of that is that all actions will take time equal to your latency and a given player's latency combined for that player to see an action you do. Think like, 50-300 millisecond lagtime on every action... So exact accuracy of location or events cannot be depended on.
- There are probably more
Organization of WorkloadIt'll be important for each person to know what they need to do. We think breaking into small teams is the best way to seperate the planning and implementation of the separate entities in an organized manner. Any person can be in any number of teams, and frequently the teams will be working together on things. Much of the inter-team communications will be giving todo lists to the other teams, such as requesting sound effects for certain things, or filling in missing art... Here are the teams we thought of...
- Engine Team - The team responsible for developing the game engine. The game engine is the core system that drives the graphics, sound, gameplay, netcode... All that stuff... The engine team is not responsible for game content or game logic at all, they are only responsible for making a usable game engine for content to be put into. This team will write almost entirely in C++, and will likely be just Brendan and I, possibly also Daguava (aka "That PHP Guy" when Brendan and I talk about him ).
- Game Logic Team - Another programming team, but this time only responsible for game mechanics and the implementation of content. This team is not responsible for creating content, but instead turning all of the content into actual code. This team will be writing almost entirely in Javascript, using the engine created by the engine team.
- Art Team - This team, obviously, is responsible for creating all of the art for the game. There will be a lot of art to be made, from times, items, players, HUD, menus, enemies.... The list is endless... Similar to the game logic team, this team is not responsible for thinking up the art to be made, but instead creating the art that is required of them.
- Sound Team - Another obvious team following the same obvious rules... They make the sound that is needed, but are not responsible for creating the game concepts behind the sounds...
- Game Details Team - While it is assumed that virtually everyone will be designing the game and putting in their opinions on mechanics and stuff, this team handles specifically the very very fine fine details, down to pages of story, fine grained level design, and the logic for the game mechanics. Everyone will be creating ideas, and when we all agree on these ideas this team will flesh them out into the details, creating todo lists for all of the above teams (except the engine team)... This team will also be responsible for bringing important design decisions to everyone, never making large decisions on their own. They only flesh out existing decisions.
Things to keep in mindThis needs to be well though out. If the game isn't going to be played, it's not worth writing. If we're going to make this shit, we might as well put our all into it, else who do it to begin with... I don't want this to be a project that is started and completed in just a few months, this needs to have massive amounts of content and very fun gameplay...
It also needs to be realistic. Basically the opposite of above, while we want a content rich game that's really fun, we also can't make the most detailed RPG game ever made. The game needs to be within our obtainable scope.
This will not be pure fun. It'll be mostly fun, but it will also be a lot of hard work. There will be a lot of tedious things to work on that are repetitive, such as creating 500 tilesets, or sound effects for 100 different swords, or implementing the mechanics for 250 different spells many of which function very similarly.
Not everyone can get started right away. The game engine and details teams can, but the art people rely loosely on the engine team and lightly on the details team, the logic team needs a completed engine and details to implement from the details team... So on and so forth...
We'll probably nominate a few people to run the individual teams, and then also a person or two to run the project as a whole. The purpose of these roles is to keep a final authority when all else fails.... Similarly to how SHENS is run, everyone's opinion will be heard and just about everything will be decided via community discussion and polls, but it's nice a have a final authority to turn to when all else fails. We can discuss that later.
Obviously, everything I've stated is up for discussion, these are just the things that Brendan and I think...
PS: Double post!
