Some more details about the architecture of the new game.

Over the last few days, I had to decide what would be the max size of the game map.
I think it will be either 256x256 tiles, or maybe 384x384.
For those familiar with Eternal Lands, a 256x256 tiles map is 4 times bigger than Whitestone, which is 128x128 tiles.

A 384x384 map would be a little more than 1 square KM. It will take approximatively 10 minutes to go from one end to another, and about 15 minutes to go in diagonal.
Of course, in the actual game it will take more than that, since there will be all kind of obstacles, monsters, and various other detours such as quests.

Any size bigger than that would be overkill for the following reasons:
1. It would take way too much time for someone to create.
2. Would take a lot of memory.
3. More than 100K 3d objects would be required, which would slow down the game too much.

In Eternal Lands, there are 2 kind of maps: Inside maps and outside maps. The inside maps have a constant ambient light, and, obviously, there are no sun shadows, nor day and night.
In this game, since there will be only one map, a mechanism had to be devised to allow indoor places (caves, castles, etc.) and outdoor maps.
This issue is addressed by various script functions and callbacks. For example, when the player enters an area which is a cave, we do the following things:
a. Set the game to render the map as if it is an inside map.
b. Change the ambient light level.
c. Hide all the 'roofs'.

The roofs will be part of a group. A group holds a list of 3d objects (their name, not their instance).
We can have different groups, such as doors, roofs, vegetation, and so on.
The scripting language will have a function to create groups and add objects to groups. There will also be scripting functions that allow you to hide or show all the objects in a group. For example, hide all the roofs, remove all the trees, and so on.
All those functions will be an area effect, so they will only affect a specific area. No reason to hide all the roofs in a map, if you only enter a house. It's time consuming, and can be impractical as well.

VWX robot kit

I just got one from RadioShack, they were 'on sale' as they put it, where the price was reduced from 300 to 150 USD.
I've eyed that kit ever since last year, but I thought 300 bucks is way too much for such a kit. I mean, while that kit includes a lot of stuff, it's just the basic thing, and if you want to make a real robot that is autonomous, you'll need a lot more money. For example, the 'programming kit', which is really just a wire and a CD, cost 100 USD.
Now it is on sale for 50, but you can't get it from anywhere, because it's been sold out. You can grab one off eBay, for about 75 USD (shipping included).
I was trying to find a DIY solution to that kit, but unfortunately it's not only a cable, but has an IC in it, which I have no idea what it does. And from doing some online reading, it seems that the kit won't let you use any advanced programming techniques. If you want to write your own C programs, you'd have to purchase a compiler, which is not free at all..

I didn't do anything with it yet, I plan to toy with it a little this week. What I would like to do is use some solar panels that I have, and make a solar bot that moves very slowly, but ideally it should be able to climb hills and move through grass. I might have to buy the tracks kit, which, on sale is about 25 bucks or so.
Anyway, once I do something cool, I'll post some pictures and details.

Where do you draw the line between copyright and fair use?

Let's assume a friend asks to borrow your screwdriver. Is it legal to do that?

Now, assuming that the previous answer is: "Yes", let's ask another question: What if that friend asks if he can borrow one of your legally purchased DVDs? Is that legal?
Why wouldn't it be legal? You purchased a good (that DVD) so just like a screwdriver, you should be able to give it to your friends.

But what if you made a backup copy of that DVD? Under the DRM laws, you are able to make a copy, just in case the original gets bad.
And while the original DVD is not currently in your possession, you decide to watch the copy. Is this illegal? Maybe.
But what if you don't watch that copy while your friend has the original DVD? Then no law would be broken, as the DVD (and it's copies) are not simultaneously used.

To go a little further, let's imagine that your friend is an evil pirate, according to RIAA, and he duplicates that DVD and gives copies of it to his friends. Is that your fault? After all, he did that without your knowledge and permission. Should you be legally responsible for what your friend did?

In a similar fashion, if you place a song on a p2p network, and do NOT listen to it at the same time the people that downloaded it listen to it, that should be ok, following the DVD analogy, correct?
And if they make copies of that song, and in turn they make it available to others to download, why should you be responsible for it? You can't control what they do with the song, just like you can't force your friend not to copy your DVD.

See where I am getting?
Whenever *AA tries to extort people into a 'settlement', they threaten with a lawsuit. They want the person that has uploaded the original song (or even those who just share it) to pay for the damage caused by an unknown number of people who downloaded the song from you, and redistributed it.

Now, if *AA would ask for a reasonable compensation, based on how many songs you have that you do not own, most of the reasonable people would be OK with that.
Say, you have 1K songs that you didn't buy, so 1K USD would be a fair amount of money to pay, given the fact that you can usually buy songs for 1 USD a piece.
But paying for 50 times the value of those songs, because they assume, without any proof, that each song has been downloaded 50 times? That's really unreasonable, and I highly doubt a sane jury would award such a compensation.

Perhaps it is time for people to stand out for themselves, and tell the RIAA negociators: "Go fuck yourself, asshole!". I sure would.

The Eternal Lands economy

Players have always complained about the economy. I guess that's normal, since people in rela life complain about the economy as well, and from what I've heard, other games don't do much better either.
One of the problems is that, according to the majority of players, there is not enough money. Another complaint is that there are too many usless items, which can not be sold to NPCs (that's due to the fact that we don't want too much money to enter the game that easy). Some say the monsters drop too much good items. Others say that the byproduct of their work (say, a sword) is cheaper to sell at an NPC than the sum of the components, if you were to buy them from an NPC.
In reality things are not so bad, and a lot of money can be made by intelligent and determined people. Some player who is leaving posted a very interesting true story about how he and his guild made a lot of money in just months. Here is that thread if you are interested.

What I have proposed as a solution to make some relatively useless items usable was to have some priest NPCs where you donate a certain amount of items every month, and your entire guild gets a bonus that month. Say, you donate 500 broad swords, and everyone in your guild gets a +5 attack bonus.
I posted that idea on our forums, but many players were unhappy with it, and since it was time consuming to implement, I've just decided to cancel it, and work on more important things.

What I will do soon is just reduce the monster item drops by half, and slightly increase the money drops, to compensate for the relative lack of money in the game.
Then I have some other evil idea with some of the crappy items in the game, but for the time being that idea is a secret. I will reveal more details once it's implemented.

Some more technical details about the new game

In this post I am trying to explain some of the ideas behind the new game I am working at, so maybe other less experienced game developers can learn something, and more experienced game developers can offer some feedback.

The goal of this new game is to have a scripting engine capable of creating games such as Ultima 7.
For those who didn't play Ultima 7, it's an old game. About 14 years old.
While the game is not playable on modern computers due to the fact that it used some more or less nonstandard memory manager, there is an effort, which is quite successful, to remake the game, so that it can be played on a variety of platforms, such as Windows, Linux, Mac, and even some Linux powered PDA. For more information, visit the Exult project homepage.

Ultima 7 had something very innovative for the time: An engine that had an embedded scripting language. At that time, however, there were no such thing as mods, so they didn't provide any information about their scripting language, or about their data files.
That scripting language, referred as Usecode, was responsible for most of the ingame logic. It was used for quests, for NPCs, for teleportation, weather, and so on.

Since my goal is to make a 3d game that is in many ways similar with Ultima 7, it makes some sense to look at how they did it, and do it better (afterall, we are 14 years later, many things have changed since then).
Yesterday I've tried to look for example and documentation on that Usecode, but couldn't find much. What I did know, for example, was that they use "eggs".
An egg is a trigger, which is activated by a variety of factors, such as if you are near or on it.
Such eggs were used to trigger various events, and set flags.
For example, an egg was placed on a door, so when you enter that house, a script is executed.
This is all good and nice, but the problem is, sometimes a house has two doors, or maybe you teleport in that house. If that happens, the egg is not triggered, and the game can be ruined, as the right flags are not set. Which DID happen in Ultima 7 and Ultima 7.5, causing some really annoying bugs, some even critical, not allowing you to finish the game.
Needless to say, that is very bad, and should be avoided at any cost.

The way I am avoiding it in the new engine is setting areas, rather than eggs. An area has the advantage that no matter how you enter in it, the code associated with it is triggered. Another advantage is that you can have an area be triggered by various factors, such as when you enter it, when you stay in it, or when you are leaving it.
Unlike an egg though, you can't call a script when you are NEAR the area. So for example, if you want a monster to spawn as you walk on a road, an egg can be useful. Similarly, sometimes you might want to trigger some code ONLY when you enter a place through a specific route (say, a door, rather than an illusion wall).
Which is why I am going to implement the eggs as well, but they will be used for different purposes.

Most of the area code has been finished, the next thing I will work at is finishing and testing the area code, as well as implementing those eggs.
The I will have to work at the combat system, and also at the items management system.
Unlike Eternal Lands, this new game will allow you to place items on the floor, rather than in a bag. In EL, the items automatically went to bags because putting them on the floor would have generated a lot of extra bandwidth. For a single player game, there is no bandwidth issue, and it can be easier and better for the player to place items wherever he wants, and it can even contribute to more complex quests, where you have to, for example, set a few items on various locations in order to open a door.
Because this new game is a 3d game, unlike Ultima 7, the code for putting items on a table, for example, is quite complicated. It will require some collision detection with the object under the cursor, to determine the Z position of the item. And only some items will allow placing objects on them, such as tables, stoves, counter..
That will be pretty hard, as I don't have that much experience with 3d collision detection. I hope I'll find someone to do that code for me :)

Bugs with the update

Tuesday we have updated the server to include the new summonable monsters. Due to the fact that it wasn't tested, there were a few problems.
The first problem was that some of the ingredients required for summoning the new monsters were not tagged as a 'resource' by the server, which has caused them not to be in the Manufacture window, making it impossible to summon them.
This problem has been addressed imediately, and was fixed in 1 hour.
Another bigger problem was that the Pawn script (the script that powers most of the NPCs and quests) has been updated to include a quest that wasn't properly implemented and tested. I didn't know that has been commited to the CVS, so that quest had inadvertently apeared in the game. This resulted in some people flags being set in the wrong order, so now, even though the quest was fixed, they can not complete that quest.

The main problem though was that some of the new monsters didn't have summoning specific code in their AI routines, and that caused them to act as normal monsters... attacking players and stuff. A few newbies died because of it.
After people reported the problem I told everyone not to summon buggy monsters in populated, non PK maps, until the problem was fixed.
Now everything works fine, except for some people that got their flags messed up and can't finish that quest. Not really a big deal, it was a newbie quest anyway, but it made me reconsider having people implementing quests.
I think I'll just stick to do it myself in the future.

Generic EL development

Friday I got my 50F capacitors :)
I put them to good use, they are in a big RC solar powered card, and it works nicely, although there are some additional modifications I have to do. More about it in another post.
The single player game I am working at is going well, finished with basic NPC dialogues implementation (so basically now you can chat with an NPC using the Pawn script).
In the following days I will have to add more functions that are available to Pawn, a few more callbacks, and all kind of other stuff I don't feel like talking about now.

Friday we had an EL server crash in the morning. Learner 'fixed' the problem and restarted the server, but the fix was more of a hack, we'd like to see what is the root of the problem. The annoying thing is that we had that bug a while ago, and we fixed it, which is kind of strange. We'll have to do some more tests and determine the exact cause. But hopefully, the checks Learner placed there should prevent other crashes.

Today I came out with an idea that pretty much everyone likes, which is rare this days. I mean it is rare for everyone to like an idea.
You can read more about it on our forums, but in case you are too lazy to click the link, here is the short version:
Use some low end weapons to summon various monsters. This is good for the fighters, because they can sell their drops to players. It is good for the manufacturers, because they can sell their surplus to the summoners. And it is good for the summoners because they can summon more stuff, and get more exp.

I am going to start implementing this today. It is trivial to implement, but just like any new formula, a lot of boring work on my part is necessary (editing loads of files).
If everything goes well (that is, I don't get bored to death and procastinate a little) they should be available tomorrow.

The first step in the new game has been achieved.

Or maybe the second step, the first being removing the non essential stuff from the EL client.
Anyway, right now I've managed to embed the Pawn script to the client, and add an NPC from Pawn.
Unlike the EL server, where an NPC is added by specifying all the details such as shirt, pants, noots, actor type, name, and so on, the single player version is slightly different.
There is a list of NPC types, such as rabbits, humans, elves, orcs, and so on. Each entry defines a type, and the following format is used:

[npc]
name: `Test npc 1`

actor_type: 1
shirt: 1
pants: 1
boots: 2
head: 2
skin: 3
hair: 3
shield: 0
weapon: 0
cape: 2
helmet: 0

portrait: 2
str: 30
dext: 20
intelligence: 15
luck: 8

affiliation_1: 2
affiliation_2: 1
affiliation_3: 7

unarmed_skill: 20
sword_skill: 15
staff_skill: 10
hammer_skill: 2
axe_skill: 3
[/npc]

[npc]

This format is still in the early stage, so things can change. But the idea is that all the NPCs* are defined in that file, even the NPCs that are unique such a specific person in the game, rather than a generic thing like, say, a rabbit or an orc.
So to add an NPC from small, I just have to call a function:
add_npc(npc_type,x_pos, y_pos,z_pos,z_rot,status)

*By NPC I mean anything but the players, including animals, monsters, and computer controlled people that give quests and stuff.

The next thing that I will work on is to be able to actually chat with some of the NPCs, so that they can give you quests and stuff.
If I am not lazy, I might finish that tomorrow, as it is pretty easy to do, especially since I've done it before on the server.

The Pawn (former Small) scripting language.

Pawn is a very nice scripting language, which we use in our server. It allows us to write the quests faster than if we'd write them in C, and some volunteers can write quests without being given access to the server source code.

One good thing about Pawn is that the syntax is very similar to the syntax of C and PHP. It is a typeless language, which means that you can not assign a type to a variable (such as char, short, float). Instead, each variable is a 32b integer (or 64b on a 64b machine).
Because the syntax is C like, pretty much any C programmer can learn it in just a few hours.
But because it doesn't have pointers, types and classes, beginners can learn it in just a few days.

The Documentation:
Pawn comes with two PDF manuals, one for the person who is going to embed it in an application, and the other for whoever wants to learn the language itself, without being bothered by the unnecessary details of embedding it.
Both manuals cover everything that needs to be covered, so you will not need to spend hours googling for tutorials.

Pawn is a compiled language. That is, it has a compiler that translates your Pawn code into its virtual machine code. The advantage is, of course, the execution speed. Interpreted languages are pretty slow, compared to compiled languages.
To make things faster, you can use a highly optimized JIT VM that is written in assembly. It works on Windows, Linux and FreeBSD, but only in the 32b mode. The assembly version is about 10 times faster than the C one.
The C virtual machine can be used on more operating system, and even on some embedded devices without an OS.

The interaction beteween the host program and the Pawn script is bidirectional; the script can call native C functions (via wrapper functions) and the native code can call the script routines. Furthermore, public variables (from C) can be accessed by the script.

Compared with other scripting languages, Pawn will give you the following benefits:
a. Easy to learn.
b. Very lightweight.
c. An X86 assemby virtual machine is available so the speed of the compiled script is close to a natively compiled language.
d. Easy to embed and expand through C functions.
e. Excellent documentation.
f. Familiar syntax (for most of the programmers).

The license:
Pawn comes under the zlib license, which is as liberal as it gets. You can use it in commercial programs, without having to pay anything, and you can statically link to it without having to reveal your source code.

If you are like me, you would like to see a sample of the syntax, so here is one example, from the official package:

/* word count: count words on a string that the user types */

main()
{
print "Please type a string: "
new string[100]
getstring string, sizeof string

new count = 0

new word[20]
new index
for ( ;; )
{
word = strtok(string, index)
if (strlen(word) == 0)
break
count++
printf "Word %d: '%s'\n", count, word
}

printf "\nNumber of words: %d\n", count
}

strtok(const string[], &index)
{
new length = strlen(string)

/* skip leading white space */
while (index < length && string[index] <= ' ')
index++

/* store the word letter for letter */
new offset = index /* save start position of token */
new result[20] /* string to store the word in */
while (index < length
&& string[index] > ' '
&& index - offset < sizeof result - 1)
{
result[index - offset] = string[index]
index++
}
result[index - offset] = EOS /* zero-terminate the string */

return result
}

As you can see, you don't have to terminate your instructions with a ";", akthough the compiler won't mind if you do so. However, empty statements after an if, such as: "if(variable);" are ignored.

If you would like to learn more about Pawn, visit the official website: http://www.compuphase.com/pawn/pawn.htm

The bottom line is, if you need a C like, lightweight, portable scripting language for your applications, give Pawn a chance, and you won't regret it.

The fun of adding new items to the game

More than 1 year after the magic weapons were introduced to the game, I came up with the idea that they should finally be manufacturable by the players.
Actually, the idea came a while ago, which is the reason I have implemented the modable weapons, which are a byproduct of the weapon manufacturing process. That is, there is a very small chance whenever you make a weapon that you will obtain a modable weapon, rather than a normal one.

But anyway, in the past few days I've worked at their formulas and knowledge books, and now some of those weapons can be made (that will take effect on the main server once we restart it, probably tomorrow).
Adding new manufacturing formulas is a very simple, but extremely tedious process, which I am going to explain here:
The first step is creating the knowledge required for the new formulas. This means editing the knowldge definition file, and adding entries for each knowledge type.
The second step is editing the item definition file, to add the new books which store that knolwedge.
The third step is adding the manufacturing formulas to the manufacturing formulas list, which is a big pain in the ass, because you have to crossreference it with 2 files (knowledge file and items file).
The next step is creating the definition of those new books into the server code, using #define.
An example would ne: #define ITEM_BOOK_OF_SWORD_OF_FIRE 420
420 is the index in the items file for that item.
Finally, those books must be somehow made available to the players, either via NPCs, monster drops, harvest events, or a combination of those 3. Of course, we could be evil and not make them available in the game for free, but only via our online shop. However, I don't want that, we already are making a decent amount of money by selling what we sell now, and even though our special swords won't sell as good now that they are manufacturable by everyone, we feel that it is in the best interest of the community to have those books obtainable in the game.


I am not going to say which method[s] I am using for those books, so the players will have to find out for themselves.

Anyway, we hope our players will enjoy the new addition more than I enjoyed working at them :D It has been a huge pain in the ass, it is one of the most boring things someone can do.

Solar/capacitor powered RC car.

As you can see in my previous post, I believe that the super capacitors are possibly the way to go with the future cars. To test my theory, I've moded a very small RC car to use a capacitor instead of a battery.

The results are pretty good, and the car moves for an estimated 20 meters. I can play with it for about 2 minutes before it runs out of juice, while not in the sun.

Except for the smaller run time, the capacitor version is much better than the battery equivalent, because the battery was 1.2V @80 mAh.
This capacitor, while rated at 2.5V, the open circuit voltage it can store is over 3.6V . So basically it provides (in the beginning) 3 times more voltage than the battery. I was a little afraid this might burn the motor, but since the cost of that car is about 10 USD or less that was an acceptable risk.

It turns out that the motor was quite happy with 3.6 volts, and the car was so fast that it could even climb on the kitchen carpet (I was running it on linoleum). With just a battery, it can't really do that.
The turns are very abrupt, and the can can stumble over itself, and turn upside down. Since this won't cause any damage, I think it's kind of cool.

One thing worth mentioning is the fact that a capacitor, unlike a battery, will drop it's voltage linearly. Which means, after half the power was used, the voltage is also halved.
A battery, on the other hand, doesn't drop it's voltage (much) until it's drained.
That means that only 2/3 of the capacitor power can be used, after the voltage drops under 1.1 volts the car it's not going to work.

Ok, enough for the theory, now let's go into the construction details.
What you will need:

a. A small RC car. You can find them in a local toy store, Radio Shack, eBay, etc. For example, you can get 4 of them and free shipping for 29 USD, from this guys.
b. A super capacitor, preferably 10 Farads or more. They are kind of hard to find, I got mine from a broken digital camera, but this company has some nice selection for affordable prices: www.alliedelec.com
Notice how my capacitor is flat, and the capacitors here are round. A minor inconvenience, but shouldn't affect the performance of the car.
c. A 3V solar panel. I highly recommend a flexible one, they are very lightweight, and being flexible you don't have to worry about them being damaged if the car crashes. Some good source is this company, although you might be able to find them cheaper on eBay.
d. Soldering gun/iron, soldering supplies, and some wires.
e. Glue, some screwdriver, wire cutters, etc.

Getting started:

1. Take the RC car cover off. It's just getting in the way.


2. Open the battery compartment (bottom) and remove the battery. You might want to put it aside for other projects that need small batteries.

3. Solder two wires on the bottom, where the battery terminals were. The polarity should be marked on the bottom.
4. Glue the capacitor on the back of the car, and connect the wires from the battery compartment to the capacitor. Pay attention to the polarity of the capacitor.
5. Glue the solar panel[s] to the capacitor, and connect another set of wires from the solar panel[s] to the capacitor.

After everything is completed, turn on the RC remote (some car models will leak a lot of voltage while the RC remote is off) and place the car in such a way so that the sun shines on it. If no sun is available, you can try to recharge it from a light bulb, but be careful, if you place an incadescent light bulb to close it might damage your solar panels.
A multimeter would be very useful to determine when the car is fully charged (a voltage of over 3 volts it's good, 3.40 is better, but some capacitors might not be able to charge that much).
With one flexible solar panel (3v, 25 mAh) it should fully charge in about 20 minutes, under the sun.

That's it, now you are ready to play with your car.

The reason there is no diode between the solar panel[s] and the capacitor is because the car itself will drain all the voltage if idle, as they do not have a on/off switch. Another reason is that a diode will lower the voltage by about 0.6V, and you want the capacitor to be as charged as possible.

Let me know if you have any comments, questions, etc.

Trucks, trains and automobiles

In the last few years, we hear more and more talk about hydrogen and ethanol as fuel for the cars.
Those two fuels are cool, but the problem is, they do not really come from renewable sources.
Sure, the hydrogen can be extracted from the water, but it is inefficient, and it has to be compressed. It requires much more energy to make it usable in a car (that is, extract, compress and distribute it) than the energy used by the car. That energy, unless created by renewable sources, is energy wasted.

The ethanol has to be created from living organisms, which are also non renewable.
For example, the plants extract nutrients from the soil, which means that you can not plant them over and over again on the same spot, not at least without refertilizing the soil. In addition to that, plants do need to be taken care of (plantation, irrigation, harvesting), which makes them not really suitable for powering vehicles.

So long as the oil reserves do not run out, and the gas can be bought for a resonable price, I don't think there will be any major shift in the way we power our vehicles.
However, given the fact that the oil is finite and not really the most renewable thing in the world, I believe it is the time to focus on alternatives.

Electric powered cars are the future. They are quiet, efficient, and non polluting. They seem like the best choice, but for some reason they really not really used.
Why? Because for the time being the batteries have a few problems: They are heavy, expensive,
slow charging, and have a limited life span. The life span is different depending on the chemistry type.

For example, the lithium ion batteries have about 1K cycles (charge/discharge) but they do get damaged in time, even if not used. They are also not really happy about being exposed to heat, which is the major killer. If they are charged at about 40% and stored at 20C, their degradation is about 5%/year. However, under normal circumstances, they are exposed to higher temperatures, which considerably shortens their lives, so in 3 to 5 years their charge is drastically affected, to the point where they need to be changed.
On the plus side, they offer an excellent power density, and they are relatively enviromentally friendly.

The lead acid battery, present in most of the automobiles, is pretty cheap but it has quite a few cons:
It gets damaged if discharged under a certain voltage (about 10V for a 12V battery), which prevents using the full available power.
They are heavy and offer a poor energy density compared to the Lithium Ion type.
They contain lead, which, if not recycled properly, presents a big environmental problem.
High (or low) temperatures will considerably shorten their life span.

Two other chemestries are the NiCd and NiMh, which are, in terms of energy density,
in between the lead acid and lithium ion.
The NiCd has toxic materials, low energy density, and suffers from the memory effect, but it offers more cycles (sometimes more than 1K, if used properly).
The NiMh batteries have a higher energy density than the NiCd, are more environmentally friendly, their memory effect is less obvious than the NiCd type, but they have less cycles (about 300 to 500, depending on how they are used).
For more information about batteries, visit www.batteryuniversity.com, which is the site :)

As I've mentioned before, the reason electric power vehicles are not really used is because the batteries are expensive, they take a lot of time to charge, and the autonomy of the vehicle is relatively small (about 200 Km at most, but usually less than that). While the electricity is very cheap, compared to oil, the fact that you have to change your batteries every few years makes such vehicles inefficient, at least for the time being.

So, what is it to be done?
Some are focusing on fuel cells, which are some devices that can convert hydrogen (and sometimes alcohol) into electricity.
The problem with the fuel cells is that they have (at least for now) a limited life, they are expensive since they need platinum, and they still need hydrogen, which, as explained in the beginning of this post, it is not so efficient to extract, compress and distribute.

One technology is relativelyoverlooked, at least for the time being:
The capacitors (or, to be more precise, the super capacitors).
The super capacitors are a new technology, which allows REALLY high power densities compared to the traditional capacitors, but lower than the batteries.
For now, they are also pretty expensive. Other problems include that fact that they store a low voltage (about 2.5v), which means you have to connect them in series, which requires some additional circuits, in order to prevent them from getting damaged because of inequal charge.
One good thing about them: they can be charged really really fast, in a few minutes, rather than hours (which is typical for the batteries). They can not be overcharged, which is a another good thing, and they have a practically infinite number of cycles (more than 100K charge/discharge cycles).

A car powered by capacitors would have a limited autonomy, maybe 20-30 Km, possibly more as we develop more efficient motors, lighter materials and better capacitors.
This problem can be remedied in a simple way: On road charging stations.
For example, the roads would be equipped with some wires, so when a compatible car is over them, a dialogue is initiated between the card and the charging station. An RfID chip can send
the ID of the car to the charging station, which starts pumping electricity in it, counts how much electricity was pumped, then at the end of the month you get the bill in the mail.
For your convenience, those charging stations could be placed at busy intersections, so while you wait for the green signal, your car is automatically charged, without any intervention. A 30 seconds stop could charge your car for another few kilometers.
So no trips to gas stations, no hassle to distribute the fuel all over the nation, no environmental impact.
Sounds good, no?

As a possible improvement, solar panels can be placed on top of the car. A van type vehicle can accomodate perhaps 5 square meters of solar panels, and at an efficiency of 30% (achieved in the lab) that means about 1.5 kWh of power. Not bad at all.

Tomorrow I will demonstrate the solar powered/capacitor car, with pictures and everything (right now it is charging in my window) :)
It's pretty cheap to build, and you can make one in less than two hours, for 20 USD or less. The parts can be ordered online, and perhaps even found in local stores.

Some considerations for the single player engine

 One of the most important decisions were whether or not the engine, and scripting, implicitly, should support multiple maps or just one map.
Now, each method has some advantages and dissadvantages that had to be properly considered.

The pros of multiple maps:
1. Smaller loading times.
2. Slightly less memory footprint (not a big deal with the caching algorithms we are using).
3. More versatility.
4. The overall maps (like a paper with the landscape) would be more easy to manage, since your location can be better pinpointed in  the local context (more accuracy).

The cons:
1. Players usually don't like loading times (an initial loading time is OK, but additional loading times while changing maps are not so great).

2. Much harder to implement. For example, say we have some actors (NPCs) which go 
to work in the morning then come home in the evening.
Now, what happens if you leave a map during the afternoon, and come back at night?
How would that NPC move to go home? It would need that old map in the meory as well, to calculate the path. Some cheating can be done, to teleport it home if you return during the night, but what if, say, you place some traps on their way home, to kill them? If they teleport home, they would not trigger those traps.

3. Similarly, the monsters would be in the same position where you left them, during map switches, because having them switch maps and walk in new maps would be pretty difficult.
4. Saving and loading the game would be much more complicated, as all the maps should be saved as well, since they can be modified.

In the end, I have decided to go with one map per game. The map would be pretty big, perhaps 4 square kilometers. Yes, it will take a lot of memory, but then again, modern computers have at the very least 512 RAM, and I estimate the game would be pretty playable with 256 MB of system RAM, possibly less than that.
Which is not that bad, considering that during some Battlenet custom games, the Warcraft 3 client run out of memory on me (no swap, about 1GB of free memory).

Server update

Last night we updated the server, and so far no problems were found with the merchant NPCs. However, it is premature to declare that everything went as expected, because if there are problems they will most likely happen in the following days, after a guild has aquired an NPC, and starts selling items.

Meanwhile, my "single player EL" project is going along fine. Yesterday I've managed, with some help from Learner, to make it display a map, the HUD, and one (the) player.
You can't do anything for the time being, just rotate the camera and zoom in/out.
Now I am trying to adapt the server path finding algorithm to the client. I am using an older path finding algorithm, which I've wrote about 3 years ago and has been in the server until last year, when Learner wrote a more efficient one.
If I don't run in unexpected complications, in a few days I should be able to have stuff moving around a map, but it depends on how much time I have available, how lazy I am, and various other factors.

The update today

Having tested the Guild Merchant NPCs for about a month now, I am resonable confident that there are no exploits or major problems with them, so they will be added today in the game.
A few new manufacturing formulas will also be added in the game, mainly for some of the new teleportation rings. We have also lowered the price of the new teleport rings to 300 - to buy and 150 - to sell.

Meanwhile, I've got the forked client to compile and link, and I will be working at making it functional (that is, display a map and the player).
I will post some screenshots once this is done.

Forking the EL client, continued

The client forking is going on well, although it is slightly more difficult than anticipated.
What I am doing now is basically removing the multiplayer spect of the game, along with stuff such as the chat tabs, skills windows, encyclopedia, books, and many other functions that do not really belong to a single player game.
Obviously, removing stuff is easier than adding new things, but nevertheless it's still a lot of work.
Whenever a file is removed, there are compilation issues because other files rely on the file that has been removed, so a lot of code reviewing is needed.
Yesterday I've managed to get a trimmed down version to compile (but not link yet), and right now I am in the process of trimming down a little more, then make it actually link.
After this is done, I will clean more of the code, such as removing some of the #defines, left over functions and variables, and so on.
Then, a preliminary test will be needed so that I can load a map and a few NPCs, and once that works as expected I will have to embed the Pawn language, rework the inventory menu, and various other trivial but time consuming tasks.