Blood Omnicide team

From Blood Wiki
(Difference between revisions)
Jump to: navigation, search
m
m
Line 1: Line 1:
 
{{WIP}}
 
{{WIP}}
 
{{TOCRIGHT}}
 
{{TOCRIGHT}}
This article explains some inner workings and rules of Blood Omnicide team.
+
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

Contents

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

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


Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox