Entry 71 with lots of cutting
Jul 21, 2012
Creep of features
Time to get rid of excess baggage left by the constant feature creep. Some of the additions could have been great, others not so much. The bottom line is that most of them just take too darn long and require too many art assets and balancing.
So mainly I’m scrapping the superunit. And, consequently, I’m also scrapping zone control and capturing zones. *sheds a tear* I know, I know, it was a big USP and it was a cool mechanic. But it’s been 1.5 years and we don’t have the resources. I rather polish a smaller, tighter game than cram it up with unfinished features. Also less bugs. In the end, what we’re left with is these wonderful keep sprites, which I’ll use to spawn the attack waves. I’ll also use the capture progress indicator as a next wave preparation indicator. I’ll still keep the actual zone layout to stop the player from building towers right under enemy nose. But otherwise zones won’t serve a bigger purpose except for some internal structuring. I also scrapped separate AIs for different “players”. I never went into this, but it was basically an internal way of keeping track of who goes where and does what. So here’s how the minimap improved:
Also, I probably don’t need to mention I’m scrapping the whole ordeal with plot and such. No story art, no prop art, no story outline, no implementation. Oh well…
It surely sounds a bit grim. But when you think about I’m mostly complaining that I have too many features. Which is always better than not enough, because I can easily cut away and be left with the best of the lot. Of course, one can argue that certain aspects aren’t meant to be cut out — i.e. some resemblance of a story.
User niceties
Among all the technical tedious things, it’s time to pimp up the user interface. What needs to happen is that every user action needs to receive an appropriate reaction. This includes, both gameplay and audiovisual cues. For example, building a tower will now do 4 things – spawn the actual tower, cue the thump sound, spawn a few dust clouds, and float the resource costs above it:
Now that’s feedback! Almost makes building towers fun. When you cannot build, a visible tooltip follows the mouse as I already posted previously. When the player clicks, they get a sound and a small flash on the preview ring (note the red ring difference):
This also got me thinking of visually showing the borders of towers in progress. Full-built towers are all roughly the same size and the player can visually tell where there is free space. However, recently placed towers are still “submerged” and it may in some cases take a while before they emerge and “fatten” up to their normal size. So a little construction guide wire:
Great! I could in fact do several levels of constructions scaffolding and such to make it feel really alive, but I won’t focus my work on the same bit for too long. I think these have gotten enough attention.
Another important (hard to understate) feature is island health:
These are persistently visible sprites at the corner of the screen showing the damage to the main player’s keep — i.e. the island. These decay as the mobs reach the keep and also flash to bring the player’s attention and create some tension:
Each heart reduction is accompanied by a screen shake (which I can’t really screenshot) and a red flash of screen borders. The last remaining heart also starts pulsing for urgency.
There is still plenty of stuff to do and at some point I’ll just have to call it.
Entry 72 with more of somewhat artsy stuff
Jul 22, 2012
A few artsy things for the game, mostly sprucing up the worlds (air, water) with least props/tiles. I made a rocky (probably impassable) terrain for air world:
It came out too photo-realistic, I even painted over it to get rid of that. But with over two dozen tiles, it’s a pain to fix them all while maintaining seamless borders. Besides, all the other air tiles are too photo-realistic too so it balances out :P Also the photo came from a stone pile in my back yard. So this is all original.
I also converted a few trees into their desert equivalents:
And I made some original sprites:
Took me long enough, but I quite like them. Came out better than I would have expected of myself. I’m slightly worried about my/Phil style difference, but oh well… Less worry, more happy!
I also (re)made some purple swamp pumpkins or purplekins and a whole new Venus fly-trap plant:
I like how these came out. And that’s all that matters.
Entry 73 with more juice
Aug 21, 2012
Firstly, let me say that “juicy” sounds much better than “fluff”, and if you are reading this you should watch this video. Anyway, short update.
Firstly, I made the progress bar for upgrading (and non-interfering with health bar):
Then I made cutesy little tower level indicator icons (since I don’t have a much better way to do this):
And then, here are not-enough-resources-to-fire tower indicators:
I will make the icons animated (flash border and scale) to make them more lively and attract attention.
I say this a lot, but–on their own–these features are not complicated at all and don’t take any time in any decent coder’s hands. But I can’t stress enough or properly explain how interdependent things get in a large, complex codebase. No matter how elegant, future-planned and well-designed the code is, you can never account for every possibility. So eventually some feature will require rewriting existing code or modifying it in a way that will break a bunch of other stuff. But this not being a nuclear facility, I can ignore those small breaks. Unfortunately, that grow like weeds and I’m a very lazy gardener. But I digress.
Finally, certain levels now can give the player a constant stream of resources once those are captured:
This can be strategically important and the difference can be amount to being able to build an extra tower or two per a dozen of those without any boosts. And that, in TDs, can sometimes be a deciding factor.
I’ve also worked on a new level (a total of 40) layout (all shown for clarity):
This is a bit more complex than that and there’s a lot of planning:
New levels get unlocked only when certain other levels are completed, and some levels unlock more, some don’t. The player progresses through the fourworlds roughly in a sequence, but with many exceptions and side-levels. I wanted the game to shift between the four worlds and not just randomly weave them all together. It should all be retty organic and with a little flavor text I think we can pull this off.
And last, but not least, island landing at level start-up:
This is pretty much what it sounds like. The island starts in the air and lands with a thud, before the level fully commences. I’m in progress of making the title nice, but here’s WIP:
It fades in and out, so it looks pretty decent.
Long time, no post. And me, myself and I are to blame. But, progress! And that is what matters!
Entry 74 with further tower improvements
Sep 2, 2012
So Typhoon tower! It’s been a long and rough ride everyone, with lots of cool ideas that went largely unimplemented. I would like to blame me and… wait, where was I going with this?
So here was the initial idea drawn by Phil for the typhoon tower:
Great, right? Well, yes, indeed. That would be quite, pardon the usage, … epic. However, and may be I’m just too thick here, but this is so impossible to code nicely using just sprites. And the number of sprites I actually need! Not going into detail here, let’s just say this has been discussed to death with more than one person… May be I’ll think of something some day.
Instead, here’s a bubbly bubble 2.0. The above is Phil’s concept art and below is projectile flying/impact animations:
Nice and painterly :) Still a bit sh…ady, but it will do. Besides, we’re on the clock here people! So in-game these look pretty decent, except typhoon tower will need something done to it to “explain” the projectile.
Or, you know, I could cheat and make the projectile shoot from the tower’s dish below and add some sparkly water clouds to cover it up. Sounds good.
To make this more useful and unique, the tower will shoot several projectiles (easier said than implemented, thankfully I already did this for vulcano tower):
Thus bigger groups and corners are the best place for this tower. From coding perspective, I just need to make sure the same unit isn’t targeted twice. Also shooting after the animation rather than before proved to be somewhat weird to implement. After all, the tower needs to find a target, then animate, then shoot before making sure the target is still there, there are still enough resources, etc. Basically another hackidy hack in a hack spaghetti.
Finally, I began implementing something I wanted to implement for ages now — polarized lightning towers:
Lightning towers are pretty much the coolest tower in-game, I think. So it makes sense to have improvements for them. Now, polarity towers only shoot towards each other and zap everything in their way. So they need to be positioned properly. But I’ll talk about this once I implement it.
I also worked a bit on transform buttons and how they look and what they show:
I sometimes forget myself what upgrades into what, so I want to make sure the player can see it clearly whenever they are about to do something. So if they build an earth tower and are about to build and inferno tower, they know they could transform it into vulcano tower later. Plus, the actual tower sprites instead of element icons makes is so much more organic and easy to identify.
Anyhooves, back to work.
Entry 75 with hot air
Nov 26, 2012
Been a while (again). What can I say, real life is a female canine. Anywho.
Whoosh
A wild Air tower appears! (Who is my most useless primary tower? Yes you are, oh yes you are!) The issue here is its primary designation (one of the main four tower) versus its poor initial utility (doesn’t do any direct damage and needs much later towers for its combinations). Not to mention it doesn’t consume any resources or stop blowing at any time (and the player can’t really control this) due to it’s wind mechanics. Is it even worth reiterating the code is a mess?
So one of the “obvious” solutions is to make it interact directly with mobs, in this case — slow down flying mobs. Air mobs being almost separate from other mobs is generally one of the big TD game aspects. And I can surely use it as well. I already have the melon flying mob, so it’s not too hard to code in:
Tower’s conical shape is best used on turns, so some planning has to go into this. Also air is a very precious commodity for super powerful lightning towers, so one wouldn’t want to build too many air towers either.
As with Ice tower, I need to make sure it’s not completely overpowered. After all, slowing a mob down 2x times means basically time for 2x more damage. Granted, all the other following mobs are still there (and also generally slowed), and the towers still need to do the same amount of damage. But it does create interesting scenarios for splash damage towers. I suppose this is somewhat offset by the fact that it only affects flying mobs.
Tower fire modes
While not crucial for all towers, this is now required for gameplay for air tower. Does it blow when flying mob is in range — i.e. slow something directly; or does it blow when any mob is in range — i.e. blowing particles. (I guess I could semi-reliably detect this, but meh.) Or may be, just leave it always on or off. This could also be useful for ash or stomp tower, for example. So that’s at least four more buttons with tooltips, plus bunch of conditions for which towers accept what and how they act on that. Plus icon sprites, always sprites. Anyway, here’s the basic idea:
Obligatory rant
Too much actual work above, time for my daily rant of procra… I mean, reflection *snicker*. We had so many great ideas for how to use towers. Blow air to spread fires, direct currents, affect bunch of world objects, etc. etc. They say removal is as much polish as anything else — get rid of redundant, useless, impractical. But I’m sad to have so many ideas in my head and realize that hardly any of them will come to fruition. I guess that is the bane of ambitious projects — they start with a vision of a magnificent castle. As you work, you realize more and more that you will build at most a mansion. There will be no court room, no dance hall, no Doberman pen, no butler residence. I guess what I’m saying is, I don’t deal well with reality interfering with my visions. But who does, ey?
Entry 76 with porting
Jan 3, 2013
Short version, I ported Uproot to MonoGame.
This means Uproot now runs Microsoft-independent XNA-style implementation. The big changes include back-end .NET->Mono and DirectX->OpenGL migration. And, of course, this means portability to all kinds of platforms — Linux, Mac, Mobiles, and, more importantly, Windows 8 Metro. I could go on a long rant about Microsoft not supporting XNA anymore and having no plans or support for XNA Metro apps. Bah! (Will just have to learn Unity proper, I guess)
There were a few minor and a couple major hiccups, although that categorization really only applies to the end result. The actual issues were fairly easy to fix. I was very pleasantly surprised at how easy it was to port it. In fact, the word “port” is an exaggeration, as it is almost the same code! It just worked almost straight away, with 0 relevant compile errors. And since I didn’t use any fancy shamncy Microsoft stuff, like Gamer Services or that weird music/sound implementation, I did not have to deal with any incompatibilities. All the stuff I use is the out of the box stuff MonoGame guys have implemented. Most surprising part is the shaders, which gave me almost 0 trouble (except names used to access parameters) where I was expecting the most trouble!
Now, there are some issues. There is an FPS drop, which kind of a sucks, given how many sprites I draw. My render target switching especially is somewhat slower, and I do lots of that. Tiles draw 2x slower (from 7 to 15 ms per frame at debug). But I really don’t know how to speed any of this up besides drawing less. Thankfully, optimized release version is much snappier and runs at 60 fps fine. Though I’m worried about slower PCs.
To celebrate, I drew some native’s swamp huts (further proving I shouldn’t draw):
Entry 77 with Unity
Oct 15, 2013
It’s time ladies and gentlemen, time for change! Time for a goal change, time for a scope change, time for a game change… literally. I haven’t devoted much time to Uproot in the last few months, almost a year. Let’s be honest — I haven’t done anything. Between work and more work, I’ve had no time or determination to properly finish this. Meanwhile a whole lot of code and art are collecting dust, while the blog and website are collecting spam comments. But enough about the past, let’s focus on the future.
I don’t have to start anew (have mercy), but I can certainly trim and consolidate. I’ve wasted far too long on minor things that aren’t even part of gameplay. They may make for a more polished game, but it is all for naught if there is no game.
Unity
But wait, what is thi, Unity? Didn’t I just “port” to MonoGame? Someone who cares might ask why and why Unity in particular (why XNA or MonoGame don’t do it?) For one, I am working in Unity for other projects, so I don’t have the headache of multiple IDEs. Secondly, there are great community resources and many readily available assets and examples. Finally, Unity is commercial, supported on many platforms, updated and unlikely to be phased out any time soon. Subjectively, it’s also fairly straight-forward and let’s me use C#.
Back to basics
Now, Unity isn’t 2D, it’s 3D and doing 2D is basically doing 3D with quads and flat camera. Without too many details, here’s my isometric grass tile:
And here’s a new mob in that tile:
Finally, let’s tile the tiles as before:
Perspective
Unity is 3D, which means 3D cameras. All above screenshots are orthogonal views (what XNA uses, flat camera, no depth distortion). If I am using Unity, why not something fancy:
BAM! Awesome. With a little fiddling and smart positioning of other sprites, I can achieve some pretty cool pseudo-3D views. All the sprites are 2D. But add a bit depth, a bit parallax, a bit perspective distortion and it will start feeling much more 3D.
One problem though — seams:
This isn’t an issue with 1:1 orthogonal camera as everything gets mapped perfectly and I can just use pixel or point filtering. I cannot do this if I am to distort the sprites, in other words, if I rotate and shift the camera, the sprites need proper filtering. Unfortunately, these are isometric tiles and the usual tricks (offset UVs by half a texel or have original sprites with extra border) don’t work for me.
So here’s a fancy solution — render the tiles with orthogonal camera to a separate texture and then render that texture on a quad that is then viewed by a perspective camera:
What this achieves is that the original sprite layout is point filtered and pixel-perfect, and the camera films it that way. No issues. That image is then distorted or viewed under an angle as a whole, so any filtering is applied to the whole image and no longer individual tiles. This makes the seams go away (mostly anyway, but I’m done fiddling with this miniature for days).
Borderlands
I don’t want to remember what nightmare the original border algorithm was, so let’s just say this took an hour to do (hell, I can write border algorithms in sleep now):
Looks right, right?
Anywho, I think this is enough for a post. May be I will shame myself into future updating since I made fancy promises here. Looking back, I share no illusions that this simple TD won’t break any records. In fact, it’s gonna be a miracle if it gets published. I think my goal now is to simply get something out there, go through the process once and then come back with something more… playable. This is not to say Uproot doesn’t have huge potential, it’s just that I don’t think I can realize that potential at this time.
Long P.S.
21 June 2018
Did you know almost nobody finished their first project? Did you know it’s always too big, too complicated, too ambitious? Well, guess I’m not a special snowflake in this regard. What I’m saying is, Uproot is unfortunately cancelled (“indefinitely postponed”, if you like). This is likely the last of the game’s dev diary. *sniff*