frostoven / cosmosis Goto Github PK
View Code? Open in Web Editor NEWSpace sim in early development
License: Other
Space sim in early development
License: Other
Details:
Implement a HUD item that allows you to track, perhaps on some sort of compass, where nearby bodies are relative to you yourself.
Details:
Move away from react-three-fiber to plain three.js.
We'll still be using React itself for some UI items, but unfortunately we will no longer be using react-three-fiber within this project.
Reasoning:
Whilst react-three-fiber is undoubtedly a very powerful tool, react-three-fiber is a bit lacking in documentation right now. My understanding of three.js is simply too little to use educated guesses to perform tasks (this is my first three.js project, and I'm currently the only contributor). Simple tasks are simply taking me way too long. By contrast, vanilla three.js is quick to learn.
Details:
The application doesn't really work out-of-the-box at the moment. Adjust npm scripts and the like to 'just work' so that we may do our first release.
Details:
We need a standard linter setup to ensure we have consistent code across various files.
Details:
We need build scripts. The purpose of these is to easily publish distributables to the releases page.
The current steps are detailed at the bottom of the CONTRIBUTING.md page, but note that the instructions are currently windows-only; we likely need to include other platforms.
Once the build scripts are working, CONTRIBUTING.md needs to be updated as part of this task.
Optional extra credits:
[Parent issue: #74]
Details:
We need to make planets and the space ship interiors respect local star light.
Task:
Note that this task refers to lighting from the local star and does not include stars that are light years away.
Investigation to be followed in comments below.
Details:
First release was potentially a little confusing to new users because it doesn't have menus, tutorials, hints, etc.
Requirements:
Details:
User profile backups were initially meant to be implemented in #48, however profile backups are not really essential so early in pre-alpha and time constraints for the task were exceed. This ticket should continue that work.
Original task:
Create backups of the profile before it's written. If writing the backup fails, abort. This allows us to 1) restore to a working save on catastrophic failure and 2) means we can pre-emptively check for write issues that might corrupt the profile in use.
It should be noted that this task will only be consider low priority as long as the game isn't yet a proper (fun/playable) game. The moment we have real players doing real things, this task becomes top priority if not yet implemented.
Describe the bug
Under certain conditions, the ship steering will get flung in some direction when entering locked mouse steering.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
Steering should be centered when entering mouse steering.
Desktop (please complete the following information):
Details:
Implement feature that allows looking around inside the ship.
Details:
I tried electron for fun, but I'm not quite what I'm used to and its quirks are interfering with development. Switching to nwjs, something I've worked with a long time.
All issues are currently managed on my own machine.
Task: migrate to them to GitHub.
Details:
Create unit and integration tests.
We will not be using any test frameworks for this. Instead, we'll be using in-application tests to make certain tasks a bit easier.
Details:
Moving very fast causes camera glitches. Research done showed that this is caused by the ship moving very (VERY) far from the game's true zero origin point.
When accelerating in regular space, move the space ship through space as per normal. However, when in warp, make the space ship the 'center' of the universe, and make the universe move instead of the space ship.
Details:
The current toast implementation was thrown together in a quick/dirty fashion (in literally 10 minutes) and has multiple issues (the most important one being that queuing messages does not work, and likely never will).
Task:
Implement a new toast system utilising the newly implemented React core. Delete the old toast mechanism.
We need multiple toast types:
Not all of them will be made equally - for example, system messages may recur for things like "Maintenance at 18:00." Interaction messages have no time limit, and are instead killed by a deletion event. Quest messages will have no option to be displayed indefinitely, and will have 'long' or 'short' time limits.
Toast messages should have the option to grab input priority for potential interaction. For example, a quest message might be displayed for 5 seconds, and have a little 'Press [Tab] to open journal' note that takes one to that particular entry in the journal. A 'Press [E] to interact' should have appropriate callback mechanisms.
Details:
All UI code not currently tied to per-frame updates are currently written as tacked-on HTML. Move this into a proper React JS mechanism.
Future menus should also use this new mechanism.
Details:
Add modding support. We want to add as many functions to these as possible. All mod functions need to employ checklist loading signals and attempt to do as much error checking and error logging as possible, even at the potential expense of performance.
Functions should be groups in major categories, example:
Technical details:
modding
directory in /apps
.modding
dir needs to have a v1
dir, in which the mod API js files will reside. This is so that we may create breaking changes in future if needed without actually breaking existing mods. This should ideally never happen, but it's good practice, anyway.mods
in the root directory, and create these directories in it:
Mods need to have exactly two files: name.js
and name.json5
. The JSON5 file will be used to feed the user info before they enable it. Once enabled, the game should md5 sum the js file and store that in the user profile. If the md5 changes, the application should complain and give the user the option to force-enable the new file if they so choose.
JSON5 file requirements:
The JSON5 file should contain a series of values. They are as follows:
name | Unique name of the mod.
modApiVersion | The mod API version that the mod uses. We'll start at v1 and hopefully never have the need for a v2.
minimumApplicationVersion | The minimum version of the game the mods requires to work. This is important because the modder may be targeting functionality that does not yet exist on the user's machine, in which case the application should warn the player. They will still have the option to force enable the mod.
Logging:
No mod functions should console.log any debug information. Warnings should be avoided, but may be added. Errors should always be logged.
Details:
Implement a mechanism that allows different parts of the application to, asynchronously and retroactively, know the boot state and progress of the application.
Details:
Implement file resource loader. It should automatically default to productions assets, but fall back to dev assets when prod assets are unavailable.
Details:
Once the game nears the end of pre-alpha stage, ensure that all UI components are VR compatible.
Details:
API function should be smart functions. I.e. they should work when appropriate, or wait for an appropriate time to execute before executing.
Details:
The way input modes are currently implemented in core has a design mistake that needs to be addressed before the UI can be implemented. If correctly implemented, different modes may sometimes, but not always, be mutually exclusive. You can have more than one active at a time, with input preference based on some predefined [hardcoded] priority.
Using Dark Souls as an example: you can run around while in ANY menu, but arrow keys and interaction keys are now snatched by the menu and don't make their way to the game. Some flight have similar features.
Needed result:
For each action mode, send the current key(s) pressed.
By default, all active mode controllers¹ should receive key input simultaneously. A controller is allowed to request priority or exclusive access.
Bonus points:
Don't allow the key controllers to actually receive keys; rather, have them receive actions. This makes control bindings completely transparent, and allows abstracting between, say, keyboard and mouse events.
Completion of this task does not require implementing all possible peripherals; rather, it requires setting up the basic framework to facilitate any peripherals.
¹ Controller in this case refers to a logical piece of software controlling what happens to actions generated by input from any source, including keyboard / mouse / gamepad. It does not mean 'hardware device'.
Details:
Implement keyboard controls.
Requirements:
Details:
There are currently UI elements (such as the speedometer and thrust indicators) that update very frequently, but is written as plain HTML. Rewrite this as pure Three.js code.
Note that the Three.js code does not have to look the same visually; the items currently in place were created in a rush for debugging purposes.
Details:
Implement HMR. For now just make it reload the entire application. Eventually we may open a new task to have HMR reload pieces of the application as needed.
Details:
Add initial mode switching, initial draco mesh loading, FPS meter, and some demo assets.
Details:
The asset loader mechanism is somewhat incorrectly named at the moment. Additionally, the constructor should be capitalised.
Rename assetLoader to AssetFinder, because that's what it does: it searches for assets based on certain conditions.
Then, create a new AssetLoader constructor to manage assets at the high level.
Details:
Make it possible to use two (or more) buttons for a single key binding. This is important with controllers where the ~16 buttons available are not enough for all available actions (at the time of writing we already have 16 actions in shipPilot mode alone, and that list is incomplete).
This needs to be implemented in ContextualInput. Unless someone has an alternative suggestion, this should be implemented by intentionally introducing a tiny bit of lag to allow for keys to pile up.
Not everyone will appreciate this tiny additional lag, so this needs to be an option disabled by default. The user should also be allowed to choose the amount delay time in milliseconds, with a suggested default.
Describe the bug
The direction in which you point the ship in 3D design software (such as Blender) will determine what forward is. This is not only unintentional, but was supposed to be fixed with 300652f. It seems something was either improperly tested or we have a regression.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
With the current implementation, direction should be based on the direction the first camera in the scene is pointing.
Desktop (please complete the following information):
Additional context
This bug is a weird one because the DS69F and Scorpion-D space ships actually point in two very different directions already (also I'm 100% sure I tested the devFlyer... regression, maybe?).
Details:
Add free cam functionality.
Details:
Implement level logic by making player space ships load as levels. Add logic to interact with switches. Make switches trigger reversible door animations.
Details:
Add visual collision bounds for debugging purposes in physics code.
Details:
We need something to stream in images and height data for celestial bodies. This would be akin to something like tile servers used by OpenStreetMap and Google Maps.
Example use case:
This might might take form as a separate application service spawned by the main application.
The contributing page is currently a braindump, and is missing some details. Please complete it.
Details:
Implement warp drives.
Requirements:
Details:
Ship loading process currently ignores any lights defined in the 3D editing software (such as Blender).
Implement a clear process on how lights made in 3D editing software interact with the engine, then document it.
Describe the bug
Seems an accidental dependency on frame rate was introduced while creating warp drives.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
Speed should be consistent. Changes in frame rate should not affect speed.
Desktop (please complete the following information):
Additional context
This also manifests as the speedometer rapidly changing speed.
Details:
Add visual speed indicator to godCam and freeCam.
Implement space ship physics using Canon.js.
Note: this task is purely related to space ship physics while not in a warp bubble.
Implement the in-game menu (including options, quit, inventory, etc) using React. The menu needs to be implemented as a mode controller.
A menu system should be implement using React. Should use Semantic UI React as the base.
Debug tools
menu implemented.Options
menu implemented.Graphics
menu implemented.Customisation
menu implemented.Credits
menu implemented.Profile
menu implemented.Details:
Add a CONTRIBUTING.md file. Does not need to be complete just yet; just need something basic going.
Details:
We need an ultra low quality mode that causes the game to:
Details:
Browserify is unable to deal with external libraries that have not been transpiled to lower versions. Replace with webpack, which is known to do this well.
What needs to be documented?
How we create a fully working install for Windows.
Details:
Move cam[0] logic into ship loader.
Explanation:
Currently, the engine expects any imported space ship to have at least one camera. This camera is used as the 'forward' direction of the ship. This same camera is also used as the captain's bridge seat location. Logic needs to be updated such that:
Describe the bug
Interacting with door switches no longer cause doors to open.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
Door should slide open when interacting with switch, and close again if interacting with switch a second time.
Screenshots
https://imgur.com/a/ftIxXdc
Desktop (please complete the following information):
Additional context
This appears to have started happening after the ship was parented in warp bubble logic.
Door switch no longer light up green like it used to, either.
Details:
Implement full screen. User should be able to press F11 to enter and exit full screen.
Details:
Webpack is currently spitting out warning which are invalid. Silence them.
Details:
Changes the user makes in the menu need to be persisted to their profile. These changes include:
Profile needs to be saved in a standard location that makes sense given its host OS. Examples:
Windows | C:\Users\[user]\AppData\Roaming
Linux | /home/[user]/.local/share
Apple | /Users/[user]/Library/Preferences
Android | /storage/emulated/0/Android/media
Please make the profile multi-user (i.e. allow for multiple save files). Perhaps limit the names a profile can have, example [a-zA-Z0-9_]
so that we may give each profile its own directory. Create a default profile with name default
during boot if it does not exist.
We also need to provide the option to have no saves in case saving is impossible (i.e. permission denied, out of space, cannot determine OS profile location, etc).
Overview:
manifest.json
(maybe?).Details:
Create control mappings that allow controlling the space ship while in warp.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.