Ядро логики или логика ядра

Начал программировать ядро игры. Передо мной встал вопрос риторический вопрос о том, что появилось раньше — яйцо или курица? Иными словами я видел 2 ветки развития ядра, приведу код инициализации первого:

program TheGame;
uses
  Windows, uGame;
begin
  Game := TGame.Create;
end.

И инициализация второго:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, GLCadencer, GLWin32Viewer, GLCrossPlatform, BaseClasses, GLScene,
  uGame;

type
  TForm1 = class(TForm)
    GLS1: TGLScene;
    GLViewer1: TGLSceneViewer;
    GLCadencer1: TGLCadencer;
    procedure GLCadencer1Progress(Sender: TObject; const deltaTime,
      newTime: Double);
    procedure FormCreate(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  Game := TGame.Create(ClientWidth, ClientHeight, GLS1, GLViewer1, GLCadencer1);
end;

procedure TForm1.GLCadencer1Progress(Sender: TObject; const deltaTime,
  newTime: Double);
begin
  Game.Update(deltatime, newtime);
end;

end.  

Как можно догадаться: в первом случае ядро игры сама создает себе форму и рабочий цикл, а во втором «внешний» каденсер обрабатывает все вычисления.
Казалось бы в чем подвох и почему я мечусь именно между двумя данными вариантами? Объясняю:

Можно сделать код очень компактным, красивым, приложение (aka игру) самостоятельным и независящим от каких-то внешних факторов, то есть — все внутри него и ничего более не требуется.

Звучит красиво и привлекательно, ну а что будет, если мы присмотримся ко второму листингу:

Логика игры разделена с инициализацией Windows-форм и работой движка. Таким образом, мы делаем именно игру, работа которой не зависит от инструментария, на котором она написана и портировать ее мы сможем на любой другой движок, виджет (не только VCL) и даже язык программирования (если скомпилируем ее в dll).

Скажу сразу – я выбрал независимость игровой логики от других факторов. Очень удобно работать вне связки, с чем либо.
Давайте думать дальше: логика с движком у нас не связана, но ведь передвигать мы будем не только импульсы в процессоре, но и меш на экране. Как мы можем чем-то оперировать, если не имеем доступа к элементам движка (в противном случае нарушается независимость логики от используемого инструментария)? Вот тут я и думаю снова создать велосипед. Будет промежуточный юнит uGameObjects, в котором я воспроизведу по новой все необходимые классы.
На практике это будет выглядеть примерно так:

TMyMeshObject = class(TMyPosObject)
private
  FGLFreeForm: TGLFreeForm;
public 
  procedure LoadMesh(path: string);
end;

procedure TMyMeshObject.LoadMesh(path: string);
begin
  FGLFreeForm.LoadFromFile(path: string);
end;

Подобное решение, наверное, может показаться очень кривым, зато для смены движка необходимо будет изменить лишь один единственный юнит, а не все подряд.
Работа по реализации всего этого, пока я начну писать код самой игры, займет у меня уйму времени, и я надеюсь, что не зря.

06.05.10 → 11:38:45