Hi, sorry to jump in like this, but I just wanted to say that I have a
relatively fresh install of vs2017 and Intellisense is working with me with
NVDA. What got broken from 15 to 17, and I'm not sure who's issue this is,
but it will no longer work with NVDA's indent reporting issues.
On Fri, Apr 13, 2018 at 10:02 AM, Ian Reed <info@xxxxxxxxxxxxxxxxxxx> wrote:
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:You can unsubscribe from this list by sending email to
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 topYou can unsubscribe from this list by sending email to
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.You can unsubscribe from this list by sending email to
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 aYou can unsubscribe from this list by sending email to
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 reallyYou can unsubscribe from this list by sending email to
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
-----
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
-----
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
-----
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
-----
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
-----
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
