SpectrumShock Redux

So many times I’ve started posts on this blog by apologising for not updating for a while. So why break a habit? Here’s another! 🙂

Over the past few days I’ve been working with Tim (whom I’m working with on the Dungeon Runner) on some rapid prototyping of a (sort of) new version of Spectrum Shock (a game I developed several years ago using Torque2D). This time I’m working in Unity and it’s coming together at a very rapid rate as you can see below.

I started on Thursday evening, and this first video was from Friday

This video was from Saturday.

You’ll notice in the second video that the environment is “tipping” around, this is matching the orientation of the iPhone6 (With relevant scaling) that I’m playing it on. It really adds quite a bit to the overall feel of the game.

I’m using Aron Granberg’s AStar project which you can find here: http://arongranberg.com/astar/

DPSDisplay released on Curse

The WildStar Addon I mentioned a while back now has a project page on Curse (as I write I’m just waiting for the download itself to be moderated).

Currently it supports all the features as shown in my last post on it, but I plan to add saving and customizable time-windows etc in the future. It’s “fully functional” now, so it seemed worthwhile to release it now rather than waiting.

On Curse it is found here.
And you can also grab it from GitHub here.

 

Update July 11th

D’oh. Turns out there was a bug on Curse’s end with file uploads (I confirmed one they knew about and found fresh one for another for them – I bet they love me…) that meant the files weren’t downloadable. I had no idea as I was off on holiday in Turkey. Thankfully all is sorted now, and 40 minutes later I’m seeing downloads already!

Thoughts on Swift (Part 2)

This is part 2 of my “Thoughts on Swift” post. See part 1 here

Immutability inconsistency

Swift has some really weird behaviours when it comes to what counts as immutable and what doesn’t. The following twitter post explains and demonstrates it very well. Note: These are *designed* behaviours and are functioning as expected as per what is in the language guide. Ugh…

 

A Couple of Quick Additional Oddities

  • Enumerations can have methods etc. Simply feels a bit odd to me, but probably ultimately very useful given the right circumstance. I expect abuse of this feature to be prevalent 🙂
  • Swift has the concept of Extensions (Categories in ObjC) and although I use features like this, I always feel like I’m maybe breaking the second principle of SOLID, namely, “Open for Extension Closed for Modification”. I mean this in the sense that when you are adding functionality to an existing class without deriving from it, you ARE modifying it and not extending it. i.e. The *original* class now has a different set of behaviours to what it had before – calling it an “extension” is a slight of hand.

Summary

A key part of any language is not so much to do with the syntax and features that it offers, but more to do with the adoption of said language by developers. A particular language can live or die depending on what libraries are available for it. This concept spreads to toolsets as well as languages, just think of the many “out of date” scientific tools that are still in common use. Sometimes systems become so large or so “embedded” in a particular industry/market that it requires seismic shift in that particular industry to jolt it into action to update and/or move away from it.

Despite my initial misgivings of Swift (these posts have been on the negative side), I know I’ll end up developing with it. The primary reason for this is that I can well imagine ObjectiveC is going to have little-to-no real development on it moving forward. I however don’t anticipate anyone bothering to do rewrites of their ObjC libraries to Swift, as Apple have made it so there is neither a benefit nor a penalty for doing so.

This is smart and should drive adoption of Swift at a pretty decent rate, at least amongst developers inside the Apple ecosystem already. It doesn’t do much to entice more in I don’t think.

I think, for a while at least, I’ll probably sit on the side and watch Swift develop before launching into it “full-on”. For the moment, let’s enjoy seeing recruiters starting to post job ads asking for 3+ years Swift experience eh? 🙂

Thoughts on Swift (Part 1)

WWDC, it always serves something up for you to think about, worry about, be excited about (or complain about?). This time around we got the unexpected news of a new language being released, Swift. Naturally I was interested in this, so I’ve done some reading on it and summarised some (This is heavily truncated compared to what I initially wrote) my thoughts below.

 

Why?

I have to admit, I was rather surprised to see a new language being announced. I still am to an extent. I’m not really sure why Swift exists at the moment. I mean, is it a tacit admission that Objective C has faults and it’s easier to develop something from the ground up rather than try and “morph” ObjC into something new? Or is there something else going on here?

A friend of mine posited the following as a potential reason for the language’s existence:

[Swift is] Apple’s apology for Objective C’s syntax.

He might have a point… ObjC certainly can feel like an alien environment when you first approach it, unless you happen to have a very particular path of experience. However, given that ObjC supports standard C syntax (duh) and you can run your code through as Objective C++ to allow line-by-line ObjC and C++ it feels that there is clearly space in both the language and the compilers to support further morphing of ObjC rather than something entirely new.

There has been a fair bit of progression in Objective C in recent times, obviously the presence of iOS has accelerated this immensely, the growth of the OS X market has played its part too. Prominent areas of development are the inclusion of code blocks and technologies such as ARC (Automatic Reference Counting) – these have both made their way into Swift in one form or another.

 

Pros and Cons

Swift simplifies a lot of common tasks, and it does them in a syntactically sensible and logical way. Iterating through ranges by using the Range operators in (1…5) is a welcome addition. Implicit typing is certainly part of the coding zeitgeist and for when you still need explicit type declaration, you do it in a JS-style way var 5.5 : float.

Optional chaining as a way of avoiding forced unwrapping is a great way of slimming down code. As daft as it sounds I’m actually quite happy that they used a question mark as the way of marking this up too, it feels “correct”. What I don’t like is how Swift is stricter on what counts as a boolean return (e.g. for use in an expression for an if statement) than what other languages would be. By way of an example, this will produce a compiler error:

let i = 10
if i
{
// code here
}

I get the logic in forcing things to be a boolean response, I just don’t like it.

Swift still doesn’t solve the main problem that has stopped ObjectiveC pushing itself into the top-tier of languages in terms of adoption, it still locks you into the Apple ecosystem. In fact, not only does it not succeed in solving this problem, it doesn’t attempt to solve it. It’s locked itself into the Cocoa frameworks tightly.

 

See part 2 of this post here.

WildStar Addons

I’m not afraid to admit it, I’m a big Wildstar fan – I’m literally bursting at the seams waiting to play it when it launches (to Pre-Order customers) later this week. In fact, I got into it so much during the Closed Beta that I looked into the Addon system that comes with it.

By default, every install of Wildstar comes with everything you need to get started with Addon development:

  • Houston is simple IDE that allows you to design your GUI (form based) and write your scripts.
  • Apollo is the API to Wildstar, written in Lua.

It’s a nice enough system, a little basic but it does the job. The real issue is less with the tools and more with the lack of documentation. As such, most of my learning was scraped off other users posting things on forums, or looking at existing scripts. As useful as these things can be, a formal set of API docs needs to come, and come soon. One saving grace is that *all* the Wildstar stock GUI stuff is written using the exact same tools they offer to you. No private API methods you don’t have access to, no limited permissions etc. You get it all.

Enough ranting, what have I done so far?

First up, was a quick bit of learning of how to get simple interactions and GUI elements working… and… learning Lua from scratch 🙂 I’ve never used Lua before so this was a fun way of learning it. Hack, hack and hack – prod around and see what works and what doesn’t. Approach problems as a way of informing yourself the areas of the language that you need to research.

I like Lua, I think. However, we’re still certainly in the “acquaintance” and not “friend” phase at the moment. I imagine this will change with further usage, but I will never forgive the lack of a zero-based index for assoc arrays, heh.

The Addons

This was my first little Addon. It gathers various items of information about whatever unit you are targeting and then displays it in a GUI.

A simple starting point for learning the Apollo API

A simple starting point for learning the Apollo API

Once that was done I then moved on to something that would be more immediately useful to me on a day-to-day basis. Initially this meant a little DPS (Damage Per Second, for those not of the MMORPG persuasion) meter, as seen below:

Stage 1 of the DPS Meter Addon

Stage 1 of the DPS Meter Addon

This progressed on to a much more sophisticated system:

AdvancedDPSMeter

Stage 2 of the DPS Meter Addon

This second version of the DPS meter shows not only current values for current DPS, damage dealt and critical hit damage dealt but also highest recorded values too.

I’ll tidy this up in the week or two after the launch of Wildstar and release it for people to download/tinker with. For now, you’ll have to enjoy the pictures 🙂

Another Game (With Web Player Demo!)

Just over a week ago I had a little play about with Unity’s 2D features that came out with Unity 4.3 a while back. The 2D features are nice if very simplistic in terms of what they actually offer over earlier Unity releases – but at least that means there is not a whole lot of new stuff you have to learn.

As I’m on a bit of a procedural generation kick at the moment, I thought I’d apply that here too. Cue some simple physics based controls, minimalist-yet-striking graphics, and some procedural elements propping it all up and you get the game linked below.

Click the link to play! (Volume up)

https://dl.dropboxusercontent.com/u/12025954/Builds/2014_04_08/2014_04_08.html

I might find a better name than "Minimalist Flyer" :)

I might find a better name than “Minimalist Flyer” 🙂

It’s obviously not finished yet, as there isn’t really much to do other than fly around listening to some mighty chilled out music, but it’s an enjoyable enough experience that I think I may continue with it.

Key Features:

  • Simple yet fun feeling controls (I think so anyway :D)
  • Minimalist visual design
  • Procedural planet placement
  • Procedural planet naming

Future Features?

  • Procedural narrative?
  • Procedural creation of planet styles
  • Ship upgrades/modifications
  • Wide array of mission types (procedural, naturally :))