Tag Archives: JavaScript

Recent Activities

Been a while since I’ve provided an update, so this will be a big one.

I won the first, and second ever GDSE Game Jams! For the theme “There can only be one”, I created Like Clockwork, a web-based bot programming game where you program your archer to navigate the battlefield, seek out, and destroy your enemies. The second jam had the theme “Time is Broken”, and I made (In &) Out of Time (works noticeably better in Chrome), a web-based adventure game. Both are open source and available on BitBucket here and here.

Asteroid Outpost could be coming along better. I created a nice dialog screen that shows who’s talking, added a new enemy spaceship that’s practically the same as the first, and started to make a new scenario. The new scenario demanded a giant super-structure, but since my game is 2D, I needed to split the new entity into 2 sprites so that it would properly draw over and under other entities in the scene. My entire engine is capable of handling two sprites for a single entity, except the current JSON format I’m using to load entity templates and send entity data to Awesomium. Now I either find a shortcut and move on, or take the time to fix my JSON. Shouldn’t be too bad, but it’s still one more thing I need to do. On the plus side, I was really happy with how quickly I was able to get a new bad guy int he game.

There have been a couple bugs in TeeVee that have been annoying me recently, and I’ve been thinking about completely redoing the UI for a few years, but haven’t made the time. This weekend, however, I finally took the plunge and created a brand new web-UI that replaces the UI portion of TeeVee. The scanning and updating from TheTVDB.com is still handled by TeeVee 1, but I plan to write two stand-alone apps that will do each of those tasks. I must say, TeeVee II is already looking way better. Not only is it significantly faster, but it’s also way sexier.

When I’m done with TeeVee II, I’m not sure if I want to release it open source or what. It’s valuable to the right audience, but my gut is telling me that the audience is too small, and none of my audience will be actively seeking out an XBMC replacement because they don’t know that it could be better. Let me be clear here, it may be better than XBMC for heavy TV viewers like myself. I tried XBMC for a few weeks, and my main annoyances with XBMC were: It’s very folder-based, lack of “favourite” shows, and it didn’t handle sleeping very well. TeeVee is file-based, so you can just download your TV to wherever you want, and TeeVee just picks it up and runs with it. It can save a lot of time if your library is large. You can select favourite shows in TeeVee, and those shows will appear above all of the other shows. I have 157 series in my database. How fun do you think it is to watch Vikings with XBMC? And the last point: if my laptop would go to sleep with XBMC running full-screen on my second “Monitor” (the TV), when I woke up the laptop, XBMC would be full-screen on the primary monitor (the laptop). Anyway, look for TeeVee II hitting the shelves near you!

Tooltips and JSON Entity Definitions

Tooltips have been on the brain, and I looked into implementing them, but realized I didn’t have anywhere to store the required data. Perfect excuse to move everything into JSON files. I’ve wanted to define my entities in JSON files for quite some time now, but I didn’t have a good reason to do it until now.

I have designed a layered JSON system where each layer overrides or adds values to the previous JSON. Currently, I have defined a base entity, followed by one definition for each entity type, then the most specific data is provided at run time when the entity is created. As I was writing this system, it occurred to me that I could write my unit upgrades in the same JSON and just apply it. So much is possible: reloading these JSON definitions on the fly, tying in the entity editor, and even networking. Everything is coming together, and I’m loving it. Now to actually implement what I set out to do: tooltips. That is my next step.

While implementing this JSON system, I came across a few issues. First was that fastJSON didn’t really want to deserialize to a generic placeholder object where I could apply the layers of JSON one after the other. I am glad I gave Json.NET a try, if for nothing else than the JObject and its collection initializer. It really helps to write C# code that looks like JSON instead of writing out a string that contains JSON data.

The second issue was a humorous fail cascade that caused the starting Solar Station to instantly disappear as the game started. You couldn’t select it, so it wasn’t a sprite issue. The creation code was executing, and all the right components were being created. You also couldn’t press Esc to get the in-game menu to pop up, odd. After some digging, I found out that it thought the game was over, which is normal if there’s no power producers in the game. Since it thought the game was over, it thought the in-game “game over” screen was already up and wouldn’t let me press Esc. Mystery one solved. So my solar station was being deleted, but why? With some more digging, the Armour was zero, so the game thought it ran out of health and deleted it automatically. The JSON showed a non-zero value for Armour, and it was loading, or at least it was being set. The setter for the Armour field had a bounds check that made sure it was 0 <= Armour <= TotalArmour. Oi! My TotalArmour was zero, at least for a brief moment while the Armour was being set. Sigh A setter designed to prevent invalid values can really throw a wrench. After loosening the setter’s rules, everything started working as intended.

In-game Component Editor

I have started work on an in-game component editor, doing exactly what I mentioned in my previous post: serializing my components to JSON, sending that through Awesomium to some JavaScript/jQuery/jQueryUI to display controls on the screen. It looks pretty slick. Here’s a short video about it:

As you can see, there’s still some more work required: certain datatypes don’t have an associated control (Vector2 and Color), the numeric sliders’ max-value isn’t fixed (it uses current value * 2), and modifications to the values go nowhere. Once I’m able to live-edit these values, this will become useful for debugging, balancing, and perhaps scenario editing.

Oh, and I may be turning into a Twit. I have started a twitter feed where I will try to regularly post about Asteroid Outpost.

Data-only Components, jQueryUI, JSON, and Networking

My components are comprised of nearly 100% data with no methods. All of the manipulation of the data occurs in my systems. Some of you may be wondering why you need to separate the logic from the data. Doesn’t it just make work and reduce encapsulation? Well… not really. Once you start working with data-only components, you notice that components are able to encapsulate an idea without worrying about the world around them, and each system handles a particular aspect of the game, one to move things, one to build stuff, one to draw, etc. Even though the data and logic are in separate classes, everything has a very clear role: Components store stuff, Systems do stuff.

After following the development of Overgrowth, watching some pretty cool development videos about live-coding and live-editing, and cutting my teeth with some near-live-coding for my web-UI, I thought to myself: “I want that!”, and who doesn’t? Adding a way to view/modify the component data for the selected entity(s) on the fly wouldn’t actually be that hard, I’d just need some web-UI controls. Googling web controls quickly led me to jQueryUI which looks amazing compared with some of the other solutions available. Since I have data-only components, I can easily wrap them up in some JSON, pass a collection of them down to some jQuery that will display the values using jQueryUI controls. When the user changes something, data would travel the other way: jQuery would produce some JSON and pass that up to XNA where the changed data would overwrite the data in the component. So what if XNA were to consume JSON from the UI in the same way it would handle it from the network? Wow, everything just clicks. JSON wins.

Starting from the beginning: I’ll have partial JSON files for each entity type that will define which components to build and any default values for those components. At creation time, I will provide value overrides for real-time values like position and rotation. Since everything is data, that’s all that’s required to construct a new entity. The same JSON used to create the entities will be used to populate things like the selection info panel on the HUD, the entity viewer/editor discussed above, and to transfer new components, or changes to existing components across the network. Since it’s just data, it’s easy to visualize. I better get the last of the logic out of my components before anyone notices.