Blood Omnicide team
From Blood Wiki
(Difference between revisions)
m |
m |
||
Line 1: | Line 1: | ||
{{WIP}} | {{WIP}} | ||
{{TOCRIGHT}} | {{TOCRIGHT}} | ||
− | This article explains | + | This article explains rules and principles Blood Omnicide team is built around. |
==The core principles== | ==The core principles== | ||
Revision as of 02:37, 13 December 2012
This page is actively undergoing a major edit
The person who added this notice will be listed in edits history
The person who added this notice will be listed in edits history
This article explains rules and principles Blood Omnicide team is built around.
The core principles
Why participate?
- Blood Omnicide team is formed solely to provide Blood Omnicide development. There can be different personal meanings of joining and contributing, but it must match the goal - develop Blood Omnicide with best quality possible.
Core team calls the shots
- For a community-driven project, such as Blood Omnicide, everyone constantly joining or leaving team.
- In order to keep things clear, there is 'core' team which consist of most passionate members doing planning, decision making and long-term support, and 'cover' team focusing on short-term support.
Cover matters
- It is easy to assume that people forming 'core' team are the team because they are more visible than other members. Core team members is more skilled, passionate and have better knowledge, but there will be no real benefit of that skills without cover team. In other words, a three-man group cant significantly push the project's progress not matter how skilled they are.
Internationale
- Blood Omnicide team consists of people living in different countries. Because of that, there can be very little communication between team members. In order to keep things synced, all workflow information is centered around SVN repository, every change leads to commit and any team member can inspect the results of other members work. Working copy is primary source of inspiration and 'what is going on' information.
Evolving from niche thing towards common thing
- Blood Omnicide at its goal going to be a niche thing. Meanwhile, changes that helps to bring it to more wide auditory is accepted, unless they confront with faithfulness. An example of good changes: multilingual support, wide range of supported platforms, etc.
The team codex
1. Extend, not replace
- Blood Omnicide is a project to port Blood Omen to 3D. Additions should be keeped at minimum, faithfulness and respect to original at maximum. If thing is working all-right, it doesnt need to be changed.
- The only exception is 2d->3d transition, which is allowed to change gameplay in order to get best play experience.
2. Not using 'ripped' content
- Blood Omnicide are not using content ripped from the games. Even from Blood Omen.
3. Concentrate on a most weak things
- The Quality of project = quality of it's most weak thing. In order to get maximum progress, weakest things are best candidates to be worked on.
4. Continue improvements, even if on very little details
- Details is a key to quality. And its always good to add more depth and reduce unneeded complexity.
5. Document changes. Fill the commit logs
- It helps other members to understand direction project is moving to.
6. Break big tasks to a small ones
- Finishing up small parts is easier and more controllable.
7. Follow the plan
- Dont start a work if you have no plan and full vision of a thing.
8. Be opened for collaboration
- Be opened for assistance other members can offer.
9. Conduct and fill up the list of offers and bugs
- Almost any thing made have its good and bad sides. Conducting the opinions of others helps to get cleaner vision.
10. If you dont know how to make something - ask other members
- One of particular benefits of planning is that you come to knowledge, what you will need to get thing finished, and particularily, a things you will need to learn in order to follow the plan.
- Not all kinds of information could be formalized and documented. And its likely that some part of current project information is not documented at all. So it is always good to communicate with others to get better knowledge.
11. Criticize, if you can make better
- It is not bad to criticize the work, but it should have a valid point-of-view as a ground. Criticism without particular explanation is not helpful.
12. Know whats going on
- It is best if any team member knows what is happened. Communicating with other members, reading commit logs and checking out wiki page changes are good way to stay on the edge.
Team credits
This is rough functional team credits listing. A full version will be available at release.
The core team
- Pavel 'VorteX' Timofeyev
- Vitaliy 'Mean Person' Gron
- Yuriy 'Sidesman' Kudrinetskiy
3d modelling
- Alexander 'Roland' Ugolkov
- Alexander 'Q`Linar' Stolbov
- Nikita 'Userdelete' Stadnik
- Pavel 'Norgant' Yefremov
- Sergey 'Mit' Selivyorstov
- Mike Cruz
General artwork and concept art
Sketches/concept art
- David Lakatos
- AmDDRed
- GamerXXL
- Hedgenok
- Lidia Lada
Bloody Sounds project
- Marcin 'Emandes' Szymczak
- Paranoid
- Evellnirt
- XVWawa
- Rockmedved
Translation packs support team
- Lorenso Forini (TraductionProduction) - Italian translation pack
- Marcin Szymczak - Polish translation pack
- Pavel Timofeyev, Sidesman, Paranoid - Russian translation pack
- Alfonso Ruzafa - Spanish
Gameplay inspection
- IvanSv
- Morenn
- SNiCS
- Bloodsteal
Additional texturing / art credits
- Andrey 'Picasso' Shatalov
- Kevin 'Rorshach' Johnstone
- Timothy Andrew 'unDuLe' Wilson
- David Gurrea
Darkplaces engine
- Forest 'LordHavoc' Hale
- Rudolf 'DivVerent' Polzer
- Mathieu 'Elric' Olivier
- Andreas 'Black' Kirsch
- Blub/0
- Eihrul
Game engine and tools
- Darkplaces engine team and contributors
- Randy 'Ydnar' Reddig and Q3map2 contributors
- GtkRadiant team and contributors
- MisterGrim