A Development Kit for the Kestrel Game Engine
License: MIT License
This repository is being archieved due to mistakes that were made in the development of this codebase, and how things have been structured. I've made big changes to KDL and basically rewrote much of the codebase. It now shares the same underlying foundation that Kestrel itself will use.
You can find this repository at: https://github.com/tjhancocks/kdl
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Disaster resource type (aka öops). This will allow declaring and defining Disaster resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::disaster class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the öops resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Rank resource type (aka ränk). This will allow declaring and defining Rank resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::rank class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the ränk resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the NPC resource type (aka düde). This will allow declaring and defining NPC resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::npc class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the düde resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Weapon resource type (aka wëap). This will allow declaring and defining Weapon resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::weapon class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the wëap resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Nebula resource type (aka nëbu). This will allow declaring and defining Nebula resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::nebula class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the nëbu resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the HUD resource type (aka ïntf). This will allow declaring and defining HUD resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::hud class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the ïntf resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Commodity resource type (aka jünk). This will allow declaring and defining Commodity resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::commodity class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the jünk resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the ScheduledEvent resource type (aka crön). This will allow declaring and defining ScheduledEvent resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::scheduled_event class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the crön resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Government resource type (aka gövt). This will allow declaring and defining Government resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::government class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the gövt resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
As it turns out, this development kit is going to need to read resource files as well as write them. This is also true of Kestrel itself. This means the two should share this implementation.
Describe the solution you'd like
The ResourceFile management aspect of the KDK should be made into something that is reusable. It can still exist within this repository, and probably should exist in this repository as to maintain the the MIT License of the development kit. Kestrel will then include the entire development kit as a submodule/dependancy.
Given that the Kestrel engine will potentially need a copy of the development kit at compile time for assembling a bundled scenario, this is an obvious solution (at least for now).
However, it does require that the resource file implementation be completely independent of the rest of the assembler.
Describe alternatives you've considered
Resource Manager lives in separate repository or is duplicated across codebases.
Describe the bug/issue
The link in the README to the Kestrel engine itself is broken ("https://github.com/tjhancocks/kestrel"). It produces a 404.
To Reproduce
Click the link on GitHub.
Expected behavior
Links to a valid repository.
| Aspect | Information |
|---|---|
| Author | Tom Hancocks |
| Proposal Date | 11 December 2019 |
| Status | Review |
KDL currently allows only for the creation of new resources, and has no concept of overriding existing resources. Whilst it is possible to override them by simply creating a new resource, if the new resource only needs to change the name, or a single value, then it can be tedious to have to define each of the fields with the original resources values.
At present there is only one way to define a resource in KDL.
declare Resource {
new (id = #128, name = "Replacement Shuttle") {
` specify all of the fields for the original "Shuttle" and change the values you wish to alter.
}
}
This is a passable solution and it gets the job done, but it is not intuitive/friendly to the developer. It should be possible for KDL to explicitly state that a declaration/definition is overriding another resource.
declare Resource {
override (id = #128, name = "Ripoff Shuttle") {
` specify only the fields that need to alter.
cost = 100000;
}
}
This would allow the assembler to know that the resource should be overridden, and require it to load the existing resource data and use that as a basis for the new resource. This will however, require a number of additions and improvements to the assembler.
These additions are the minimum required to allow this to work.
| Aspect | Information |
|---|---|
| Author | Tom Hancocks |
| Proposal Date | 12 December 2019 |
| Status | In Progress / Writing |
At present KDL is a largely static definition language, which is not ideal long term. It requires type information to be baked into the assembler, and thus new versions to be deployed in order to keep pace with the Kestrel engine. It also makes it impossible for forks, variants of Kestrel to add new types and make use of KDK.
By adding Assembler Directives we can allow for more dynamism and the following things to happen:
KDL already has the basic syntax for Assembler Directives built in.
@directive {
... do something here ...
}
Directives start with an @ and the directive name. Presently only the @out directive exists, and it is used for dumping information to the standard output. It might be used for something like:
@out {
"AwesomeTech is designed for use in EV Nova, and developed by John Smith."
}
It can provide a means of informing users about the plugin/data file being assembled (presuming the plugin/data file has been distributed as source.)
There are 4 primary extensions to Assembler Directives that will be discussed here.
It could be made possible for meta data to be encoded into plugins, either as extended file attributes, version resources, or some other yet undefined resource type.
For example, assume the following directives are used in the source for the AwesomeTech plugin.
@require { "Nova" } ` Takes the name of the scenario it requires
@name { "AwesomeTech" }
@author { "John Smith" }
@version { "1.0" }
These directives are an example of what could be added. Both @name, @author and @version are self-explanatory and obvious, but @require warrents further explanation.
Assuming the addition of an option to the assembler that allows referencing/linking against an existing scenario, the @require directive could be used to enforce the need to be linking against a specific scenario.
As an example, presume the following invocation of the assembler
$ kas --scenario="/Applications/EV Override.app/Contents/Scenario" AwesomeTech.kdlPresumming the Scenario defines the following
@name { "Override" }
And the plugin specifies the following
@require { "Nova" }
Then the assembler can infer that it will be referencing an incorrect set of information, and thus warn the user.
It is rarely a desirable thing to include absolutely all of your code into a single file, and thus the ability to import other code files into the current context is important. At present KDL provides no way to do this.
There are multiple ways this will likely work ultimately. This is one of the mechanisms that will likely be required.
@import { "/path/to/type-definitions.kdl" }
This is using the same familiar directive syntax, but with a slightly different mode of operation. All directives execute immediately upon being seen. The @import can utilise this behaviour, open the specified KDL file, perform lexical analysis of the contents and insert the resulting tokens into the current semantic analysis context in place of itself.
If the imported KDL script includes type definitions, then those types will now be seen and parsed by the current semantic analysis context, and become available to use in the script.
` Import the Mission resource type definition.
@import { "/path/to/game/mission-definition.kdl" }
` Use the Mission resource type.
declare Mission {
...
}
to be spec'd
to be spec'd
It should ultimately be the responsibility of a scenario to define the resources it needs. This allows for appropriate naming to be used within KDL, and easy expansion and reuse of the assembler.
Before getting started this is an example of what a type definition might look like.
@define {
name = "Sprite Animation";
field("sprites") {
required;
value(type = resource_reference, offset = 0);
};
field("masks") {
deprecated("This field is not used by Kestrel.");
value(type = resource_reference, offset = 2);
};
field("size") {
required;
value(name = "width", type = integer, offset = 4, size = word);
value(name = "height", type = integer, offset = 6, size = word);
};
field("tiles") {
required;
value(name = "x", type = integer, offset = 8, size = word);
value(name = "y", type = integer, offset = 10, size = word);
};
}
The definition needs to be able to specify the locations of values in the binary data, and the sizes of those values. To begin with the definition language should be simple in its capability, and extended later. This should allow focusing on getting a working system in place first.
The following value types should be specifiable in definitions:
resource_reference: This value expects a resource id. Ideally there should be a way to constraint what happens when a file("...") value is given as a reference.integer: This value expects an integer. If an integer type is specified then a size must be specified as well (byte (1), word (2), dword (4), qword (8)).string: This value expects a string to be provided. If the string type is specified then a length must be specified as value.c_string: This value expects a variable length, null terminated string to be provided.p_string: This value expects a variable length string with a maximum length of 255. The length is encoded in a byte at the start of the string.color: This value expects an RGB color encoded as a dword integer.bitmask: An integer type that merges symbol values together. If an bitmask type is specified then a size must be specified as well (byte (1), word (2), dword (4), qword (8)).Symbols are a way of specifying a semantically appropriate representation of a value. For instance, take the following resource declaration.
declare Person {
new(id = #130, name = "Nameless") {
` ... stuff ...
government = none;
` ... stuff ...
}
}
Rather that specify the value -1 directly, we have provided the symbol none. The assembler knows to subsitute the none for -1 in this context.
Symbols can be defined by doing the following.
field("foo") {
value(type = bitmask, offset = 0, size = word) {
}
};
Has this proposal being discussed with the community? Changes to KDL affect everyone, and thus the more people that have been involved in refining it the better. If you haven't discussed it yet, then perhaps consider taking it over to the Discord and discussing it there first.
Detail some alternatives that were considered, and why they would not really solve this particular problem.
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Person resource type (aka përs). This will allow declaring and defining Person resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::person class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the përs resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Character resource type (aka chär). This will allow declaring and defining Character resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::character class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the chär resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
This may require work to be done for file_reference types, allowing image data to be imported and setup as a resource (more information and issue related to this to be defined.)
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Interface resource type (aka cölr). This will allow declaring and defining Interface resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::interface class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the cölr resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
This may require work to be done for file_reference types, allowing image data to be imported and setup as a resource (more information and issue related to this to be defined.)
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Description resource type (aka dësc). This will allow declaring and defining Description resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::description class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the dësc resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
Currently the way kas is reporting errors and warnings to the users as it performs lexical analysis, semantic analysis, assembly etc is not particularly useful. It doesn't always reflect what has happened, and doesn't fail gracefully.
Describe the solution you'd like
Diagnostic messages should indicate the severity of the message, the file it was raised in, and the line number. For example:
ships.kdl : L10 : Warning - Resource instances should have an ID specified.
Describe alternatives you've considered
None considered - open to suggestions.
Additional context
N/a
Describe the bug/issue
The accented characters in resource types are not being converted correctly from utf-8 to macroman.
To Reproduce
Assemble the following test file.
declare SpriteAnimation {
new (id = #700, name = "Stars") {
sprites = #700;
size = 10 10;
tiles = 1 1;
}
}
Expected behavior
The ï character in spïn should be written as 0x95 in the output file but it ends up as unicode 0xEF.
[edit] Figured it out, it should push_back(j) not push_back(cp_table[j]). Will submit PR...
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Mission resource type (aka mïsn). This will allow declaring and defining Mission resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::mission class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the mïsn resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Describe the bug/issue
When running kas, the output location (specified by -o) is ignored and output instead goes to the input file (specified by -f).
To Reproduce
make to generate the build directorycd build./kas -o plugin.kdat -f "../examples/kdl/test.kdl" (per the Readme)Note that the output is as follows:
Hello, World
Saving data to ../examples/kdl/test.kdl
As you can see, the output was sent to the input file, overwriting it.
Expected behavior
In the above example, I expect to see:
Hello, World
Saving data to plugin.kdat
In other words, the output should go to what was passed in with -o.
Desktop (please complete the following information):
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Outfit resource type (aka öutf). This will allow declaring and defining Outfit resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::outfit class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the öutf resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the StarSystem resource type (aka sÿst). This will allow declaring and defining StarSystem resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::star_system class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the sÿst resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Explosion resource type (aka bööm). This will allow declaring and defining Explosion resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::explosion class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the bööm resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Say that a PR was submitted. Right now, there is no way of verifying that the code will work properly, or that it won't break existing features, without having a user exhaustively test every scenario of the app. Such manual verification is time-consuming, and as a result is likely to be avoided. Therefore, there's a high possibility that any code may introduce bugs or break existing functionality.
Unit tests are an essential tool to ensuring the stability of a project. With it, we can ensure that new changes don't break existing functionality, and have confidence that our code will run correctly on end user machines.
Kestrel SDK is still a fairly small project, so by writing unit tests now, we can set a precedent for future work and avoid having to add a lot at a future date (in other words, we are preventing "tech debt" at a later time).
The alternative would be to not write unit tests at all, which is the current situation in which we have the problem described above.
This article provides an excellent overview of unit testing in C++, including a comparison of various testing frameworks. I do not have a particular recommendation of one framework over another.
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the StellarObject resource type (aka spöb). This will allow declaring and defining StellarObject resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::stellar_object class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the spöb resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
The kdk::target class is currently building a representation of the final resource file by adding resources to an rsrc::file. However this is not written to disk, and simply discarded as the assembler exits.
Describe the solution you'd like
A method (or set of methods) need to be introduced that allow writing the contents of the rsrc::file object to disk, in the binary format of either a Standard ResourceFork or the custom Extended ResourceFork.
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Ship resource type (aka shïp). This will allow declaring and defining Ship resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::ship class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the shïp resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the ShipAnimation resource type (aka shän). This will allow declaring and defining ShipAnimation resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::ship_animation class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the shän resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
This may require work to be done for file_reference types, allowing image data to be imported and setup as a resource (more information and issue related to this to be defined.)
Is your feature request related to a problem? Please describe.
This is to add a type assembler for the Fleet resource type (aka flët). This will allow declaring and defining Fleet resources in KDL. The assembler should output the current format expected by Nova.
Describe the solution you'd like
This will involve creating the kdk::fleet class (use kdk::sprite_animation and kdk::asteroid as reference), to assemble the binary data for the flët resource type. The field layout, naming and substitution symbols should be logical, and documented as part of the PR, allowing for any potential bike shedding of names and value groupings to be discussed.
Describe alternatives you've considered
Not applicable.
Additional context
None
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.