Entry 51 or how tiles expanded and mobs shrunk
Oct 29, 2011
Let there be tile!
First of all, we decided to axe the current tile sizes for new ones:
Though it’s not quite as simple as that. The thing is, I do need small tiles for world, so that all collisions, path-finding, mob locations can be done fast. It also allows for more detail, such as tile effects (wet/burnt). There are also now “transparent” tiles that show whatever is beneath that level. So in this case, some boring parallaxed cloud cover.
The actual rendered tile is now 9x the size of a world tile, which are now 36x18px (down from 52x26px):
This method will simply assign the same tile type to all 9 tiles underneath. But I can do distinct values on a per-worldtile basis.
Another thing I haven’t mentioned is that the tiles are now solid color, and the texture is applied via a tiling overlay texture, like this one:
This makes for subtle terrain and adds some noise to the final image.
Peewee!
OK, so I guess we are calling our mobs “peewees” after all. So here are some base sprite frames made by Philip:
They are smaller than I though we’d have mobs. Instead, it will be a horde of them, jumping slowly to their inevitable deaths.
Here’s a wet peewee getting lightning zapped:
Bzzzt!
Random path-finding
Now, A* path-finding is fast and efficiently implemented here, so it barely takes any time. But it is also perfect (unless I mess with distance estimation), which means it produces the shortest paths according to the rules I set. This is extra-boring. All mobs follow the same path down the same line.
So instead, I made the mobs choose a certain X/Y offset from their path and try to follow this imaginary offset path when they can (they obviously can’t if the path is next to impassable places). But if they can, then it results in each mob having a slightly different path (blue is path, red is next offset target coordinate):
Since mobs don’t spawn at the same spot, they try to cut corners, and now they follow the path with an offset, it actually looks pretty natural.
Entry 52 about tower mechanics
Nov 13, 2011
Whew! Haven’t posted for a bit, busy time with setting up a website (http://www.uprootworld.com/), video (http://www.youtube.com/watch?v=XBT1nkRSIYs), 8bitfunding (http://8bitfunding.com/project_details.php?p_id=258), etc. But there is also some nice progress on mechanics. Also art got a makeover.
Anyway, this is “the coder’s blog”, so back to mechanics:
Lightning
We now have properer lightning animation and stuff:
Wet peewees also get zapped accordingly to their wetness/humidity.
Ice
Peewees can now also be slowed down by ice towers (also helped by being wet):
Extra chilled peewees also get frozen in spot for a while.
Wind
Here is an air tower, with an air stream. The player can choose which way to face it; you can see X and Y wind values for each tile:
Now, it is too time-expensive to calculate wind direction and/or iterate nearby towers/projectiles to assign their movement. It’s fine for a few items, but when there are 30 clouds and 5 towers, it gets over 150 expensive math function calls per frame. So what I do is keep an array of wind direction for each tile, that gets updated only when an air tower is built/destroyed/disabled/rotated.
Now, adding an ash tower that spits out ash projectiles, we get (projectiles at ground level for demo):
Strictly speaking, these are not “projectiles”, I just the class that way because it is easy to manage. Cloud projectiles possibly share least similarities with other ones. For example, I use wind, inertia, subtle idle movement, fading, etc. on these.
Art art art
This probably should go on Phil’s blog and not here, but I can’t help it:
If you check the video, some cool background cloud parallaxing and ship rocking sine wave multiplication going on.
Main island concept:
Not all peewees have always been small:
But, anyway, back to code (I always say this, then play Minecraft for 10 hours).
Entry 53 on resources
Nov 26, 2011
The more we (I and Phil) think about the game and design features, the more we agree that the game would benefit from RTS features. Not that we hadn’t planned to use some sort of resource system.
Let there be collectors!
Anyway, we went with a pretty basic system with 5 different resources. Firstly, there is “wood”, which is the base material for all construction (building and upgrading/transforming). Secondly, there are 4 “element essence” resources — earth, fire, air, water. These are needed for both building towers and enabling them to fire. Each tower requires the essences that it is made of — so water for air tower or air and water for ice tower. You can see the “temporary” (everything is temporary these days) collector sprites below:
We discussed what the “base” resource should be with Phil, and decided to go with wood. This is for two reasons. Firstly, wood is available in one form or another in every word as is generally abundant and not precious, so it won’t interfere with the story. Deserts have oasis with palm trees; fire worlds have burnt, leafless trees; icy worlds have fir trees, etc. The other alternative was metal, but it was hard to explain how they come by such high level material, when they are struggling to harvest the other basic elements. All other resources seemed more exotic and unsuitable. The second most plausible one is probably stone, but wood > stone in my opinion.
Resources galore (not really)
The player is obviously always aware how many they have:
But, in addition, we added little change indicators per second. This is actually a bit tricky. No tower or collector uses resources reliably and at the same times/intervals. So a tower may be shooting or not, and collector do not “tick” every second. So what I ended up doing is keeping several arrays of resource amounts of past seconds. Then, once a second, I average the last several seconds and show that as the current change.
When the resources run out, the towers stop firing (here we don’t have water, but have plenty of fire):
Each tower eats up one or two resources ever so often, and if it doesn’t have anything to consume, it will idle.
Coding is not programming
Now there is even more stuff to balance for levels *sigh*. I could go on a 3 page rant about balancing issues and what it means to have main resource and how and what acts as primary, what are good tower:collector ratios, etc. Suffice to say, I’ll be posting about this again (some day).
Phil thinks 5 is a biggish number (or so I got the impression). Technically, this is just 2 kinds — one for general building and one for whichever element you need. I guess I won’t mention I thought there could be more. Although, on retrospect, we should keep this simple(r). It’s not like balancing these will be easy.
Entry 54 or fluffy user end stuff
Dec 1, 2011
Fluff. This describes the user interface and various “game” features from programming perspective. There is no difference in mechanics, implementation, almost anything; just some more classes, events, and stuff, all purely for fluff. More chances for weird bugs and more potential for endless tweaking. I guess you can tell I’m a fan of fluff. :) In all seriousness, “fluff” is what makes the game in the end. I am phrasing this weirdly, but this is basically the last 20% I am talking about. The beginning of polish. So today I ought to look back at some of the “polish” on the game part.
GUI scale
This isn’t really fluff per se, but the fact is I cannot expect everyone to play at 1680×1050. So the viewport has to scale. The problem is really aspect ratio though. So the GUI is drawn in two steps – top part and bottom part:
These only scale when the width of the screen changes:
Here is a mock-up Phil did for how GUI might look:
We are yet undecided if the world will scale or not (like, for example Terraria, which is in XNA, and keeps pixel aspect ratio the same at any resolution).
Global announcements
I put a simple system so that different parts can announce stuff on screen, like wave/assault manager telling peewees are coming:
Tooltips
What would user interface be without immediate feedback. Oh, I know, it would be fluffless. Distinct lack of fluff. But here we are, tooltips for building:
These are actually very important if the player tries to build but cannot for some reason. They ought to know why. Sims did this very well.
Here is another mandatory one for build buttons (everyone does this one):
The end stfluff
Oh, well, back to fluff; I mean “polish”. In reality polish is what separates good games from excellent games. Then again, polish is what takes most of the time. Then again again I ought to stop pretending we are that near completion.
Entry 55 with zones and minimap
Jan 3, 2012
Well, haven’t posted for a while now. A month to be exact. So our 8bitfunding project failed :) Also made an IndieDB entry for Uproot. We keep missing out deadlines as well. Also it’s a new year, woo! So better get this blog thing in gear, right? Right?
Zones
I guess the biggest thing we have been working on is zones, or in other words, territories that are controlled by a certain player. In out case a zone can be controlled by the player or by one of the AIs. We obviously strayed from traditional TD formula on this one.
First of all (as opposed to what a proper course of action would be), here are Phil’s zone keep designs:
Possibly the best stuff yet.
The top row are the “main” keeps — the AI player base essentially. The bottom row are the small ones placed in all the other zones.
With cool zones comes great res… I mean zone owner based rules. For one, the player cannot build in zones he doesn’t own:
Ideally we’d have better zone border lines, but that is very similar to having tile borders in the code logic that needs to be done. It may take away for time than we (I) want to spend right now.
Minimap
Since we are going for the RTSque style, we decided to go with a minimap, as our zones are quite big and scrolling is both a pain and doesn’t show a proper world overview. So the first minimap iteration with programmer pixel art was born… special:
It’s still a bit of work with zone definitions and colors and icons and the whole isometry thing. Alas, soon some concept art was made:
This may be a bit overboard in terms of coding edges and lines. Using XNA I actually draw a little isometric tile for the minimap like I would in the game world. This gets updated only when the map needs updating so it’s relatively fast. But it means all borders and lines is sprites that I need to draw and align. No easy primitive drawing in XNA. Oh, well…
Anyway, a nice border was done by Phil and currently we have this:
Better.
Entry 56 with keeps and units
Jan 12, 2012
Our initial idea was to have each keep produce certain units and send them at the player. But this isn’t very TDish. First of all, it’s pretty boring because not a lot of action is going on. This is how a keep looked:
*yawn* Secondly, the player doesn’t see enemy waves approaching until they attack from nearest keep. Part of TD fun is anticipating the huge forces marching, and this is something we want to show visually.
Thus units gathering around a keep was made:
Additionally, this allows us to show the waves sooner than later and lets the player plan better and anticipate what they need most. So first the player would get a warning:
The actual mobs can be then seen coming from map edges “reinforcing” the keeps:
They bunch up at the keep (as in image a bit above), to be sent at player soon.
Then there’s bunch of algorithms and planning that we aren’t even sure of yet. The basic idea is that events happen in steps. And at every step some group/wave decides what they can do. So they would slowly all move towards the player zones and attack them.
Entry 57 or collectors be proper
Jan 13, 2012
A shortish update on collectors, but I think it deserves it’s own post. Firstly, Phil made some geyser sprites, and we are putting water and fire collectors over those. When trying to place a collector, it will snap to a nearby geyser automatically:
If there are no geysers nearby, then it will tell the player that this can only be built on a geyser.
This principle applies to water and fire collectors. Once it’s places, it replaces the geyser or something. Phil’s not yet done proper collector graphics, so we are waiting for that before I know what exactly happens to the geyser underneath.
We tried to think of different ways to do this, like placing water collectors directly in water or fire collectors in lava. The problem with this is that not all tiles are present in every setting. So earth world may not have any lava and fire world may not have any water.
In the end, this limits the number of these one can build. And arguably, fire and water are the most multi-purpose and strongest elements here. Air is more for utility and later combinations and earth is mostly steady dps.
Wood/tree harvesters now highlight nearby trees upon placement, and will gather those trees up. Each tree has a limited number of wood until it gets “converted” into a stump.
We’re still thinking how to do air and earth. Our initial idea was to have special tiles for those. So earth would collect from some ditch-like tiles. And air gets placed on some high up cliff tiles. But that’s a lot of tile work. So we will probably leave earth to collect some ground rocks. Still no good ideas for air though.
Entry 58 or more GUI scaling
Jan 15, 2012
GUI scale 2.0
It seems that as soon as I post something, we change it a week later. We decided to make GUI and world scale the same. So 720p would be the native resolution and it’s upscaled from there, only preserving the aspect ratio:
So the only difference is that resizing the window would also resize the world. Basically, everything is drawn to a width x 720 pixel texture, where width gets updated depending on current aspect ratio. So 1280 for 16:9. This is easier and better looking than not scaling the world. This also makes performance more or less consistent, only upscaling hurts, but not drawing 5000 instead of 500 tiles. We don’t have too much pixel art, so we don’t need to have pixel-perfect representation. Then again, we are doing sprites, so it can blend/scale sub-optimally. But what can you do, at least we support all resolutions :)
Not much else to say, except it crashes once in a while if one does intense minimizing, restoring and if the system happens to lag at the time. XNA issue no doubt.
Entry 59 or prettification doesn’t finish games
Apr 3, 2012
Long time, no post. I think any attempt at explaining how I managed to not post anything for 3 months is… typical. I really ought to make another video too. *sigh*
Light shader power
Time to put the lighting shader to good use and utilize it’s full potential. So here’s the four basic towers with some ground light emanating from them:
This works very nicely and I like the looks. Of course, this is just a “simple” ground tile “tinting” based on a “spherical” radii around the towers. Simple is relative, since this is all shaders with multiple specialized textures and stuff. I also haven’t found a perfect way to “tint” the pixels, that is change the color. I cannot just shift the hue, and I cannot overwrite the existing color. So this works well for darker/desaturated/blander colors, like pale brown. But it’s a little crappy with “colorful”, saturated tiles:
Now, the way to fix this is to have all tiles desaturated. This would also help to make the objects (towers, mobs, props) stand out more. That way I can focus more on lightning and ground effects and less of tile detail. The inaccessible tiles (water, lava, etc.) don’t need this, because almost nothing is placed on these.
To saturate or not to saturate
This is something Phil has brought up before. The few tiles I did, I didn’t quite grasp his intentions with the original tiles he did. I still don’t fully get the details vs. detail size vs. saturation/color stuff. But here’s grass/dirt 2.0:
It needs work, but, what the hell, it will do for now. The lights are more prominent and the objects stand out. It gets a little bit of the “grim” vibe, but I personally like it. Probably just Tiberium Sun nostalgia. Here’s some earth resource/diamond rocks:
Tower tweakages
After prolonged exposure to Photoshop, I “tweaked” the towers a bit. When I say “a bit”, I mean “a lot”… My favourite bit is earth tower animation:
This gets triggered randomly once in a while after the tower fires a projectile. I really spend too much time on these “nice to have” things and not enough on actual code that matters. There’s bunch of small other things I’m too lazy to list or screenshot. Besides, not much I can show without animation.
Finishing up
I have to stop adding new stuff and finish old stuff. Much of this is boring code and tweaking that there’s not much to say about for a blog post. So back to more tedious work. Hopefully, I can do stuff that matters. May be if I say it enough times, it’ll come true.
Anywho, due to unforeseen real-life circumstances, Phil isn’t able to contribute to art at the moment, so I don’t have a lot of pretty updates to post. This just means I’ll use the existing stuff as best as I can, cheat as much as I can, and get out my talentless brush when I can’t avoid making something myself.
Entry 60 or tools that aren’t game
Apr 5, 2012
Lots of stuff is spent doing stuff that isn’t the actual stuff. What I’m saying is that I hate hard-coding things, but in (not) doing so, I rely on tools and editors to put content in the game. This is a great approach for when I have tons of stuff a team of designers and artists can use and work with… but it’s not very efficient when I have a dozen or so items that only I use. Still, I do need some for the sake of convenience. It’s just easier to deal with monotonous stuff this way. Gee, what is it with me and rationalizing my laziness in every possible way.
PropSheetMaker
Unless one has done game objects and map editors before, you probably don’t quite realize just how many variables define each object if you don’t want to hardcode everything. Besides, it is a royal pain to measure each object’s location on a spritesheet if you happen to not use a pretty grid based spritesheet. Thus, PropSheetMaker was born:
This let’s me add, remove, and modify props easily. Mainly, select their location on the texture, as well as size, origin and height with a few clicks. I can also set all the relevant properties. I’m a little too lazy though to make a proper version that repacks the images into a smaller image for performance, but I might some day.
This is a separate (from game) program, which is probably what the artist/designer would work with. This doesn’t need any coding, and “export” button spews out the piece of code that I need. As soon as I put that ingame, I can use the props with the map editor. Speaking of…
Map editor
I don’t think I’ve talked about the recent map editor iteration. In-game menus and selections became just too time consuming when the number of stuff that can be edited got so large. Here’s a couple screens:
Certainly using Windows built-in form controls is much faster than coding all the stuff myself, that I will only use once. I guess this is also something level designer would use.
Anyway, I won’t convolute the post with more stuff and I could talk in length about these two and how things should’ve gone. Suffice to say, they are pretty much (almost) complete and I can use the for actual content/quantity now.