Thanks.
What version of Windows are you using?
I'm still on Windows 7.
I wish I knew why my intellisense doesn't work in VS 2017, because it
would be nice to upgrade my code bases and use the latest language features.
When I last tried to fix this (in January) I updated to the latest
version of VS 2017 at that time, and got a fresh copy of both the latest
standard release of NVDA, and NVDA from the master branch.
Without adding any addons to NVDA, the intellisense still didn't work
for me.
There is also a Visual Studio addon for NVDA which I tried, but no luck.
I'm sure an NVDA developer could figure it out by debugging NVDA a bit
and seeing if VS is sending the expected information, etc.
I don't have the time to familiarize myself with the NVDA code base, but
if someone knew how I could check at a lower level why NVDA is not
speaking the intelisense menus I would love to get to the bottom of this.
I could reinstall Windows which would probably fix it since it seems to
work for many others, but I definitely don't have the time for that
right now.
On 4/13/2018 8:58 AM, Brandon Cross wrote:
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 <mailto: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 <http://V8.NET>.
Unfortunately V8.NET <http://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
<mailto: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 <http://u.name> select u.name
<http://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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest
dev version of
Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this
list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev
version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list
by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of
Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by
sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of
Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by sending
email to ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of Tactical
Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by sending
email to ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of Tactical Battle
here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
-----
You can unsubscribe from this list by sending email to
ian-reeds-games-request@xxxxxxxxxxxxx
<mailto: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
<//www.freelists.org/list/ian-reeds-games>
Download the latest dev version of Tactical Battle here:
http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip
<http://blindaudiogames.com/downloads/Tactical%20Battle%20Dev.zip>
