WASD?! Watch your mouth!

Moving in 1994

TES: Arena was made back in day when the WASD key combination for movement wasn’t used much (if at all) and most movement keys defaulted to the “arrow keys”. In addition, the ability to remap the keys in a game was fairly rare too.

SIDENOTE: WASD = W – forward, A – backward, S – slide Left, D – slide right. In variations without mouse-look, “slide” is replaced with “turn”. This is pretty much the defacto standard today due to being able to control movement with the left hand and mouse with the right.

It’s been there all along

For the Arena Depixelization process, I have done a lot of “in-game” checking of textures. The controls always felt unnatural to me even when the game was popular, but I put up with it. Later when DosBox became a popular way to run old Dos games, it included an ability to “remap” the keyboard keys. So in theory, you could move the keys functions around (e.g. map the arrow keys to the WASD setup. The problem was that this mucked up the assignment of letters and makes typing words and text (such as naming spells and save games). I tried the new setup a couple of times but didn’t really “get” DosBox’s key mapping tool very well.

Left doesn’t equal Left

So earlier in May, I had enough and decided to really try and make something work. In a short period of time, I discovered that the key remapping tool in DosBox was actually pretty versatile and the method it used allowed me to employ a trick that would fix the “typing words” problem and still have an optimized control scheme.

Basically, after remapping all the keys, I assigned one key “L Alt”  as a master default key. This meant that anytime the Left Alt key was held down, ALL keys assignments reverted to normal behavior. For a game light on text input like Arena, this is a pretty elegant solution to the problem AND it works really well in the game and feels quite natural once you learn the key assignments.

I uploaded the files to the below two sites.

Moddb

Nexus

What’s this doing on an art blog

There was some graphic arts to this although hastily done and not quite as nice as I’d like it. I wanted to include a nice key template that laid all the keys out in an easy to understand and intuitive way. First, I scoured the internet for a decent picture of a keyboard (scoured = googled). After cleaning the image up a little, I added text box labels for every in-game key (including the few that I didn’t remap). Then I simply highlighted those keys with the paint bucket fill option and made all non-game keys a dull gray.

New control scheme

New control scheme

FUN FACT: There are several “new” keys that didn’t exist in the original game because the function only worked with a combination of keys before; such as there is now a long jump key as well as the regular jump (regular jump is really just hop in place), a world map key separate from the local map, a recast last spell key and slide left and right (which was only worked before by hold “.” and pressing a turn key)

All in all, it only took a few hours to get this done and now not only is it easier to test in game, but others can download this and use it for their game.

– Martin

Advertisements

A little bit of paint

This is a timelapse of me retexturing one of the Mage Guild exterior sets. This one stayed pretty close to the original and I liked how it turned out. I did later on decide to make the brick darker red for a more striking look.

I have a couple more that I made but haven’t posted. I’ll put those up shortly.

– Martin

Who’s steering this thing?

Planning

One thing I noticed recently on my work w/ Arena is that I don’t really have much of a game plan other than “finish Wall SETS then IMGs”. Considering how much project management is part of my work, I found it odd that I didn’t implement it here. After thinking about it awhile, I came up with two reasons: 1. When I’m home I don’t want to think. 2. This is my hobby so I have never been too worried about how fast or slow it goes…I just do it for fun. Incidentally, for my Torchlight project, I didn’t have this problem (well not to the same degree). In that project, I tackled one levelset at a time. I marked textures to see where they fell in the game ahead of time and work one of them till I was happy how it looked in game. Only then would I complete all the others in that level set. I even had some of the templates saved for similar creatures to minimize duplication of effort.  There was still room for improvement though. I was terrible about writing down and special techniques or tricks that I used. Because of this, if I held off and came back later, I forgot how it was done.

Mission

Realizing this now, I feel their are definite ways to plan a little more accordingly. Hopefully in the next week, I’ll enough time to work out a little design document. It might be the next post, not sure yet. I plan to work out the vision, objectives, goals, etc. It might not make too much difference but I think it will help keep me on track with what I want from this project (and I can develop the habit now so the next project will go more smoothly).

Back in the saddle

Although I haven’t been on in some time, I have been busy with the Minecraft project I mentioned awhile back. I actually completed all of the Minecraft block textures and 1/3 of the monsters. On top of that, I’ve done quite a few mods that my boys frequently use (maybe 10 or so) to include some big ones (Metallurgy, Biome-o-Plenty etc) that took more time than the original game.

I was really interested in making Minecraft “artistically” interesting. Because of this, I didn’t feel the need to yield completely to convention and try and make the blocks “look real”. The best example is probably my takes on the leaf blocks. I spent a lot of time working and testing in-game to get this artistic effect. I haven’t release it yet because I wanted to at least 100% complete with the core Minecraft textures (I still have to do 2/3 of the monsters).

This slideshow requires JavaScript.

 

What the heck is muxing?

I spent a good chunk of my free time in the first 5 days of the week experimenting with the file data for Arena. I spent some time researching and trying to decode image files using a hex editor and the internet. Needless to say, I was way over my head. I did find a few odd things. For one, I tried editing the .MNU files with random hex values just hoping for it to show up weird in the game but none of it had any effect. My presumption is that either I messed up the checksum (file verification) and the game defaulted to the artwork in the BSA or those files serve another purpose than image data. After researching more on the compressed images, I couldn’t get more than 8 bytes in before I couldn’t tell what was going on (the height and width are in the first eight). I read through some of WinArena’s source files (partial attempt at a remake of Arena) and saw the insane “muxing” that Bethesda did. Apparently, they pulled some crazy tricks to conserve valuable disk space. Remember this game came on a 3.5 floppy originally.

For extra giggles, I looked at the Arena executable in a hex editor (it’s only 171KBs). Turns out the executable is compressed too and like the image files decompresses realtime when launched (the compressed images are uncompressed in a similar manner). The header in the executable listed an old version of a compression software  called PKLITE. I searched on the internet and found a whole page of decompressing software for dos that could decompress the executable. Just curious, I downloaded one called xtract and put it in the Arena directory. Now this is a dos tool, so I had to use Dosbox to even run it. But it worked. The file went from 171Kb to 300+Kb. Woohoo (i think). I checked it again in a hex editor and saw that I could now read all the hardcoded text strings in the file. Beyond that, I had no idea how to interpret the rest. Just to test it, I ran the game and it worked just as if it was compressed. Not sure what benefit this would bring but it’s nifty to know if anyone is every interested.

After all that, I decided to get back to what I’m better at. I am now 45 of 185 SET files done. I initially thought the low resolution 64 x 64 pixel pictures would be easy but it still takes some time to get such few blocks to look good. I spend about 1/2 to 1 1/2 hours on each individual SET file trying to get the look just right. That’s the same amount of time I spend on a single Torchlight texture! Basically, I’m editing every pixel by hand. Good thing it’s fun to me 😉

Still a ways to go

I have completed 33 of 184 image “SETS” in for Arena. Each set contains usually 2-5 “tiles”.  The sets are what is used to texture walls, floors, and ceilings. That’s cover all landscaping and buildings. That still leaves “IMG” image files. Those are static objects such as barrels and trees. These come in two variants. Onces that load basically like a SET file but with only a single “tile” and meant to always be 64 x 64 pixels. The difference for the other ones is that they can be different sizes. Since they don’t have the predetermined size, that information has to be included in the file.  There are alot of those. I can manually do those but the Arenamodder .95 doesn’t support it yet so it will be slower going once I get to those (unless he fixes it by then).

Slow week

Didn’t get as much actual work done on my current project. But did make some headway organizing my previous efforts. Here are some results from my various projects (all in various states of completion).

 

Arena Depixelization Project

Stonekeep

Stonekeep

More screenshots

 

 

DarkTone

Exit to Forest

Exit to Forest

More screenshots

 

 

Toonlight

More Screenshots

 

 

Morrowind – Pinkerton’s Mod Renovation – Sea of Destiny

More screenshots

 

 

Morrowind – Pinkerton’s Mod Renovation – Dragon’s Perch

More screenshots

 

 

Early experimental runs at changing Morrowind Textures

More screenshots