Analysis update
This commit is contained in:
@@ -101,19 +101,3 @@ Game Engine - With Mist a maze game
|
||||
which is a high level OOP interpreted langauge with a low learning curve due to its simple to learn syntax, and tons of helper functions for rapid development.
|
||||
- It could be used by educators for teaching game development basics to students and getting hands on experience.
|
||||
- This engine also indirectly effects the gamers, the end users as they are the ones to feel any performance costs when enjoying the games.
|
||||
|
||||
# Analysis
|
||||
|
||||
(an outline)
|
||||
-> first i say what is teh kind of thing im making is (an engine and the core job of an engine) and similar softwares (godot, unity etc.), and then explain that doing physics calculations and controlling multiple objects in a virtual world etc. can be done using computers
|
||||
-> then the kind of people it is meant for
|
||||
|
||||
- teachers of about high school level can use it to teach students about game development and using ecs systems and even OOP or teh languge ruby (the engine uses mruby for teh games with the engine itself written in c++), and explain how they can use it.
|
||||
- indie developers, similar explaination but also teh fact that the engine is built to work crossplatform on desktops and also packs the final binary as a standalone (which can be very useful), and helps keep a unique brand image (+ normal stuff like high performance and ruby prototyping speeds for making games quickly and support for ecs and object oriented styles they could choose and audio and animations etc.), also include myself in this category and hwo it will also simplify licensing issues for myself.
|
||||
- and then a section of research into existing engines both ones with ui/without: unity, godot, gosu etc., by going into their specifics and how they manage systems liek unity's ecs system and godots object based, then like gosu and how it is much more minimalist and more like a library than a proper engine, and then parts of tehir architectures i like vs ones i dont, like the ecs from unity, or physics and shaders and animations / tiling and templates etc from godot, or ruby from gosu, but also stuff i dont like like gosu requiring a ruby runtime etc.
|
||||
- and then use the data from the previous section about possible choices in architecture / dev i have and then design a survey asking people (with 2 categories, education or game developers), and what they think about it, (in which alongside data i can explain a bit about the data being done on a very small scale possible issues with such data etc.)
|
||||
- then a little interview chat with an actual developer who's used godot a lot and what features of it makes them use it and what i should add more
|
||||
- then a draft one of teh requirements with justification of each based on the previous sections
|
||||
- then any limitations / problems that can arise with certain choices in that list and how i might tackle them or ignore them
|
||||
- then specifics of what ill need to actually make this, like the libaries languages hardware etc. ill use with reasons of why, can have a big section on stuff like explaining why i chose sdl3, or mruby (mostly because of mruby precompiling and how i can prepack the engine into a single binary - as im doin)
|
||||
- and finally a rigid list of requirements of things it should be doing by the end with 2 priority levels and this time just the list and not any justifications or none
|
||||
|
||||
Reference in New Issue
Block a user