Se me ocurrió la posibilidad de que, por ejemplo, mientras varias personas trabajan simultáneamente en el motor del juego, ¿cómo se evita la sobreescritura?
Digamos que el desarrollador uno está trabajando Audio.cppy el desarrollador dos también está trabajando Audio.cpp, ¿cómo se maneja esto generalmente en equipos grandes para combatir la sobrescritura? (En otras palabras, para evitar que el desarrollador dos abra el archivo hasta que el desarrollador uno haya terminado)
project-management
version-control
teamwork
java
2d
collision-detection
vector
collision-resolution
unity
directx
directx11
directx10
xna
ios
monogame
windows-phone-8
xamarin
design-patterns
oop
xna
collision-detection
collision-resolution
bounding-boxes
rotation
collision-detection
mathematics
javascript
algorithm
separating-axis-theorem
xna
2d
monogame
image
xna
directx
graphics
performance
opengl
2d
3d
c++
directx11
unity
c#
scale
c#
xna
collision-detection
collision-resolution
leaderboards
scoring
glsl
srgb
tilemap
three.js
tiled
unity
physics
xml
dialog-tree
xna
c#
.net
opengl
lwjgl
vbo
physics
graphics
procedural-generation
simulations
water
opengl
java
textures
lwjgl
frame-buffer
unity
unity
2d
collision-detection
collision-resolution
trigonometry
java
android
libgdx
xna
c#
frame-rate
c++
unreal-4
procedural-generation
java
graphics
lwjgl
slick
c++
software-engineering
Ethan Webster
fuente
fuente
Respuestas:
La mayoría de los equipos de desarrollo de software (no solo en desarrollo de juegos) resuelven este problema utilizando el software de control de versiones . Ejemplos son
Todas estas herramientas tienen algunas diferencias, pero el flujo de trabajo básico suele ser así: hay un repositorio central para el proyecto con la base de código completa. Cuando un desarrollador quiere unirse al proyecto, realiza una "compra". El software de control de versiones copia la base de código en su máquina local. El software recuerda la versión actual ("revisión") de la base de código. Cuando un desarrollador realiza sus cambios y quiere colocarlos en el repositorio principal, realiza una "confirmación". Sus cambios se cargan en el repositorio central y se crea un nuevo número de revisión.
Cuando otro desarrollador ahora quiere confirmar sus cambios, pero la revisión que una vez revisaron ya no es la más reciente, el sistema de control de versiones no lo permitirá. El desarrollador primero necesita "extraer" las revisiones que ocurrieron mientras tanto. Esto actualiza su copia local a la versión más reciente en el repositorio central. Cuando hay conflictos (las revisiones intermedias hicieron cambios a un archivo que también cambiaron), el software podría pedirles que resuelvan el conflicto editando los archivos en conflicto manualmente (una "fusión") en caso de que no logre hacerlo automáticamente. Una vez que hayan hecho eso, pueden confirmar sus cambios como una nueva revisión.
fuente
Los desarrolladores no usan el mismo archivo.
Cada desarrollador tiene su propia versión del archivo, y utilizan un tipo especial de software para administrar su trabajo. Si ambos realizan cambios, el que intenta sobrescribir los cambios realizados por el otro desarrollador se encontrará con un conflicto que debe resolverse, de lo contrario, el software del que hablé comienza a quejarse. En otras palabras, el desarrollador que causa el conflicto, necesita combinar su trabajo con el trabajo del otro desarrollador, y solo entonces se puede "guardar" el archivo.
Esta es una explicación simple para una parte del concepto de control de versiones que de otro modo no sería tan simple .
fuente
Además de los puntos planteados en las otras respuestas sobre el control de versiones y el manejo de conflictos con fusiones, existen al menos otras dos formas en que los miembros del equipo pueden evitar sobrescribir el trabajo de los demás:
Algunos sistemas de control de versiones (por ejemplo, SVN) permiten el bloqueo de archivos. Esto significa que un miembro del equipo puede tomar posesión exclusiva de un archivo durante un período de tiempo prolongado, evitando que otros miembros del equipo realicen ediciones conflictivas (o, en realidad, cualquier edición) hasta que el archivo se desbloquee posteriormente.
Sin embargo, esto generalmente se usa con poca frecuencia, ya que puede causar una serie de problemas. Puede reducir la productividad (al limitar quién puede trabajar en archivos en un momento determinado) y puede causar problemas si alguien olvida desbloquear un archivo. Además, al menos para SVN (no estoy seguro acerca de otros VCS), bloquear un archivo no impide que otra persona realice cambios en su copia de trabajo, solo evita que cometan sus cambios; esto puede resultar en un esfuerzo inútil si un desarrollador modifica el archivo solo para descubrir que no pueden confirmar sus cambios porque está bloqueado.
Los equipos pueden tratar de asignar tareas a los desarrolladores de tal manera que no tengan más de una persona trabajando en un archivo en particular en un momento dado. Por ejemplo, los desarrolladores podrían ser responsables de una parte particular del proyecto (por ejemplo, representación 3D, red, audio, etc.): si la base de código está bien modularizada, el desarrollador asignado al código de red debería tener poca necesidad de tocar los archivos lidiando con el audio.
Por supuesto, siempre habrá una superposición que debe gestionarse de otra manera.
fuente