Hey Craig,
Re .NET Core:
I'm going to use Windows Forms for a built in IDE because I have
experience with it and know it can be made pretty accessible for screen
readers.
That means at least one of the assemblies needs to remain .NET Framework
instead of .NET Core.
That said, I would actually like to make many of the other assemblies
.NET Standard, and make the server programs .NET Core.
Unfortunately intellisense does not work for me using NVDA and Visual
Studio 2017. It used to, but it stopped working a few months ago,
possibly due to me updating to the latest version of VS 2017 at the
time, or possibly due to some other change on my system, since I rarely
used it before updating.
So until intellisense works in VS 2017, I'll continue to use my old copy
for development, which limits me to .NET 4.0.
If you have time to help me troubleshoot this I'd be up for the help.
Re why invent a new language:
That is a great question.
A big part of it is that I feel domain specific languages (DSLs) can
have a huge benefit on the experience of the person writing in them.
As a simpler example, consider the object file format used in TB today.
We generally write one flag per line, with the flag name first, followed
by a space, and then the value.
The archer file in the getting started maps contains lines like the
following:
description A ranged combatant skilled with a long bow.
add_skills attack,defend,move
team 1
attack_health_inflict 4
attack_range 3
sound archer
Note that the new engine gets rid of the |flags line and the file type
and version lines that usually make up the first 3 lines of the file.
It also gets rid of the distinction between C# flags and script flags.
So the above is an accurate representation of the entire archer file in
the new engine.
Compare this to XML, which is considered to be a well established choice
for specifying this kind of data, and it might look like this:
<?xml version="1.0"?>
<Unit
description="A ranged combatant skilled with a long bow."
add_skills="attack,defend,move"
team="1"
attack_health_inflict="4"
attack_range="3"
sound="archer"
/>
Note all the extra quotes that are needed, the equals signs, and
consider that if someone uses quotes in their description string, they
would have to use the backslash character to escape them.
The XML attribute names are case sensitive, it requires the correct
opening and closing less sign, and slash greater than signs.
Unit had better be the only node I define in this file, otherwise I need
to wrap the multiple nodes in a single root node.
We had to have the XML version definition at the front, just because.
I can't even take advantage of an XML schema document because the
attack_health_inflict flag is only allowed because there is a separate
skill file named attack.
I could generate the XML schema document at runtime, but I'm not sure
how that would be any better than just validating the data format myself
at runtime.
JSON is another choice, but it still has a similar amount of curly
braces, required quotes, colons, backslash escape characters, and case
sensitivity.
Using existing libraries to parse XML and JSON are likely to give less
informative error messages than I can give, since they tend to throw
exceptions that they expect trained programmers to read.
These are just things I can quickly think of, but the point is that a
DSL / data format designed to work well for the task at hand tends to
make the builder's life better.
You have personally seen the menu format I was using for AHC, which I
also believe makes writing menus cleaner.
And there is a DSL I built for writing linear JRPG style dialogue.
I can't remember if you've seen that or not, but it is an even better
example of how using a DSL that fits the task at hand can really reduce
the amount of extraneous syntax required for the common cases.
Some of the actual ways the new programming language can make
coders/builders lives better are:
* By not allowing nested function definitions (or using a different
keyword for them), and using keywords for if/then/else/end instead of
curly braces, we can tell a builder/coder about a missing end or right
curly brace very close to the line it is actually missing on.
This is much better than reporting a missing curly brace at the end of a
thousand line file as typescript/javascript might (that actually
happened a few times in AHC with code Joseph had written, that I had to
comb through to find the missing right curly).
* I believe the shift to favoring keywords over special characters in
many cases makes the language much easier to read with a screen reader.
I recognize that experience programmers who are already used to C style
function definitions will find this a bit odd, but I don't think it will
take long to get used to, and I feel it provides a better experience for
blind gamers learning to code for the first time.
You can see some of the actual syntax in my previous email.
This favoring of keywords also shows up in the L I N Q like expression
syntax the new language will support.
And in the if/then/else/end keywords, though that is already common in
languages like lua.
* Building a new language means I can leave a lot of advanced concepts out.
This means that new coders can learn the language quickly, and since the
platform is focused around people being able to take existing programs
or themes and extend them, having a simple language makes it easier to
learn someone elses code.
Another part of the reason for making a new language is about integration.
I plan to have a built in IDE that provides auto complete, go to
definition, and find all references features.
I can ensure that these features work well with screen readers, and
don't get broken when, for example, a new update for VS 2017 comes out.
Since I am parsing and type checking the language myself, I can also
provide stronger integration with the object data files
(unit/skill/effect/item, etc.)
For instance, you could press F12 while on the archer enum in the
programming language, and be taken to the archer data file that contains
all the flags that make up that object.
Or you could right click on a SoundName enum and choose to have that
sound played.
Similarly, you might be testing the FPS you were building, kill another
player, hear the death sound and realize that it is playing the wrong sound.
Then you could perhaps press F12 while in the game, and be presented
with a list of recently played sound events.
Then you could press a key on that sound event to be taken either to the
actual sound object file that was played, or to the line of code that
played it.
I also want to eventually have a live updating feature for speeding up
the iteration cycle of making changes and testing them.
For instance, consider you've written a chess game, now you are testing
it on your local machine.
You make several moves for each player, then as you go to move your
rook, you realize the move validation logic for the rook is incorrect
and not allowing you to place it at a valid destination.
So you switch over to the code, find the mistake, fix it, save, and
press a hot key to live update the currently running game.
Now you alt tab back to the game and quickly test that your update
worked as expected.
I believe that using a custom programming language will make this live
updating feature smoother to implement, being able to clear out old
functions while retaining the existing in memory object graph.
Another part of the reason for building a new programming language, that
is related to the integration point, is that I can perform static
analysis on the code.
I'm using a multiplayer model that sends inputs from clients to the
server, and uses state replication to sync object graph changes on the
server down to clients.
Being able to statically analyze the code means that I can automatically
determine what parts of the object graph actually get used by clients,
and what parts I can avoid sending to save packets and bandwidth.
Similarly I can determine which inputs are informational and handled on
the client side only, and thus avoid sending them across the network as
well.
Reducing the number of unnecessary packets being sent across the network
is a big performance gain for real time network games, and yet I still
get to keep the simple state replication model so building network games
is easy for coders.
Another factor is that using an existing language does not get rid of
all the headaches, though I agree it is a much shorter path to getting
things up and running initially.
For instance, even in the current AHC engine there are subtle issues you
can hit with javascript created lists versus C# created lists.
The runtime errors contain javascript line numbers rather than
typescript line numbers. (There is a way to map them back to the
typescript line numbers, but I never figured it out.)
The last time I worked on getting javascript hosted in C# cross platform
I had to switch from the noesis Windows only library to V8.NET.
Unfortunately V8.NET required me to write a lot of extra code to get it
integrated, and it turned out to have a bad memory leak I never solved.
Having the game logic code run cross platform is not just about getting
it to work on Mac; it is also a requirement for getting it to run on my
linux servers.
Writing more things in C# and reducing the dependencies on external
tools and libraries tends to make it easier for me to port to other
platforms in general, and the parser/type checker/interpreter/compiler
for the new language is all being written in C#.
Another reason to build a new language is that I want every game built
in the engine to have the option of being translated to all the Google
Translate languages, which I would pay for.
The default string concatenation in most programming languages results
in a combinatorial explosion of possible strings, meaning it would get
financially expensive quickly.
I think you've seen how we avoid that by using a String.Format style in
TB and the engine used for AHC.
In a new language I can require that to be the only way to combine
strings, which if you are only using the language for game logic
actually isn't so bothersome as you might expect.
It turns out that in game logic, strings are mostly used for either
comparisons like is this unit the same type as that unit (better handled
with a fancy kind of enums I am building), or they are used as text
output to players (better to be combined in a translation friendly way).
I think ensuring all the games can be played in any language will be a
big benefit to non English speaking gamers around the world.
Side note: there are some games where translation wouldn't be
meaningful, like hangman, crossword, vocabulary, spelling, and other
word games, but they are not the initial focus of this platform.
I hope that does a decent job outlining why I think building a new
language provides some very real benefits, especially in the long term.
All that said, I totally get why you would question the choice to build
a new language.
A few years ago I would have thought it pretty silly to create a new
language when there are already so many that exist, especially since the
learning curve for building languages is steep, and the time and effort
involved is high.
I totally appreciate the empathy, and it has been a lot of work to get
the language working to its current state.
There is still a fair bit more to do on it, but I am already using it to
detect changes in input and adjust player velocity (in a real time game
prototype).
The project in general is huge, and building the new language has been a
large part of the work, but I feel the final product will be worth the
effort.
On 4/11/2018 3:58 PM, Craig Brett (Redacted sender craigbrett17 for
DMARC) wrote:
Would it be worth implementing it in .NET Core? That way, it isn't an impossibility to port it. I'm not sure how you go about making non-web GUI apps in .NET Core yet... I've not really looked into it. I believe Xamrin Forms might serve your purpose there, and as a lot of your old UI code is hand drawn, as it were, I can't imagine it being impossible to do in Xamrin. Maybe I'm biased, I just like .NET Core.
Something that probably needs asking, as I'm looking at this as a potential builder, is why? Why invent your own programming language, when there's lots already out there? I'm not saying there aren't perks, but it does add a layer of complexity for yourself. As an academic exercise, it sounds fascinating, and I can imagine you're having a lot of fun with ANTLR or whichever tool you're using, deciding how you want things to work. I just worry you're fashioning a rod for your own back. That being said, I wouldn't object to it, it's more empathy that makes me ask :)
I am looking forward to this! I've not fully given up on TB or anything, I just keep needing more motivation and time and such than I have available. But a fresh start is something that wouldn't go amiss. And a gaming engine that isn't BGT would always be handy.
On 21/03/2018 15:39, Ian Reed wrote:
Some day it may become cross platform, but in the early days it will be Windows only.
This is because there is just too much to do, and so I have to prioritize features.
Plus I expect people will be able to run it on Mac using wine, as they have done with AHC.
On 3/21/2018 9:33 AM, Joshua Tubbs wrote:
This engine should be cross platform, would be great to build games on Mac and other platforms not served by the audio games community, not just Windows all the time.
On Mar 21, 2018, at 11:24 AM, Ian Reed <info@xxxxxxxxxxxxxxxxxxx> wrote:
I've used a fair number of technical programming language terms in the below description, and assumed familiarity with other programming languages.
For the non programmers, don't let that scare you off.
When the project is released, I hope to create some newbie friendly documentation that teaches people the basics of coding and the related vocabulary.
Plus people can always have a good time as builders, and slowly familiarize with snippets of code at their own pace.
The programming language is a statically typed, imperative language.
It focuses on being simple and readable, so that new comers to the language can pick it up quickly if they have experience in any other language.
This is also a benefit since the platform is focused on people being able to take one game's code and extend it, so keeping the language simple means it is easier to read other people's code.
It also favors keywords a bit more than symbols in order to read better when using a screen reader.
For example, its if/else expressions are closest to lua's, something like this:
if someCondition then callFunc1()
elseIf someOtherCondition then callFunc2()
elseThen callFunc3() end
Having if/else blocks be expressions instead of statements also makes snippets of code found in menu or story files more concise, specifically when they need to result in a value.
It uses the and, or, and not keywords like python and lua, instead of C/C++'s &&, ||, and ! operators.
It is not whitespace / indentation sensitive like Python is.
It doesn't use semicolons.
It uses references, not pointers, and is garbage collected.
There are no bit manipulation operators.
Defining a function looks something like this:
func add, takes a as int, b as int, returns int {
return a + b
}
It borrows the as keyword for specifying a variable's type from Visual Basic.
It uses type inference in most cases to let the coder elide the type.
It is procedural, focusing on functions and data types. It is not object oriented.
Free standing functions can be called using method call syntax on the type of their first parameter.
For instance the above function can be called in the following ways:
var num = 5
var num2 = add(num, 2)
var num3 = num.add(2)
This is similar to how extension methods work in C#, except that all functions implicitly extend their first parameter type, rather than needing an explicit this keyword.
There are many cases where chaining function calls with the method syntax is more readable than nesting function calls.
It will also have a query expression syntax, similar to the L I N Q syntax used in C#.
This is to take common idioms for filtering, ordering, transforming and querying on lists and turn them into a syntax that is easier to read and write.
For example, imagine you have a list of units in a variable called units.
This query would get the names of all the units with at least 50 health, ordered alphabetically.
var results = from u in units where u.health > 50 orderBy u.name select u.name
// then you might print them out like so:
foreach var name in results {
say(name)
}
Note the where keyword filters, the orderBy orders, and the select keyword transforms, just as in SQL or C#'s L I N Q syntax.
We also elide the parentheses around the condition in the above foreach loop, and if/else conditions.
As I designed it, I've referenced C#, Rust, Swift, Lua, Python, Ruby, and Javascript/Typescript to get ideas for which features I felt would work best.
It is a language built for writing high level game logic, not low level sound file streaming or other such tasks.
Those low level tasks will be handled by the game engine, which provides a high level API to coders, and strong integration with the builder tools.
On 3/20/2018 2:24 PM, Joshua Tubbs wrote:
What will the programing language be like? I’m not a fan of C++ syntax, or C#, which I’m pretty. Sure AHC is in.
On Mar 20, 2018, at 4:19 PM, Ian Reed <info@xxxxxxxxxxxxxxxxxxx> wrote:-----
Oh, another reason releasing the AHC engine would be problematic is that I'd have to tear out the translation logic.
It is easy to accidentally use incorrectly,, causing tons of unnecessary translations, so I would have to trust each person using the AHC engine to get it right.
Plus I'd be paying for all the translations done in their games.
The new platform I'm working on takes this into account and makes it much harder for coders to accidentally misuse the translation feature.
This means that the new platform will support translation of all games into the 100+ languages that Google Translate supports.
On 3/20/2018 1:48 PM, Ian Reed wrote:
I won't be releasing the AHC game engine. A few reasons off the top of my head are:-----
* I would have to write a ton of documentation for it.
* I would need to remove anything DRM related, since viewing that code would help people reverse engineer AHC.
* The sound system is FMOD using sound banks. I'm not sure how accessible sound banks are for blind users.
* FMOD's license would not allow me to release it as part of a standalone game engine anyway.
* If I released it, I would spend a lot more time maintaining it, which is less time for extending and maintaining the new engine/platform.
Overall, I've learned a lot from building that engine, but I want to take what I've learned and implement a new engine that isn't held back by needing to remain backwards compatible with AHC scripts.
I intend on bringing all the best features from the AHC engine into the new project, which would make the AHC engine obsolete anyway.
The new engine will eventually support real time games as well, but I'm going to focus on turn based games first, since support for real time games is a bit trickier to get right.
Far down the road, the new engine/platform will have enough features that you could write an AHC like game in it.
But it will also benefit from better performance, better tools, multiplayer capabilities, and my long term support.
On 3/20/2018 1:50 AM, Zak Claassen wrote:
Hey Ian, this sounds very cool. I did some scripts for tb, but like
you said you're limited in what you can do, plus there are some bugs
that cause some scripts to not work like they should, so really
looking forward to this new engine. Would you ever consider releasing
the AHC game engine in a similar form so that people can use it to
create such games?
On 3/20/18, Ian Reed <info@xxxxxxxxxxxxxxxxxxx> wrote:
I am writing the new engine from the ground up.-----
I've learned a lot since I originally wrote TB, and more as I worked on
the engine for AHC, plus the multiplayer features require some major
architectural changes.
I hope and expect the new engine will have better performance than my
previous attempts.
I'm far from perfect though, so we'll have to deal with issues as we
encounter them.
On 3/19/2018 5:41 PM, Shaun Everiss wrote:
The issue with tactical battle I found was that if you had a game say-----
startrek elete and you had well several hundred units same with
rampage, every action dead destroyed, new generated etc, would add to
a memmory buffer.
If that and when that buffer got full the system simply ran out of
memmory to actually do anything and crashed, rampage hit this thing
really fast.
I am not sure what you guys did with ahc but as I understand you
helped with that, now an engine based on that would rock, it certainly
never had an issue with a multiple unit thing and if tactical battle
maps could work with that system that would rock a lot.
On 20/03/2018 12:31 p.m., Ian Reed wrote:
Yes, it takes scripting much further than TB did.
The new system has 2 roles, builders and coders.
Builders work with roughly the same set of tools that map pack
creators used in TB, plus some easy to use file formats for creating
menus and JRPG style story dialogs.
Coders use a programming language to define the game rules and player
interactions.
Coders have a lot more power than scripters did in TB because they
get to define all the game rules, rather than only getting to inject
script at a few key points within the TB rule set.
TB is like a very moddable game.
The new system is more like a game engine that lets people build
their own games in a high level programming language.
Then it hooks those games up to the builder tools so they can easily
be modded.
I'll be making some sample games for the first release, so people can
modify them instead of starting from scratch.
There is a lot to do, so it is still quite a ways off, but I am
excited for it.
On 3/19/2018 1:58 PM, Monkey wrote:
I'm excited to see what this will look like, I've really enjoyed-----
making stuff for TB.
Will be able to script for this new engine as well?
On 3/19/18, Ian Reed <info@xxxxxxxxxxxxxxxxxxx> wrote:
I've restarted the TBServer so you can play multiplayer again.
Craig Brett deserves the credit for adding multiplayer capabilities to
Tactical Battle.
I no longer maintain TB, but I am working on a new moddable
multiplayer
gaming platform.
I expect it to support a wide variety of turn based games, like card
games, strategy games, classic board games, etc.
I will even remake some of Tactical Battle in it as a sample game that
can be extended and modded by others.
It will be much more moddable than TB, so would better support your
ideas for playing table top games, once it is finished.
The map editor and file format for defining units, skills, effects,
items, terrain, etc, will remain roughly the same, so learning to make
map packs in TB would be a relevant skill for the new system.
I think anyone who has enjoyed being a map pack creator for Tactical
Battle will really enjoy the new system.
On 3/18/2018 8:50 PM, ryan.strunk@xxxxxxxxx wrote:
Hi all,
I was very excited to see that version 3 of TB is playable online.
When I tried to log on, though, the server was down.
Is this still in active development? Is it possible for me to run my
own server?
I would love to explore the possibility of using this setup to play
tabletop games.
Thanks for any help you can provide.
Best,
Ryan
You can unsubscribe from this list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject field.
Or by visiting the list page at
//www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
You can unsubscribe from this list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field.
Or by visiting the list page at
//www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
-----
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
-----
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
-----
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
-----
You can unsubscribe from this list by sending email to ian-reeds-games-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.
Or by visiting the list page at //www.freelists.org/list/ian-reeds-games
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
