Guidelines - Senscape/Dagon GitHub Wiki

Foreword

For practical reasons, we have adopted OS X as our primary development platform, hence the reason why the project is organized according to Xcode (the IDE distributed by Apple) standards. This also means that the OS X port of Dagon sometimes gains features before other versions do (see note regarding compatibility). However, this would always be transitory as the ultimate goal is to ensure that Dagon performs exactly the same across all supported devices.

Folder Structure

• Dagon/

  The actual code resides here.

• Dagon.xcodeproj

  The Xcode project for OS X.

• Documents/

  This folder includes the License, Credits, and several combinations of the Dagon logo. Future documentation based on this Wiki will be bundled with the engine inside this folder.

• Info.plist

  This file contains information about the application for Xcode.

• Libraries/

  External libraries such as Theora and Lua are included here for convenience along with their headers. Note this folder is for OS X only.

• Other Sources/

  Files not directly associated with Dagon are included here. For example, the source of the Luna.h template.

• Readme.md

  The typical Readme file in Markdown format, which is readable with any plain text editor and is later nicely formatted by Github.

• Resources/

  Resources such as icon and strings for OS X.

• Sample/

  This folder includes a brief excerpt of the Asylum project and is fully editable.

• Windows/

  Includes a Microsoft Visual C++ Express 2010 project and different Libraries and Resources folders for Windows.

All the shipped project files generate code inside a 'build' folder, which is always ignored when committing.

NOTE: We always suggest pointing the working folder to Sample in your IDE of choice. This way you can test the Asylum code directly while programming the engine.

Versioning

We loosely adhere to the standard Apple versioning system, which includes major, minor and revision numbers with a letter distinguishing the type of release. For example: 0.1.0a where 'a' means alpha.

We also include a four digit build number with, again for practical reasons, is incremented whenever the engine is archived in Xcode. It's therefore advised against doing this so that the version number is managed solely by Senscape, unless you are developing for a drastically different branch that you have forked.

Compatibility

All pushes to master branch should ensure full compatibility across all currently supported platforms. For example, if you must change the DGSystem header then make sure you propagate the changes to all versions of the module. If you are going to try something that you know beforehand it won't be portable, then we recommend doing it in a branch.

If you don't have access to all the supported systems, then get in touch with the administrator before pushing to master, so that your modification is immediately tested.

NOTE: We have included as many omissions as possible in the .gitignore file so that the repository isn't flooded with unnecessary files. However, we recommend visiting the following link if you are using Microsoft Visual C++ which explains how to omit extra files: Why does Visual Studio 2010 create ipch folder and .sdf file?