RTS4 – WebGL

I’ve decided to move RTS4 to JavaScript and WebGL instead of some C# environment. Specifically, the game is being developed in TypeScript, a JavaScript-like language which adds common object oriented features to the language. The game is using the same “engine” as the WebPA demo, ported to TypeScript and improved with better separation between resources and WebGL interfaces, and added animation / DAE support. This move brings a heap of new abilities and challenges, summarised below:

Pros

  • Can access the game from anywhere by visiting the URL in a newer browser (can also run on mobiles)
  • Much less likely for WebGL to be discontinued
  • Built-in standard and high performance UI framework (HTML/CSS)

Cons

  • Very difficult to load external resources (require expensive upload or local storage options)
  • Mathematical inaccuracies make multiplayer and game replays much less stable, require error correction
  • Overall slower loading and rendering performance
  • Impossible to protect the game code from hackers, though security measures can be added to prevent cheating in multiplayer.

After designing enough of the game, I will likely build a native Windows version of the game as well. The current version is quite underwhelming, but can be played below.

RTS4

Play in Chrome

Advertisements

Rymdkapsel

I’ve was quite impressed yesterday by the mobile game Rymdkapsel. The game seems to follow a similar idea I was trying earlier of abstracting all the RTS mechanics away from the user, allowing them to interact with the game world through simple GUI gestures, but their implementation is much better. In fact, I think that is where this game really shines; all interactions with the game look really well polished and the sounds are very fitting.

I decided to give it a go remaking the game in XNA, and after a day, here is the result:
Screenshot of the Rymdkapsel clone (R2)
Windows (Source)
Windows Phone

The original game can be downloaded from the Playstation Store, on Android, or on iPhone.

RTS4 UI

Its been a while since my last post! I’ve been working on my study, but have recently had some time to work on this project and make some more progress. I’ve started to build some classes to load the AOM UI files. These files are XML-based with a hierarchy of “gadgets” used to display textures, text, buttons, etc.

Some things to note while writing a UI parser:
– Many hidden elements contain invalid data, resources from elements should be lazy bound, to avoid reading from data that does not exist
– UI resources should be looked up in textures2.bar, then in textures.bar
– Element bounds are always in screen-space, they are not transformed or offset by their parents rectangle
– The UI appears to be highly coupled to the engine – pressing the menu button calls “showGameMenu”, which then must unhide an element inside the same UI file, looked up by its name. These may be defined in an external xscript file that I have not yet found
– Similar to the last point, the contents of many elements seems to be driven by the engine, looking up that element by name and setting the appropriate data (ie. chat lines), other parts follow a data binding model (ie. resources)
– To load the correct image, you need to look for a [image name]_def.xmb file, check if a civilization specialization exists to be used instead, and then add .ddt to the end of the image path.

If I’m wrong on any of these points, please tell me!

Screenshot of the in-game UI displayed in XNA:
rts4ui

Screenshot with all elements visible:
ui_all

I’m too lazy to create file locating stuff, so you’ll need to update the list of install directories before running it:
Download source and binaries (170KB)

Progress Report

Progress has slowed slightly, and I’ve been mostly bug-fixing and adding GUI bindings to existing functionality. This has bought the modder to a pretty significant milestone though, it is now able to be used to mod the game! All DDT formats are now supported too.

Mod HQ now displays items in a explorer-like file browser, and double clicking items will automatically convert and extract the item, and launch your default editor. After editing, it will pick up when the file changes, reconvert the file, and add it back to the .BAR file. I’ve tested if it works correctly with AOM, and I was able to change the hitpoints of the town centre by opening the modder, clicking Data Files, double-clicking protox.xmb, changing the hitpoints from 2800 to 50, saving, and opening AoM. I then went on to villager rush and won the game pretty fast :P.

Current progress:

-File formats-
Can load: BAR, DDT, XMB
Can save: BAR, XMB
Unsupported: BRG, SCN, SCX

-Parsing-
Proto.xml
Random map scripts (.xs)

-Loading-
Proto.xml
Random map generation

-Game-
Basic environment / entity / component framework

Future work:

This functionality is split over two separate projects, with the Proto.xml parsing not currently compatible with the game simulation, and it will be quite difficult to integrate the two projects. After learning more about how the AOM engine works, I’ve realised that the current game code is far more complex and flexible than it needs to be (entirely component based), so I am thinking it may be better to recode it work how it appears to work in AOM (a super unit class that contains most of the behaviours present in the game, and smaller components for more specific functionality). The problem with this approach is that I wouldnt be able to extend the game or use the code for a new game as easily as otherwise.


Download
Also the shadow is gone for now, so that the window can be resized, runs faster, and will have better compatibility. Might add it back in later.