Zity - Tile Art

This week's post isn't going to be about Zity but rather about a free art program I recently discovered and will be using for Zity (unless I hire an artist of course).

Krita

There's a lot you can find out about Krita on their website here, but I'll give you an overview.

Krita is a free digital painting program. You can think of it like photoshop with more of a focus on painting and less focus on photos, and of course it's free. Krita uses a complex brush engine system that is very flexible and allows you to create the kind of brush you need. It also works with layers, color pallets, shape tools, gradients, and pretty much anything else you could want. Krita is also consistently updated with bugfixes and new features so there are no worries of using an outdated, glitchy program. It's basically wonderful and anyone interested in doing digital painting/art should seriously check it out.

Zity - of Problems and Setbacks

This post doesn't have too much to do with anything recent but I thought I'd pass along some information and all the things that a game programmer starting out would want to know before they find out for themselves.

Zity has been in serious development for over a year now, but if I'm honest... I've been working on Zity for something more like two years. It started out as an idea and it went through several iterations before any sort of actual game was fleshed out. During those iterations a lot of trial and error, research, and improvements were made, and while these were all necessary at the time I would not want to repeat them again.

Some things to watch out for:

Often times as a game developer I overlook aspects of the game that I assume would be easy. They never are. In order to avoid the continuous cycle of overlooking something and then having to go back and alter everything I've had to really force myself to dig deep into the systems that make up Zity and make solid decisions on the game.

A List:

Zity - Lighting Revisited

If you ever played a game with really good lighting you probably noticed it. The way the shadows were cast and the illumination of objects helps to set the mood of the player and even can fuel the gameplay in certain genres. Horror games use lighting to limit the player, making him afraid of what he can't see. Action games use lighting to heighten the thrill and intensity. Strategy games can use light to convey time of day or weather. In any genre lighting can be a tool well worth polishing in order to get the most out of the game.

So it's no surprise that Zity will be heavily investing in a good lighting technique. Zity is all about tension and suspense and even sometimes the peace of being away from the tension. To help convey that feeling I will use lighting.

There's several different lighting techniques and methods to choose from when creating a 2D game. It's easy to see in games like Terraria where you can alter the lighting in the settings and see the various effects. But before even diving into techniques I'll give a brief overview of some options.

Zity - Components

This is my second post about the current state of Zity, following my initial one that outlined the new editor.

I've switched Zity from using OOP and inheritance to a component based architecture. This means that there hasn't been a whole lot of new content, but a lot has gone on under the hood with how Zity is programmed. Basically I've been working my way BACK to where I was a month ago using this new architecture and thought it's been quick, I don't have much to show yet. What I can do, however, is explain OOP and components in case anyone is interested.

Allow me to shed some light on the subject.

Object Oriented Programming (OOP)

OOP is a programming methodology (rules basically) based around this concept of objects. An object can be anything in your game/program that exists by itself. For instance in a game like Zity I would have Car, Player, Zombie, Gun, and Bullet objects. Each of these self-contained 'things' is an object and would like this in code:

Zity - The Editor

Hey Everyone, here's the deal:

The Blog - I've decided to start writing up new posts EVERY week instead of whenever I feel like it. Hopefully it'll both help me stay motivated, and help promote/push information to you (the reader). So this should be the first of a weekly series highlighting my blog.

The Game - A lot has happened since my last update, sadly a lot of it isn't very noticeable. I built and rebuilt an editor, did a LOT of research and theory pertaining to programming Zity, and spent a lot of time with friends/family (not programming).

The most noticeable addition has been the Semi-Block Editor. This editor will be used to create pre-made sections of the city that will be used in the pseudo-random generation.

Let me explain -

The map in Zity has gone through a few changes in how it will be generated. From my first idea of complete procedural island/city/building/room generation I've come to realize that procedural generation is HARD. Seriously if anyone reading this has ideas about a procedural game then they need to be SURE that they have a plausible, simple, straight-forward idea about how to generate it.

My new way of generating the city combines random elements with preset elements:

Pathfinding - A* | Theta*

Path-finding was obviously going to be an important of Zity as most of the NPC creatures would need to be able to get places in a non-linear fashion. For instance a zombie seeing the player through a window will need a way to get to the player besides just running at the window. To accomplish this I looked at many different path-finding solutions, ideas, and methods and settled on Theta* (A variant of A*).

Path-finding - An overview

In video-games a common scenario involves an NPC trying to get to the player whilst avoiding obstacles. While things like (steering behaviors) allow characters to dynamically avoid obstacles, sometimes we need characters to find a path through a maze, out of a building, or to a far away player. To accomplish this games use a method called path-finding which involves traversing a representation of the map in order to find the shortest path from start to goal.

Maps are typically represented by a bunch of polygons or sprites that draw the terrain. Then collision meshes and bounding boxes are used to check if things are hitting these maps. Path-finding unfortunately requires another representation of the map. Depending on the style and type of game the map representations can vary. Common representations are grids/graphs, way-points, navigation meshes, and visibility graphs. Each of these has pros and cons depending on each game's requirements. You can read an excellent article on map representations (and find more information about path-finding in general) (here).

Once the representation is implemented you then need a method of finding paths on it. There are many different algorithms and variations on them to choose from but the most common is A* (A star). A* merges together two other techniques to find paths to create a very fast, and accurate path-finder.

A*

There's a lot I could cover about A* but I'm going to very quickly go over it's implementation. A* works by estimating a nodes distance to the goal node and adding that to how far the node has come from the starting node. These two values are H (distance to goal) and G (distance from start). One other value is F (H and G combined) which is used to determine the likelihood that the node will lead to the goal. Every node keeps track of it's G and F values and the node it came from.

A* also uses two lists. One is the Open list which keeps track of all the nodes we have yet to expand. The other is the closed list which keeps track of the nodes we have expanded already. An important note is that the Open list sorts the nodes by their F values so that the highest (best) F value is at the front.

A* basically works as follow:
Start by adding all the neighbors of the start node to the Open list. To do this you get the neighbors from the Graph, calculate how far each node is from the starting node (G - usually 1), and how far the node probably is from the goal node (H) and add them together and store F and G. Also set each neighbor node's Parent to the starting node.

Now you have some number of nodes in the Open list sorted by their likelihood of leading to the goal node. You take the best one out of the Open list and basically repeat what you did with the starting node - Expand it's neighbors and set their values. You then put the node in the closed list since it's been traversed already.

Now eventually you will get to the point where the node you take out of the Open list if the goal node. Once you get here you can stop and create the path by starting from the ending node and adding the Parent of it, and it's Parent, and it's Parent and so on until you get back to the starting node.

There's a lot more to A* then this and I encourage anyone who is interested to check out (this) for a very well done article on how it works and how to implement it.

Zity - Day/Night cycle

I know it's been awhile. These past two weeks or so I've been stuck in a rut. For some reason I could not dredge up the energy, direction, or motivation to work on Zity. I spent most of the time researching things such as AI pathfinding/navigation and music tools, both of which were just distractions from working on anything (although the pathfinding will probably be useful in the near future). Today however, I accomplished something.

Day/Night Cycles! I had always known I would implement day/night cycles in Zity as it just fits with the theme, similar to Minecraft, Terraria, Day Z. I had done some early theory-crafting about how I could implement them but never really touched any code for them. Today however I gave it a shot.

Zity - Character Creation

Pretty big update. After my foray into zombies and their animation I decided to work on the player and player animation. I implemented almost all the same pieces of a character (head, body, feet, hair) except arms as those will work differently then the zombie's. After getting all the art together and working I decided it's about time I worked on character creation and customization, so off I went.

Zity - Trees

Another day, another update. Today it's trees.

I'm in NY! Yesterday morning my whole family and I flew out to NY to attend my great grandma's funeral this morning. She died at 103 years old which is crazy amazing. Yesterday I was exhausted but this afternoon I was feeling better and decided to tackle the problem of foliage in Zity.

Over a year ago I played a small little flash game that involved being a wizard and defending against creatures; I wish I could remember the name. The part of this game that interested me was how the (beautiful looking) trees faded in and out as you walked under them. I instantly knew I would use that effect someday in my own game.

In Zity, trees will come in a variety of different types and variations in both look and color. There will be forested areas of the map where zombies will be few and animals many. These areas will be for setting up a camp or taking a break from the populated city zone. Animals can be hunted and berries picked for food and little lakes and ponds will give water. The only thing about these zones is that the temperature is lower and you have to fight off the cold.

I digress. Trees are now almost fully implemented and you can watch a short video below:

(Treeeeeeeeeesss!)

For those who would rather read: Trees come with a canopy and a trunk. The canopy will fade when creatures are underneath and become mostly transparent. Trunks act as walls and block movement and bullets. When a tree is chopped down it will drop wood and a few other sparse items. I'm considering implementing a season cycle and colorize the trees according to the time of year, but I'm not sure a game will last that long or if that would be appropriate for the first version of the game.

Let me know what you think! These trees were drawn by me and my sister.

Zity - Idle Zombies

This morning's work was all on the zombies. Specifically, I wanted to work on how the zombies act when they aren't attacking anything. The obvious actions would be to shuffle and look around from time to time. So that's what I did.

This video shows how the zombies move about and look around. I intend to have more interaction with the zombie in idle mode such as fights and the obvious groan sound effects. For now though, this is a good start.

Next up is going to be some work on zombie stimuli. Sounds and smells to be exact. I'm hoping to spend my trip to NY (this weekend) and get to the point where zombies will react to the player making noise and try to find the player around walls and obstacles.

I've gotta say, this AI programming is really satisfying. Everything I've done up til now has been great but, aside from vehicles, nothing else has had such an immediate impact on the game and actually added gameplay. I'm very excited for future updates and I'm churning out new content at a steady pace these days.

Zity - Sound and Stuff

Another day another update. This time it's audio and sound.

I knew audio would be a big part of my game but I desperately wanted to put it off for as long as I could. This was mostly due to the fact that didn't have any audio FOR the game. I did, however, think about the type and style of the audio system would take. This morning and last night I decided to give it a shot due to a number of reasons one of which was the discovery of http://incompetech.com/music/royalty-free/ , a site with hundreds of songs with different mood attributes making them easy to find.

The song system is going to be pretty straight forward. There will be several song lists for different areas of the game, from the menu to the city. Each list will have half a dozen ambient songs played sequentially with cross-fading to make it sound seamless. I've picked out a few songs from incompetech and, in a few hours, had my audio manager up and (mostly) running. So far only the menu screen will play music as there is no map with zones to switch between as of yet. In the end there will be several zones such as: City, Woods, Country, Ocean, Desert, etc. I'm still in need of an Audio Producer but I'm not concerned with that as of yet.

Sound effects are also going to be an important part of Zity. Actions such as opening doors, stepping on floors, shooting guns, reloading, eating, crafting, and coughing will all need both a sound effect for the user to hear and will create a sound object that will alert nearby zombies of the sound. The zombies will then choose whether to react or not based on their awareness and some other pseudo-random factors.

(Image resized - Not representative of in-game)

Apart from sound I also did quite a bit with the zombies graphics and movement/attacking. The zombies had their shoulder width cut and their overall shape improved. I also added preliminary arms that stretch from the shoulders to the target. I thought about trying to implement my dynamic hand idea but I realized it was out of the scope of what I wanted to accomplish right now. That's more of a final polish item. Anyways, now the zombies look like so.

They also will start attacking the player when close enough. After half a second of animation (that hasn't been implemented yet) if they are still close enough to the player they will deal damage and then repeat. While there may be an issue with players abusing the sprint function to periodically gain range on the zombies to avoid attacks, I believe I can iron out the flow enough so the zombies feel dangerous. The only issue I have right now is that the zombies tend to overlap in weird ways. The ones nearest the player should get preference over those farther away and I'm looking at implementing this soon.

So all is well. Working on more of the zombie states currently. After that who knows.  Maybe I'll work on buildings again. I'm hoping to get around to working on trees soon. Also another gameplay component popped into my head; Zity will most definitely have farming and farm animals along with pets and zombified animals/pets.

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.

Zity - Items and Equipment

I know I talked about how the inventory was coming along with weapons and bullets. Today however, I've started streamlining their creation through the use of 'Item Factories'. These classes hold all the data of every item and will return new items as requested, streamlining code and making it much more readable.

On to the interesting stuff - While I was working on these factory classes I realized that I hadn't set in stone the way equipment (and stats) were going to work in Zity. I originally had planned to simply use the old Strength, Intellect, Dexterity, Agility style stats and derive specific stats from them. For example a character with high intellect and dexterity has increased lock-picking and increased car-jacking. A character with high agility and strength would have increased melee damage and run speed. You get the picture. While implementing this I realized I really didn't like it. These stats were too base, too simple, and they didn't give enough control and clarity over what each one does. So I got to thinking and came up with the following:

There will be specific stats for specific actions, similar to professions in World of Warcraft (Skinning, Mining, Fishing, etc), skills (Skill with guns, melee), and attributes (Strength, Cold Resistance). The compiled list I have so far is as follows:

Stats:
Lock Picking
Car Jacking
Strength
Cold Resistance
Guns
Melee
Armor

With these stats I'm able to vary each classes starting attributes to (semi)correctly match their theme. For example:


Hobo ~ ++ Cold Resistance, + Melee, - Armor, - Strength
Geek ~ + Car Jacking, + Guns, - Strength, - Armor, - Melee
Doctor ~ + Cold Resistance, + Lock Picking, + Armor, - Melee, -- Guns

You get the idea. In this way each stat is easily accessible and understandable and tailoring your character to the kind of play you desire is simple. This list of stats (and the examples) is definitely not complete. Some characters may get special stats that only apply to them. I'm still brainstorming all the ones I'd need in the game but I may just start with these and add others as things move on. Comments/Suggestions are welcome.

(Sorry, no picture today)

Zity - Small Update

Not much to mention today. I worked on the inventory system, guns, and bullets and managed to get simple firing and bullet creation/deletion working. The bullets are full, physics-enabled, objects which will be fun if I implement a ricochet gun or other weapons like it. The inventory is coming along nicely. I've landed on having a list of all the weapons the player is carrying and you can scroll through them to swap which one you are currently using. Then there are two support-slots which can hold any consumable item.

There are a few reasons behind this design choice. My initial impression was to make an item bar (like Terraria) and have the user put whatever usable items he wants to in it. Then I realized I really didn't like the way it would play. I wanted something akin to real life where you have a backpack full of stuff and a few pockets and things slung over your shoulder. So my second notion was to take the old 'primary weapon, secondary weapon, consumable, consumable' approach, where the player chooses which items he wants in those slots and has to swap them out each time. This sounded pretty good to me at first (and I may test it out once things get underway) but I wanted it to be easier to access weapons quickly instead of having to check the inventory every time.

My current implementation means that it will take time to switch between weapons and each weapon has to reload while equipped so managing ammunition is important. As far as Ammo goes, I'm currently sticking with just bullets, rockets, nails, etc. I thought about individual bullets for weapons but that would fill up the inventory quickly and might add a frustrating scenario of 'hey I found bullets to a weapon I don't have, I guess I'll wait and hope I do find it'. Again that might change in later releases.

For the next few days it's inventory, inventory, inventory. Streamlining the item process and getting equipment and consumables up and running. Also I need to work on the GUI for the inventory still and the weapon/consumable list. After the items I'm going to head back to the map generation and get to work.

Zity - The Island

Procedural Content Generation. The words alone send shudders down my spine. I have spent the past 5ish days working on getting an island generated. Not a full blown, tile based, streets-and-all island; but simply an image of the island that I'll use to create the previously said features. I wanted a land mass that was surrounded entirely by water and had an interesting coastline and possibly smaller islands nearby. Sounds easy. It's not.

I've trawled through dozens on dozens of sites and forums and blogs looking at different methods from complex polygon ones, to cellular automata, to perlin noise and gradients, and finally to perlin noise and particle gradients. There's a lot of information in a lot of different programming languages using a lot of different methods. Needless to say, my brain melted a little. I flip-flopped from gradient, to particle gradient, to polygon (hahahaha, no, I'm no genius), to automata, and finally settled back on particle. I'm happy with the results.

(The right picture is of the images that combine to form the picture on the left, each island has these)

Basically what this means is that I'll be able to control how the world will look like and can generate new worlds on the fly with only a few parameters. Another huge bonus to this method is that the amount of data the map needs to save is minimal since we can regenerate the map procedurally from it's parameters every time instead of saving the data to the disk.

I had wrote a draft of a blog post yesterday outlining how I was becoming frustrated with PCG (Procedural Content Generation) and basically had given up and moved on to the inventory, but after taking another crack at it today (I'm glad I did) I've finally made some progress.

Next up - Lakes/Rivers (or a break to work on the inventory)

Zity - Physics and Lights

Hello anyone and everyone. Things have been moving a little quicker now that I'm back into my normal routine. I've worked on some of the physics and lighting a bit more on the main menu and thought I'd share. As of a few minutes ago I've implemented vehicles using the wonderful Farseer Physics Library (Almost a direct port of Box2D). I had been using Farseer for awhile but this is the first major structure I've created. The vehicle has four functioning wheels (until I work on Semi trucks) and headlights and physics governing it's movement and collision. Below is a screenshot:

(Zombies are all gathering around the mouse, the car is controllable)

I've also added lighting to the main menu in the form of random colored lights speckled around the screen, a light that follows the mouse, and the headlights. The car starts out positioned so you can see the menu in it's lights. So far the whole thing runs 60+fps on my decent-enough laptop (and in debug mode) so I'm not concerned with anything yet except a few physics glitches with the zombies colliding with the car. My plan is to finish up the vehicle class by adding brakes, player capacity, turning on and off, and switching gears (going to drive, park, neutral). Then I'm going to work on making it flexible enough that to add a new car I would simply create the image of the car, figure out where I want the lights, tires, etc.. and then use those values to initialize it.

All-in-all I'm very excited about this. This has probably been the most content that I've crammed into the game in a long time and it's starting to turn from a bunch of systems and code libraries into a game. There's going to be a lot of fiddling and tweaking along the way but I'm still very much a believer in the end product of Zity.

Zity - Progress Update

These past few months have been busy. Sadly not too much in the way of Zity. The Christmas season left me with little time to develop and January saw me taking a trip to NJ to take care of some relatives for a bit. But throughout it all I've managed a few things and did a substantial amount of research and thinking, so here it goes.

XNA:
I knew XNA would be an amazing framework for my game as it is easy to pickup and maintain in a one-person studio. I also new that Microsoft was no longer supporting it. Months ago I looked into Monogame, an open source implementation of XNA that would make it easier (and possible) to target different platforms and operating systems and would be updated frequently. Recently I decided to start switching over my code and found it very quick and relatively painless to do so. From now on my game will be utilizing the Monogame framework and hopefully this will give me some extra drive to complete Zity knowing it won't be obsolete on release.

Zity:
So moving on to the state of the game. I spent my trip to NJ thinking about and prototyping parts of my game. I would go from notepad to notepad writing down thoughts and ideas and coding in between. What I came away with was a basic framework for networking. It is still in progress, but I have reached the point where it would be possible to connect to a server hosting Zity and to host a game of your own. I'm still porting my single-player code to the networking scheme so as of now there is no real information sent between server and client but that's next up after menus. MENUS. I hate menus. I spent two days or so revamping my main menu screen from a small list of navigable buttons to this:

(A swarm of zombies follow the cursor (Cursor is invisible currently))

My menu system uses events and currently leads through a few different options before dead-ending. This is simply because I'm still working on the networking game and I'm planning on using the same screen for both networking and single player to save on code reuse and make it easier for someone to host a game. Currently I'm using the menu screen as a sort of benchmark to see how the game will most likely run with all the lights, zombies, bullets, and physics running. If the menu screen is laggy the game will be laggy.

Other Thoughts:

Programming is tough. In a mental, rather than physical, way. It takes motivation, determination, and a clear understanding of the amount of work involved to progress. I find that some days my mind just can't grasp what I need it to and the thoughts just pass through my brain without reaching my mind. Other days code slips out of me like a waterfall and everything clicks. The key is to work on ANYTHING instead of working on nothing. In the days when I can't wrap my head around the code, I take to the notepads and start prototyping other systems or art or design. On days when I'm pounding out code like a machine I focus on completing sections instead of following rabbit trails. It can be so tempting sometimes to work on the fun things and ignore the issues but in the end it is substantially more satisfying patching up the issues and knowing that everything is working right and you won't have to go back and change things later. That's the thing that keeps me going, those moments where everything is working right and you can see the goal clear in your mind again.

In conclusion:

The next few months should see a lot of polish on the game engine side of things and after that: content.