Blood Omnicide team

This page is actively undergoing a major edit
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 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 and evolve principle, which is allowed to change gameplay in order to get best play experience.

2. A careful re-make

Porting to 3D involves re-making of many things using new scripts and techonogies. The key principle of faithful re-creation is to carefully inspect the original thing, find the rules it was built around. The rules may be (but not limited to): balance, proportions, colors, inspiration, imagery and connections with the rest of game world.

3. Concentrate on a most weak things

The quality of project = quality of it's most weak part. In order to get maximum progress, weakest things are best candidates to be worked on.

4. Continue improvements, even 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

The knowledge of other members work is the key to understanding what is going with the project and therefore, using optimal way to do things. 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

• Alexandra 'Enigma' Melnikova
• Adam Brown

Sketches/concept art

• David Lakatos
• AmDDRed
• GamerXXL
• Hedgenok
• Lidia Lada

Bloody Sounds project

• Marcin 'Emandes' Szymczak
• Paranoid
• Evellnirt
• XVWawa
• Rockmedved

Translation packs support team

• Lorenzo Forini (TraductionProduction), Giorgio 'Zelgius' Di Nucci - Italian pack
• Marcin Szymczak - Polish pack
• Pavel Timofeyev, Sidesman, Paranoid - Russian pack
• Vitor Bolonhesi Gracia, Cristopher Polzl - Brazilian portuguese pack
• Janos Birinyi - Hungarian pack
• Alfonso Ruzafa - Spanish pack
• Xavier 'Knilf' Hurteau - French pack

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