Zity - Graphics

Graphics update woohooo! I usually don't even bother with updating the graphics since I know my art skills are far inferior to pretty much any collegiate artist. However, today when I was pondering how to make my zombies attack I realized that I needed to make some decisions on what the zombies would look like. I wanted the attacks to feel meaningful instead of just - if zombie is close enough damage is done. So I whipped out the colored pencils and started scribbling on some graph paper. The idea came quickly that I would need the arms and hands as a separate, dynamic, animation. My final decision is that the arms and hand segments will be in two sections and will be placed according to elbow, hand, and shoulder locations. This will allow a lot of fluid like movement with the arms and make the zombies feel less like walking GIFs.

So on to implementation! As I was pondering about the arms I ALSO realized I wanted to split the zombie up into segments: Head, Torso, and Legs/Feet. The head would look left and right independently of the torso both while idling and attacking. The torso would keep the collision shape and direction of the zombie while also rotating towards the direction the head is facing while walking. The feet will face the direction of the torso until walking, where they will face towards the target (like the head). All of this was decided by walking around my home and observing how my body looked while turning, hitting poles, and reversing; which makes it scientific.

On to art! I quickly drew up a circular head and applied some hue and brightness jitter to a brown color to create a hair like texture (in Photoshop CS5). I then added some eyes and moved on to the torso which is simply an ellipse. The feet are curved rectangles that have been animated by moving them forward and backward. Put them all together by almost completely rewriting the physics, animated sprite, and altering all classes that had used them; and we end up with a pretty decent looking zombie prototype sans-arms.

Zity - Sight

As you may have noted, my previous post was filled with excitement over my victory in scaling the map. Well as it happens, scaling that map to an appropriate size takes over a minute. So not worth it. I have some ideas to get around this but for now (and for a long time) I'm going to be working on gameplay.

Game-play in Zity is currently at the fledgling point. It's just starting to take root and sprout it's mighty branches upwards. But as for what you can see NOW... well not much (Movement, Shooting, Vehicles, Zombies.. All basics). So my goals are to really work on the game-play elements until completion and THEN and ONLY THEN move on to map generation.

Today's goal was sight, smell, sound. I wanted zombie to react to seeing a player, smelling something, and hearing something. Two days ago I worked on implementing zombies as a state machine and got the theory to the point where, today, I could start implementing these features.

 (My Zombie State Machine)*

*band name anyone?

So first up is sight. Zombies should be able to see a player walking along and then switch from idling, to attacking them. In implementing sight there were little to no issues. The basics of it are as follows:
-Check every zombie for a player within it's sight radius (circle).
-Check the player to see if it is within a cone in front of the zombie (cone).
-Use a raycast to determine if there are any walls or other sight-obstructions in the way (line).
-If none we can see the player/creature, if any then we can't.
A simple process. I implemented this in under an hour and to my satisfaction everything ran smoothly. The zombies would now wait til you were in front of them and within a certain distance before giving chase.

The next logical step from sight was to work on things that obstruct sight (walls). I already have a physics engine that can create physical walls for the player to run into, and a lighting engine that can create shadow objects that obstruct lights, all I had to do was put them together. I created a Wall class that contained both a shadow-hull and physics-object and synced them so they were in the same spot and orientation. I gave my walls a default texture and after spending close to 45 minutes fixing what amounted to a slip of the mind, I had collidable, occlusive walls. These walls also prevented the zombies from seeing you.

 (Walls - blocking light and zombies. He also can't see me)

I haven't started on implementing smell and sound but I know exactly how they will work. Before I implement sound I may have to actually ADD sound to the game... maaaaaybe. So next up is most likely zombie attacks and implementing the aforementioned state machine. Hope there's anyone out there still with me.

Zity - Scaling Success

I Did it. Pictures below

It's not perfect, but I managed to create a method/algorithm to scale my island data to any size larger. This means that I can create my islands small (the way they are now) and scale them to the required size for use in the game. The reason this is so important is that my methods for generating the island shape and population data work VERY WELL on small sizes but for larger sizes they would take monstrous amounts of processing power and tweaking that wouldn't be feasible for the scope of my game. So I'm very glad it's over.

A little history - I posted this question here on StackOverflow 20 days ago and didn't get a single response or comment. Riddled with grief (more annoyance actually) I took it upon myself to solve my own question this very day! So starting at ten-o-clock this morning I set out into the deep unknowns of math and statistics. Wading through, I came to find that I could solve many of the issues myself and within hours I had gotten some key weighted values that I simply needed to add together for the final value (That took another two-three hours). Now I'm sitting here enjoying my triumph of mind over mechanical construct and soaking in the rays of victory. Answering my own question on StackOverflow was a bit of an ego-boost and now I'm ready to dive into generating the roads and highways that will make up this wonderful world!.. only after another few hours of cleaning up my code. I'm very excited for the things to come, especially buildings.

 (Top is my method of scaling, bottom is the computers)

(Ignore the difference in the island's color, only the shape has been implemented currently)

Zity - Corpses

Corpses!! The backbone of any shoot-n-loot has now been implemented, er.. mostly implemented.

(The dead are dead!)

(Ignore the circles, they're for debugging)

When zombies die they leave behind a shell of what they once were. Zombie corpses will persist throughout the entire lifespan of each map to mark out areas that have been cleared or to signal that another player might be nearby. Hopefully it won't get too crowded with corpses.

The one aspect about the corpses that I am not sure about yet is that off loot. Originally I had intended zombies to be a powerhouse, a force to avoid - not confront. This makes sense for a survival game where you don't want the player holding too much power. With zombie fights being something occasional and not constant I figured that the zombies could carry loot that could be taken from their corpse, a standard game mechanic. Then I loaded up a test scene with 50, constantly re-spawning, zombies and a 1-hit-kill sub-machine gun and proceeded to have a whole lot of fun. Hmmmmmm.

So now I have a problem. It's very fun to murder hundreds of zombies in one go and carefully strafe around them as the huge horde gets ever closer. It's also impractical to have all those corpses contain loot. There's no good way to loot 50 zombies in a pile and that much loot in one go wouldn't be healthy for the game. Having zombies be easily killed makes it fun, yet takes the power away from them. There's a few options as I see it:

1. Zombies swarm the player in large numbers but do not drop loot and simply act as a conflict in the player's efforts to survive and re-supply.

2. Zombies remain sparse in small groups or by themselves. They contain variable loot that the player can pick up and act as a component of the survival process.

3. Zombies swarm the player in large numbers and DO contain loot. The loot is minor, stack-able things (money, ammo, stuff like that), and is picked up automatically as the player walks over the corpses.

These are the three options I'm working with currently. The merits of them vary.

Option 1 is fun, no denying that, but turns the atmosphere into an arcade bullet-hell instead of tense survival.

Option 2 is tense, zombies are strong and take bullets to kill. They also are satisfying in a way that they contain loot, making the expenditure of bullets and stealth worth it.

Option 3 is even more like an arcade. Money is picked up automatically and used on npc's to upgrade weapons/equipment. This option is last on my list but the auto loot mechanic might come into play somewhere else.

So that's that. Corpses and Looting is the flavor of the week. After this I'm hoping to get back to my map and the accursed scaling problem.

Zity - Back on Track

It's been a bit longer since my last post than usual. I recently got back from a short trip to Texas to escape the ridiculous Minnesota weather we've been having. A few days both before and after my trip I managed to get absolutely nothing done which I'm not to happy about. Today though, I decided to fire things up again and set some goals for each week. This week's goals involve vehicles and zombies.

First thing first, I don't believe I mentioned this in past blog posts, You can now run over zombies and kill them! It's not as exciting as it sounds (since there isn't any blood or corpse yet) but the zombies do die when hit at a sufficient speed. Later on I'll be streamlining this to include more interesting animations and blood spatter.

Next up is what I completed this morning, namely player states and vehicle controls. I had planned to work on entering and exiting and controlling vehicles right off the bat but I ran into a fairly decent problem. My player wasn't programmed in a way where he wouldn't fire a gun or move around while in a vehicle. this may sound dumb but it was actually quite a hassle. Previously my player would simply move every frame depending on what keys are pressed and fire if the mouse is pressed. This is all well and grand but when the player is in a vehicle I don't want him able to fire or move himself, only the car. I could've simply hacked in a flag saying whether the user is in a car and use that to determine if the player should move or fire but I realized there are quite a few more scenarios such as picking a lock, using an item, talking to npc's. All these things needed to be organized in a way that they wouldn't overlap or interfere with the others. An example would be if you went to pick a lock and pressed the mouse down and started firing while lock-picking. While this behavior would be pretty awesome, it is not intended. My solution is to make the player a State Machine. What this means is that the players change their state depending on what they're doing and some actions cannot be taken while in some states. This separates driving from shooting and lock-picking from looting and is very easily expanded to new states.

Now on to the interesting stuff. You can now walk up to a vehicle and a message will display prompting you to press the E key to enter it. this only occurs near any door to the vehicle (not just by being near the vehicle). When you press E you enter the vehicle and take control over it. The vehicle control scheme goes like this: WASD controls turning and moving forward and backward but not your actual speed. That is controlled by the scroll wheel. For instance if my desired speed is currently 50 then when I press W I will attempt to accelerate to 50. If I want to go faster then I simply scroll up a little more to set the desired speed to 75 and keep holding W down. I found this scheme works better then simply holding down W to accelerate and S to brake/go backwards. The later tended to force the player to tap the W key continuously to maintain a steady speed.

Also the user can toggle the lights, and would be able to honk the horn (if I had sound effects). The other features vehicles will have is an On/Off state, Passenger seats, Damage, Locked doors, and the requirement of hard wiring a car to start it up if it didn't have a key. Some of these features I'm working on now, others I have planned for later weeks.

The other elements of the game that I intend to finish this week are adding corpses in where zombies die, filling them with randomized loot, and allowing the player to loot the corpses. I'm not entirely sure if I want corpses to have any valuable loot or simply scraps and maybe some coins or something. I don't want the game to turn into a zombie-kill-fest where you find lots of awesome gear by slaying millions of zombies. I want it to be a tense survival atmosphere where you are afraid to run into zombies since you will then have to waste bullets and try to escape and lose the loot you were trying to find. Hopefully I can get it to that point.

Sorry for no pictures again. There really isn't much to SHOW of the new features but a lot of background components and game play. I'm hoping to get a speedometer up and some more graphics for the GUI soon.

And before I forget I actually switched the inventory system around again. Instead of the weapon list I opted for the standard primary weapon, secondary weapon method. The reasoning behind this was that it was causing issues with looting from zombies and while I could've implemented it again I  thought I'd try this method first. After working with it I find that it adds more to the survival element by not being able to rapidly switch weapons. You can obviously still fairly quickly open the inventory and right click a new weapon to exchange them but this takes a conscious effort and time where zombies (or players) can get the upper hand.

I hope to continue developing Zity the way I am this week, with clear goals and direction every week/day. I realized I'd become lax with my routine and the vacation really through things off so I hope by motivating myself to reach goals each week I can plow through a lot of the tedium and start making things fun.

Zity - Road Beginnings

After my work on the inventory I decided to take a break and go back to the generation of the island. I knew all the steps I had in mind for generating roads and cities so it didn't take too long to start implementing them.

First thing first, I needed a way of drawing highways over the island to connect high centers of population (cities). Well in order to get that far I needed to have population data to sample from. So using the good old Perlin Noise library I came up with a noise map that was spaced out and smooth enough to represent centers of population. I then overlay this onto the map for visual purposes.

 (Areas in black - high population, white - low population)

From this map I could now construct roads by starting at a random point on land and projecting the road in a direction. Then for each additional road segment I simply search for the best direction for a road to go within the area in front of it by looking at the highest population density. This method produces roads that tend to circle around and pass through black (high population) areas of the map.

(Red lines are roads, duh)

While this can provide some nice looking highways, I find that they tend towards the dark areas too much and I'll most likely be implementing a weighted value approach that's too complicated to explain in this blog. Also as of now I still have to scale the island up to it's final size. Currently the map is only 300 pixels wide by 200 pixels tall and each pixel will represent a tile (25 x 25 picture) in the game world. Since I want the world to be realistically big it will have to be around 400,000 tiles long which, for those of you following along, is also 400,000 pixels long. An image that long would be ridiculous and my generating methods would not work on data that big so instead I'll be scaling the generated island to the correct size before moving on to the roads and buildings.

I digress, The roads function fairly nicely and are tweakable easily so I'm prepared to move on to other things, namely streets and local roads. I'll admit I'm not too confident in any plan for streets and lots yet but you've got to try to get anywhere in programming. Number one piece of advice I've ever received was to make it work until it doesn't, and then fix it. This wouldn't make sense in a business application but in independent game development you cannot wait around til everything is extensible and moddable, you have to make it work and quickly.

Zity - Inventory

The inventory. Something that I've struggled with from the beginning. I've gone through several different designs, graphics, and implementations but finally have something concrete.

My current inventory layout is extremely simple with a 20 slot bag to hold all your items. You can drag and drop the items wherever you want and open and close the bag, all basic stuff. Yesterday I managed to get tool tips up and running for equipment, guns, and ammo (the only three item types I have finished as of now) These tool tips display the items name, description, type, and information.

(A tool tip for a generic cap. It's being compared with a baseball cap currently equipped)

The tool tips also display the gains and losses of equipping the item when you already have an item equipped. The tool tips for the weapons display the damage, rate of fire, reload speed, etc. The ammo tool tips display the type and description. I haven't gotten stacks to show up yet but that is next on my list.

The key thing to remember is that all of this is placeholder art and designs. They are not final in any way and right now they are just tools so I can see how the final game will play.

So next up is collisions: Killing zombies, running them over, shooting them, punching them, etc.