Code Monkey home page Code Monkey logo

divine-engine's Introduction

Divine Engine

TypeScript License Open Source Love Build Status codecov


The Divine Engine is a Typescript game engine built for developers - first and formost - on some of the latest web libraries and frameworks. The Divine Engine allows users to develop and deploy lightweight games in a modern development environment. The engine focuses on being modular and lightweight, all while allowing developers to quickly build projects and applications and begin buidling right out of the box.

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Documentation

Before you begin with the project, check out the Divine Engine's API documentation and learn what the engine has that you don't have to write. Also be sure to checkout the wiki for additional information on the engine.

Prerequisites

  • Install NodeJS and NPM

    If you've never worked with NodeJS or NPM before, check out my tutorial on setting up a Typescript library. The first part of the tutorial goes over how to install NodeJS and NPM here.

  • Install all project dependencies

Installing

To use the Divine Engine in your own project, first setup a new NodeJS project:

Documents/projects/> mkdir temp-project && cd temp-project && npm init

Note: (use npm init -y for a basic setup).

Next install Typescript and the Divine Engine from NPM as project dependencies:

Documents/projects/> npm install typescript divine-engine

Now you can begin working with the Divine Engine in a new TypeScript file.

Running the library unit tests

Running the unit tests is simple when using NPM, all you need to call inside the project folder is:

npm test
# Or one of it's variations:
# `npm run test:` and tab the rest out

Note: each test must be passing before submitting a pull-request. Travis-CI will check unit tests before allowing admins to merge. More can be found in CONTRIBUTING

Break down into end-to-end tests

The engine runs these unit tests on all core components. Through the methodology described in the proposal, unit tests are crucial to the development of this project. Test cases are written before code development, then functionality is written and tests are run to debug. This will ensure rigorous testing of the engines components and structure for a complete product.

Code Linting

Coding styles must be followed in this project. To ensure that users are following the standards, all pull requests will be run with the linting standards described in the tslint.json file.

Built With

Contributing

Please read CONTRIBUTING for details on our code of conduct, and the process for submitting pull requests to us.

Authors

Spencer Pollock

See also the list of contributors who participated in this project.

License

This project is licensed under the Apache 2.0 License - see the LICENSE file for details

divine-engine's People

Contributors

dependabot[bot] avatar srepollock avatar

Watchers

 avatar

divine-engine's Issues

Linting Test Scripts

Setup linting standards scripts. This will ensure that all code added to the project follows the coding standards and guidelines as described in the tslint file. Having linting in a project is important so as to get quick merges into the project and to best avoid merge conflicts in the future.

Render System

The rendering system is the meat of an engine. Really if nothing is displaying, you don't have much of a game. For this engine, I have finally decided to begin using ThreeJS as my renderer. I have begun implementing the system, and while it's showing a standard screen, it is not correctly implemented in the engine as of yet. I will continue updating this thread with any hiccups along the way.

Asset Loading

I need a tracking issue for assets. This is to ensure that they will be called properly and effectively. This is a personal tracking item.
As commented in commit 4cf0930:

/**
  * Asset Manager class
  * Load Asset example:
  * 1) When an asset is required, send a message to the IOSystem. ex: IOSystemMessage(data: filename)
  * 2) IOSystem recieves message and calls AssetManager.load(filename); on complete, sends an AssetMessage
  * 3) SceneManager recieves all AssetMessages (as the Scene in SceneManager will hold the loaded assets)
  * 4) SceneManager.Scene contains the asset for updating
  */

This issue is tracking the changes made to the system to ensure that the Assets are added to the Scene VIA message calls

Fix messagesystem tests

What is the Issue

The messagesystems tests are erroring with: TypeError: Super expression must either be null or a function. After doing some research it looks like the issue is a circular-dependency.

I will try to fix using the fix I talked about in the GameWindow issue.

How to duplicate the issue

Run npm test on commit 7813838.

Screenshots/Console output/Log files

> [email protected] test /Users/Spencer/Documents/git/divine-engine
> mocha --opts mocha.opts test/components/*.spec.ts test/core/*.spec.ts

/Users/Spencer/Documents/git/divine-engine/node_modules/@babel/runtime/helpers/inherits.js:5
    throw new TypeError("Super expression must either be null or a function");
    ^

TypeError: Super expression must either be null or a function
    at _inherits (/Users/Spencer/Documents/git/divine-engine/node_modules/@babel/runtime/helpers/inherits.js:5:11)
    at /Users/Spencer/Documents/git/divine-engine/src/core/scenemanager.ts:36:26
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/core/scenemanager.ts:170:2)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/core/engine.ts:7:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/core/dobject.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/core/component.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/components/flagcomponent.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/components/index.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/src/index.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/test/components/flagcomponent.spec.ts:3:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at /Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:250:27
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:247:14)
    at Mocha.run (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:576:10)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/bin/_mocha:637:18)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:279:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:752:3)
npm ERR! Test failed.  See above for more details.

Update publishing guidelines

Documentation

  • Project has a LICENSE file with an open source license
  • Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
  • The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
  • The issue queue is up-to-date, with issues clearly organized and labeled
    Code
  • Project uses consistent code conventions and clear function/method/variable names
  • The code is clearly commented, documenting intentions and edge cases
  • There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)

People

If you’re an individual:

  • You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)

If you’re a company or organization:

  • You've talked to your legal department
  • You have a marketing plan for announcing and promoting the project
  • Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
  • At least two people have administrative access to the project

Codecov not displaying nyc generated coverage

What is the Issue

Looking at this Travis-CI log file it says that the lcov generated from nyc is being sent to Codecov however when I check it is not there. This may be an issue with me not running my tests first, then running the coverage generation, but I don't know for certain. Next step is to update my .travis.yml to better match what Codecov says to use under: With NYC.

How to duplicate the issue

None.

Screenshots/Console output/Log files

Check the Travis-CI log file

Messaging System

The messaging system is the backbone of the Daemon engine and it is something that I have spent a lot of time racking my brain with. There is a few implementations that I would like to try, after reading Jesse Warden's article on message systems. After reading I have decided to either go with a node stream based messaging system that will allow easy subscribing and publishing of messages, as well as piping messages, or go with a basic pub/sub message system. While streams are more efficient, they are much more complex, and almost redundant in a lightweight game engine. This could be a good place to learn and implement, but may prove too complex. With the pub/sub system it is easy to learn, implement and use, so it will be my backup solution to the message system if I cannot get streams working or implemented in time.

Regardless of the solution I go with, there needs to be a message system implemented before the end of Stage 2 of the project.

Engine tests

Engine tests

What is the Issue

Finish base engine tests with message system integration. This should test all engine functions.

MessageReceiverComponent causing Engine.instance to throw an undefined error

What is the Issue

Commit: a5594d8

When working on the MessageReceiverComponent and trying to subscribe to the MessageSystem with a callback function to handle the message, the Engine.instance is not defined.

I'm attempting to call Engine.instance within the MessageReceiverComponent constructor and it appears to be called before the Engine is being initialized.

In the MessageReceiverComponent spec file you can see that I'm calling Engine.start() before initializing the MessageReceiverComponent. This could be an issue with exporting the class then.

How to duplicate the issue

Pull this commit and run npm test

Screenshots/Console output/Log files

> [email protected] test /Users/Spencer/Documents/git/divine-engine
> mocha --opts mocha.opts test/components/*.spec.ts test/core/*.spec.ts

Debugger listening on ws://127.0.0.1:1123/bb186ffd-47ec-4d97-bc2b-b798e35363bb
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Error Code: 101 Information: Engine instance undefined.
/Users/Spencer/Documents/git/divine-engine/src/core/engine.ts:123
        throw new Error(_logging.ErrorCode.EngineInstanceNull.toString());
        ^

Error: 101
    at Function.get (/Users/Spencer/Documents/git/divine-engine/src/core/engine.ts:70:19)
    at new instance (/Users/Spencer/Documents/git/divine-engine/src/components/messagereceivercomponent.ts:6:16)
    at Suite.<anonymous> (/Users/Spencer/Documents/git/divine-engine/test/components/messagerecievercomponent.spec.ts:17:13)
    at Object.create (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/interfaces/common.js:112:19)
    at context.describe.context.context (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/interfaces/bdd.js:40:27)
    at Object.describe (/Users/Spencer/Documents/git/divine-engine/test/components/messagerecievercomponent.spec.ts:7:1)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Module._compile (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .ts] (/Users/Spencer/Documents/git/divine-engine/node_modules/pirates/lib/index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at /Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:250:27
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:247:14)
    at Mocha.run (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:576:10)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/bin/_mocha:637:18)
    at Module._compile (internal/modules/cjs/loader.js:686:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:266:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)
Waiting for the debugger to disconnect...
npm ERR! Test failed.  See above for more details.

Unit tests with Mocha and TypeScript are erroring

What is the Issue

When running npm test the command line is erroring in multiple ways. 1) Mocha is complaining about running TypeScirpt written files 2) it must run the code through a transpiler to test before running through Mocha 3) the transpiler is erroring on the type of Babel being used and 4) the tests cannot run in the DOM.

This is a multi-layered issue that will take time to address and debug. Over the next few days I really have to pay attention and get this error fixed. This will take some time to look at TypeScript, Babel and module loading. I still fully do not understand and will have to research this before I can properly utilize it. I will have to start looking at StackOverflow forums and the likes because this project needs to get working sooner than later.

How to duplicate the issue

Run npm test on 5a5645e to see the log error.

Screenshots/Console output/Log files

> [email protected] test /Users/Spencer/Documents/git/divine-engine
> mocha --opts mocha.opts

/Users/Spencer/Documents/git/divine-engine/node_modules/babel-core/lib/transformation/file/options/option-manager.js:328
        throw e;
        ^

Error: Requires Babel "^7.0.0-0", but was loaded with "6.26.3". If you are sure you have a compatible version of @babel/core, it is likely that something in your build process is loading the wrong version. Inspect the stack trace of this error to look for the first entry that doesn't mention "@babel/core" or "babel-core" to see what is calling Babel. (While processing preset: "/Users/Spencer/Documents/git/divine-engine/node_modules/@babel/preset-env/lib/index.js")
    at throwVersionError (/Users/Spencer/Documents/git/divine-engine/node_modules/@babel/helper-plugin-utils/lib/index.js:65:11)
    at Object.assertVersion (/Users/Spencer/Documents/git/divine-engine/node_modules/@babel/helper-plugin-utils/lib/index.js:13:11)
    at _default (/Users/Spencer/Documents/git/divine-engine/node_modules/@babel/preset-env/lib/index.js:150:7)
    at /Users/Spencer/Documents/git/divine-engine/node_modules/@babel/helper-plugin-utils/lib/index.js:19:12
    at /Users/Spencer/Documents/git/divine-engine/node_modules/babel-core/lib/transformation/file/options/option-manager.js:317:46
    at Array.map (<anonymous>)
    at OptionManager.resolvePresets (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-core/lib/transformation/file/options/option-manager.js:275:20)
    at OptionManager.mergePresets (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-core/lib/transformation/file/options/option-manager.js:264:10)
    at OptionManager.mergeOptions (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-core/lib/transformation/file/options/option-manager.js:249:14)
    at OptionManager.init (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368:12)
    at compile (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-register/lib/node.js:103:45)
    at loader (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-register/lib/node.js:144:14)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/Spencer/Documents/git/divine-engine/node_modules/babel-register/lib/node.js:154:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at /Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:250:27
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:247:14)
    at Mocha.run (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/lib/mocha.js:576:10)
    at Object.<anonymous> (/Users/Spencer/Documents/git/divine-engine/node_modules/mocha/bin/_mocha:637:18)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:266:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)
npm ERR! Test failed.  See above for more details.

API documentation not working

What is the Issue

The API documentation is not displaying correctly from the Travis-CI build with the TypeDoc build. There may be another type of documentation builder I can use. I will look into this later

How to duplicate the issue

Check out the docs and just navigate around the site to view the error. Look into different modules and you will see that there is nothing being displayed but if you look at the file tree on Github there are clearly files there.

Screenshots/Console output/Log files

Check the site

Modular package bundler

Setup Rollup along with Babel to bundle the Typescript code to Javascript for consumption.

Note: This will need to be completed before the testing framework is setup as the testing framework needs Javascript files

[REPORT] Week 1

Summary

A summation of this weeks’ report as given in this document.

Week one was difficult in the sense that I gave myself a very short window to work with. I didn’t allocate my time correctly over the weekend, and that hurt my optimism in creating a testing project for stream messaging. While I got a good majority of what I wanted to be done, I did not complete all my goals to the extent that I wanted to. A temporary testing project has been created and will be integrated shortly (approximately another 2-4 hours of work) into the engine to replace the current event-based message system. This will be a large overhaul but will be important to integrate early. Next week, I will better plan my time and allocate it more to the project to reach the timeline set.

Week Goals

Goals to be completed at the end of this week. These goals are to be small and easy to achieve in a 10-hour time frame.

  • Stream messaging between two components in a node process
    • Setup a temporary project for this
    • Build off the typescript-bootstrap project
  • Objects should be in the NodeJS process
  • Unit tests for functions created before programming
    • All tests must pass
  • Full documentation on functions
    • All functions must have 100% documentation coverage by Istanbul
  • Code must follow ES Lint

How they will be accomplished

Tactics that will be followed to help ensure the goals are completed by the end of this week.

  • Using typescript-bootstrap (a project created by myself) to create a test project implementing Node streams
    • This will be a simple project just to showcase how Node streams work
    • Doesn’t have to be fancy, just has to work
  • Once working, then tests will be written in the main Sunset Engine project and will be ported over into modules
    • All tests must pass
    • All modules must be documented

End of Week Summary

A summation of this week’s goals.

What can be better for the next week?

Reflection on this week's tasks. What was done well? What was done poorly? What could’ve been approached better?

  • More reading into the NodeJS stream documentation will be required
    • Especially on the basic Reading and Writing streams and Duplex/Transform are built off it
    • Additionally on the EventEmitter API as Streams are built off of it

Out of Scope

The goals that were out of scope for this week’s task list. Keep this to a minimum. If goals are constantly being placed here, goals are being set too high and should be minimized as much as possible.

  • TCP and Socket connections for the overall engine
    • By setting up a stream message system off the bat - which is used in the http and socket libraries as a main source of communication - the project could have future networking capabilities that can be added into the native message system

Resources

Resources used for this week. Could be articles, blog posts, Game Engine book pages, online projects, tutorials, etc… Should be added to as the week progresses.

Unit test framework

Setup a unit test framework to be called on the engine to check the functions. This is critical to the project as we are using a test-driven staged development methodology.

The testing framework will be written with Mocha and Chai dependencies.

Base game engine running

Create a runnable game object based on the engine architecture proposed in
image
This engine should show running output in the debug console.

Cleanup

All issues will address this until I have cleaned up this project to its entirety. Cleanup here is in the context of removing extraneous issues, files, and reverting to my new workflow.

Divine Engine Diagram

This is a tracker for the current UML diagram of the engine. This will be a useful issue for a top-down view of the engine, I think...

Version 1.0 Tracking

Entity Component System Requirements

  • Unique game object ID’s for easy access
  • Entity-Component game object system
  • Game objects can send messages directly to the message system
  • Game objects can receive messages directly from the message system
  • Developers defined game objects loading from a project (outside of the game engine file system)
  • Developer defined components loading from a project (outside of the game engine file system)
  • Game managers can access game objects for scene managing

Message System Requirements

  • Stream-based messaging system
  • All objects can receive messages
  • All objects can receive messages of specific types
  • Objects do not receive messages they do not specify
  • Objects can unsubscribe from messages
  • Messages can send information from system to system

Render System Requirements

  • Scene loading
  • Scene reloading
  • Rendering textures
  • Rendering sprite sheets
  • Rendering sprite animations from sprite sheets
  • Allows for layering of textures and UI objects
  • UI object selection

Physics System Requirements

  • Rigidbody components with force movement
  • Rigidbody object rotation
  • 2D box collider components with collision detection over the message system
  • 2D box collision response between game objects over the message system
  • Game world gravity effecting objects movement

Sound System Requirements

  • Can play game music
  • Can play sound effects
  • Can play music from game object call
  • Can change game music from manager objects
  • Can pause music
  • Can pause music from manager objects
  • Can play tracks on repeat
  • Can start music from the beginning at any time

Input System Requirements

  • Tracks keyboard input
  • Messages keyboard input to objects through the message system
  • Objects can receive developer specified keyboard input
  • UI elements on press or action sends user input messages through the IO system to the message system for handling
  • Controller input (Xbox controllers on Windows) handled by the IO system

Overall Engine Requirements

  • Insert new game objects while the game is running with incremental building
  • Restart scene and insert new game objects with incremental building
  • Close and re-run application from the initial or specified scene and insert a new game object with the incremental building – specified by the project configuration
  • Specified scene loading on startup
  • Unit tests for each system in the engine checking each function built into the engine for code debugging
  • Continuous integration testing running on source repository checking unit tests for passing to ensure no errors were added in the commit
  • Code linting run to ensure code requirements are met and running with tests
  • Engine error code system displaying and human readable to pinpoint errors
  • Documentation covering 70%> of the code per stage delivered to ensure an API built with development
  • Reads an external project file system for developer objects
  • Deploy to npm on each push to master as a new version release
  • Runnable immediately after installation to a developer’s game project
  • Builds an empty project from a console command for developers to get started
  • Builds an example project from a console command for developers to see how the engine works

Istanbul coverage incomplete

Describe the bug
I cannot get my Istanbul to correctly check the if statement in systemstream to remove messages from the stream when they should no longer be read.

To Reproduce
Steps to reproduce the behavior:

  1. Run npm run test:all to get the report

Expected behaviour
Messages should be removed from the

Screenshots
None.

Code snippet
Tests

    it("should pass global messages to the process.stdout", () => {
        let m: Message = new Message("Hello world!", MessageType.Global, true);
        let es: EngineStream = new EngineStream();
        systemStream.write(m);
        systemStream.pipe(es).pipe(process.stdout); // printing here
        es.on("data", (data) => {
            expect(systemStream.fromJSON(data)).to.not.be.undefined;
        });
        process.stdout.on("data", (data) => {
            let d = systemStream.fromJSON(data);
            expect(d).to.not.be.undefined;
            if (d.type === MessageType.Removed) {
                expect(true);
            } else {
                expect(false).to.be.true; // Will throw an error
            }
        });
    });

System Stream

    public _transform(chunk: string, encoding: string, callback: TransformCallback): void {
        let message: Message = this.fromJSON(chunk);
        if (message.single && (message.type === this.type)) {
            message = new Message(message.data, MessageType.Removed, true);
            callback(undefined, this.toJSON(message));
        } else {
            callback(undefined, chunk);
        }
    }

Desktop (please complete the following information):

  • OS: macOS

Additional context
None.

Scene switching

What is the Issue

Setup scene switching in the main engine. This will allow users to change scenes. Maybe there should be a SceneManager class within the engine?

Windows programming

Suggestion

Setup a task runner (GulpJS or GruntJS) to run npm scripts. They do not work in relative paths for node_module scripts.

This is a feature later on to add, when I want to start doing more Windows development. I could also setup the task runner to setup the projects for me for testing purposes as well?

[REPORT] Week 2

Summary

A summation of this weeks’ report as given in this document.

I didn't complete the message system this week, but I have completed more cleanup of the engine (re: #61). Additionally, I've made more sense of how TypeScript and NodeJS work together than before, and now I'm on my way to making the most of this system. This weeks tasks will be rolled into Week 3 #65 unfortunately, but for the best.

Week Goals

Goals to be completed at the end of this week. These goals are to be small and easy to achieve in a 10-hour time frame.

  • Messages are not being removed from the stream when they are handled by their respective type
    • Transform stream should allow me to “remove” messages (just not write them to an out stream) and handle them internally
      • This will require integration with the main project’s sub-systems
  • Full documentation on functions
    • All functions must have 100% documentation coverage by Istanbul
  • Proof-of-Concept integration into the main project’s engine
    • Unit and integration tests will need to be written
    • 100% test coverage of all functions must be brought into the project before continuing

How they will be accomplished

Tactics that will be followed to help ensure the goals are completed by the end of this week.

  • Scheduling will be done every Sunday (starting this week) for the week ahead
  • NodeJS Streams API will be read to help create my own implementations of the stream’s for the message system (mainly Duplex and Transform)
  • Tests and documentation will be built into the engine before the system is implemented.

End of Week Summary

A summation of this week’s goals.

Not a bad week. Needed to work on more over the week, but got a lot of cleanups done on the engine. Figured out that babel is completely unecessary, and tsc and ts-node are the only compilers I need, as well as npm for my scripts. Everything else is terchiary. Also, almost finished chapter 2 - that will be tomorrow's task as well and rolling over to week 3.

What can be better for the next week?

Reflection on this week's tasks. What was done well? What was done poorly? What could’ve been approached better?

Done a better job of sticking to my schedule, and need to be proud in that. Working to keep on track while reading up on best practices, development pipelines and functional development.
Have to keep my schedule for next week to get it done on time.

Out of Scope

The goals that were out of scope for this week’s task list. Keep this to a minimum. If goals are constantly being placed here, goals are being set too high and should be minimized as much as possible.

None for this week, they are all possible and will be rolled into next week.

Resources

Resources used for this week. Could be articles, blog posts, Game Engine book pages, online projects, tutorials, other issues, etc… Should be added to as the week progresses.

LogDebug(string)

Create a new debug log function that will only be run in debug mode in engine options.

Broken link in README.md to CONTRIBUTING.md

Broken link in README.md to CONTRIBUTING.md

What is the Issue

The link in README.md to see the CONTRIBUTING.md file directs users to github's http 404 (page not found) page.

current link URL in README.md is:
https://github.com/srepollock/divine-engine/blob/master/CONTRIBUTING.md

How to duplicate the issue

On the repo's main page on the Code tab, scroll down in README.md, and click the CONTRIBUTING link. You will then be shown github's page for http 404.

Suggested fix:

use the URL:
https://github.com/srepollock/divine-engine/blob/master/.github/CONTRIBUTING.md

I'd be happy to update this in README.md for you.

`getChild(string)` on Entity is not efficient

getChild(string) on Entity is not efficient

What is the Issue

The Entity function getChild(string) is handing back an undefined. Is there a better way to talk to the developer that they don't have a child before handing back a null?

How to duplicate the issue

Code found in entity.ts

Screenshots/Console output/Log files

None.

Mocha tests are hanging

What is the Issue

Mocha tests are hanging. Pull from 4af5661 to test error.

Boneskull may have fixed this issue and I'm going to test this out later today if possible.

How to duplicate the issue

Run npm test or any of it's variations (by tabbing-out after test)

[REPORT] Sprint 1

Summary

A summation of the sprint as given in this document.

Overall, this sprint was a good start. Most of the time was spent setting up these documents and planning the project over the next couple of months. This is just as important as actually working on the project as it will allow me to focus on what is needed during each week to succeed. This sprint was again short, but not a failure. A slight carryover of work into the second week, including the message system proof-of-concept (POC), but can soon begin integration into the main project soon. Most goals were hit, but a few were out of scope and unnecessary to complete for a POC project.

Sprint Goals

The goals set out to complete by the end of this sprint.

As this will be a short sprint (a few days with not much time) this sprint will not encompass much but is more to get started and get things going. This sprint’s goals are the exact same as this weeks’ goals. Goals are listed in the Week 1 document.

How the goals will be accomplished

Tactics that will be followed to help ensure the goals are completed by the end of this week.

Goals will be accomplished by creating a small, proof-of-concept project. This should be no more than 4 hours worth of work at the most.
Once the proof of concept has been created, tests will be written in the Sunset Engine then integration of the new stream message system will be put into place. Using unit and integration tests, the integration of the new system and refactor will be worked in smoothly, and show most issues before being merged into the branch.

End of Sprint Summary

A summary provided at the end of the sprint of what was worked on. Attached are weekly reports for reference.

#62

What can be done better for the next sprint?

What was done well? What was done poorly? What could’ve been approached better?

  • More reading into the NodeJS stream documentation will be required
    • Especially on the basic Reading and Writing streams and Duplex/Transform are built off it
    • Additionally on the EventEmitter API as Streams are built off of it
  • Set more time aside to work on the project
  • Better documentation in the weekly reports to archive work completed

Out of Scope

The goals that were out of scope for this week’s task list. Keep this to a minimum. If goals are constantly being placed here, goals are being set too high and should be minimized as much as possible.

  • Unit tests
    • All tests must pass
  • Full documentation on functions

All functions must have 100% documentation coverage by Istanbul
I believe these goals were out of scope for this sprint, as they were meant for the test project. There is no need for a proof-of-concept work to have full documentation and testing. The project itself is testing and unit tests are only meant for the end project.

[REPORT] Week 4

Summary

A summation of this weeks’ report as given in this document.

This week went alright. I did not complete as much as I wanted to, however, I did get time to relax and focus on some planning and friends. I will need to complete the main loop early on, and begin to complete the project more thoroughly than when I started out. I may have another idea in mind that will allow me to complete the project a bit sooner than anticipated. More to come this coming week.

Week Goals

Goals to be completed at the end of this week. These goals are to be small and easy to achieve in a 10-hour time frame.

  • Continuous Integration / Continuous Deployment with TravisCI
  • Main engine loop and message loop
    • I have some pseudo code on how to implement this.
  • Update the Wiki with the correct information and my proposal or a link to it (finally).

How they will be accomplished

Tactics that will be followed to help ensure the goals are completed by the end of this week.

  • Following my schedule
  • Setting aside time for reading
  • Writing my test cases before writing my code and following my methodology of Test Driven Staged Delivery

End of Week Summary

A summation of this week’s goals.

What can be better for the next week?

Reflection on this week's tasks. What was done well? What was done poorly? What could’ve been approached better?

I need to better stick to my timeline. Continue to work on weekly tasks when assigned (as well as allowing time to decompress and relax during the day).

Out of Scope

The goals that were out of scope for this week’s task list. Keep this to a minimum. If goals are constantly being placed here, goals are being set too high and should be minimized as much as possible.

I believe Puppeteer may become out of scope for this project at the moment. It could be added in later on but for now, shouldn't be considered as a priority at all.

Resources

Resources used for this week. Could be articles, blog posts, Game Engine book pages, online projects, tutorials, other issues, etc… Should be added to as the week progresses.

Missing Exports for fs in Rollup - A Rollup issue

What is the Issue

Referencing an issue from Rollup. Those were the old files but the issue/fix is the same one I believe. The updated files to this issue are on commit 7b44e4a.

Error output:

> [email protected] bundle /Users/Spencer/Documents/git/divine-engine
> rollup -c


./src/index.ts → ./lib/divine.umd.js, ./lib/divine.cjs.js, ./lib/divine.es.js...
(!) Missing exports
https://github.com/rollup/rollup/wiki/Troubleshooting#name-is-not-exported-by-module
src/core/helperfunctions.ts
readFile is not exported by node_modules/browserify-fs/index.js
30:     // return fs.readFileSync(filename, "utf8");
31:     var output;
32:     fs.readFile(filename, (err, data) => {
           ^
33:         if (err) {
34:             LogError(ErrorCode.ReadJSONFile, `Error writing ${filename}`);
src/core/helperfunctions.ts
writeFile is not exported by node_modules/browserify-fs/index.js
59:  */
60: export function writeJSONFile(filename, data) {
61:     fs.writeFile(filename, data, "utf8", (err) => {
           ^
62:         if (err) {
63:             LogError(ErrorCode.WriteJSONFile, `Error writing ${filename}`);

The further I've dug on this issue the deeper I get into the dependency rabbit hole but I believe I've tracked down the issue. In the rollup-plugin-node-builtins pr 23 @SupremeTechnopriest set the fs path to require browserify-fs. From there the issue sits in this line of code in browserify-fs.

It seems my Rollup is not grabbing the readFile and writeFile exports from the require.

How to duplicate the issue

Clone commit 7b44e4a and run npm run-script bundle

Documentation scripts building

Setting up documentation scripts was completed in Stage 1 however as talked about in issue #7 the documentation is currently breaking and not displaying correctly. This will be worked on and patched for Stage 2

GameWindow

What is the Issue

The engine needs to be running in a window (can be a code generated one) to test the main game loop.

Will look at integrating the BrowserWindow class, or extending a base Window class to create. Need to also see how to get the DOM

[REPORT] Week 3

Summary

A summation of this weeks’ report as given in this document.

This week's report is coming early as I will be out of town this weekend. Again, this week could have gone better, and I would have hoped to have the build working better by this time, however, I have made great strides in my CI/CD build tooling. The message system has been integrated into the project and works great. There is some more testing to be done in terms of networking, however for the purposes of this engine, it does as I would like it to at the moment. I thought I would like to get a Docker build setup for this project however, I feel as this is out of scope for the project at this time, and can be implemented in a later build. Right now I am working on setting up a more secure TravisCI build in my TypeScript Bootstrapping project and will continue to finish it and integrate into this project. I have to be wary as TravisCI only allows 100 private repo builds as a trial period, so I need to be sure that what I am building is correct. Next week I will be completing the building process and will begin working on the main loop.

Week Goals

Goals to be completed at the end of this week. These goals are to be small and easy to achieve in a 10-hour time frame.

  • Messages are not being removed from the stream when they are handled by their respective type
    • Transform stream should allow me to “remove” messages (just not write them to an out stream) and handle them internally
      • This will require integration with the main project’s sub-systems
  • Full documentation on functions
    • All functions must have 100% documentation coverage by Istanbul
  • Proof-of-Concept integration into the main project’s engine
    • Unit and integration tests will need to be written
    • 100% test coverage of all functions must be brought into the project before continuing
  • Docker image for the project

How they will be accomplished

Tactics that will be followed to help ensure the goals are completed by the end of this week.

Following my scheduled plan: reading my course book, reading NodeJS API and setting time aside for extra work when possible.

End of Week Summary

A summation of this week’s goals.

What can be better for the next week?

Reflection on this week's tasks. What was done well? What was done poorly? What could’ve been approached better?

Continue sticking to my schedule. I will need to make up for lost time in the next week.

Out of Scope

The goals that were out of scope for this week’s task list. Keep this to a minimum. If goals are constantly being placed here, goals are being set too high and should be minimized as much as possible.

Docker and CI/CD with Docker. For now I will only be using TravisCI (as it can also deploy). This shall be put on hold for now and can be set up at a later time to run on different OS' and builds.

Resources

Resources used for this week. Could be articles, blog posts, Game Engine book pages, online projects, tutorials, other issues, etc… Should be added to as the week progresses.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.