Having solved the tower issue last night tonight I had a little over an hour to start on the same issue except this time with barracks. The tower solution didn't scale well because of all the edge cases.
Basically the size of the target determined how well my solution worked. A tower approached from any side is equidistant from the center which is where all of my aiming was going. Once I tackled a barrack the issue became obvious, from a flat side the creeps and the player attack from one distance, from a corner side they attack from another distance. The center of a rectangle varies in distance from various points on the perimeter.
To solve this I'm not aiming and moving to the nearest bound of the collider attached to the target. This has the added benefit of stopping the creeps at the proper distance from the target consistently. This may also solve the issue I was having with baking the navmesh and then raycasting to holes in the navmesh.
I'll have to test the solution more thoroughly tomorrow. But calling it a night it looks promising. I feel like I'm behind scehdule. Its one week in and I'm still working on the controllers and basic AI. These components have to be right but there's so much more to do and not so much time to do it.
Next step needs to be life, death, and combat in between. Afterwards its creep spawning, and base destroying. Big topics, lots of work in between. Time for bed.
Showing posts with label unity. Show all posts
Showing posts with label unity. Show all posts
Tuesday, January 7, 2014
Monday, January 6, 2014
Day 7 - Navmesh Hell
I burned most of the day working out a few subtleties in Unity's navmesh system. I'm not 100% happy with the way I put it together but its largely functional.
The navmesh system builds simple geometry and you use this geometry to navigate around your map. The problem I ran into is my towers are static, meaning they never move so Unity was cutting out holes in the navmesh for them. This is intended behaviour. Later, when I tried right clicking to attack them I would have to move my player within range of the tower to use his auto-attack. This is where the problems began.
The intended behaviour is that Unity provides a position that is the nearest edge to where you clicked. However, this turned out to vary wildly per click and made closing to weapon or spell range sporadic and sometimes just plain buggy.
The fix I used was to include a navmesh obstacle onto the tower and to re-bake the navmesh without the tower. This allows the right click to always land on the navmesh and for the player controller to accurately close distance so you are in spell or weapon range.
The downside is you can walk right through the tower as if it isn't there.(per the navmesh system it isn't), the navmesh obstacle makes your character controller avoid it, so you could technically still walk through it, or be pushed through it by another agent, however in light testing it appears to be holding up as intended.
That worked through, I've implemented a very basic combat system. Right clicking an actor that is not on your team causes you to close to auto attack range and start auto attacking. I've equipped the player with a fireball spell that autocasts every 2 seconds as long as he's in range.
Attacks do damage and the tower will quit firing when it's "dead". The player has health, but is still immortal at the moment.
I've also begun the basics of the creep AI. Right now if he's on your team he'll attack enemy towers or move to a waypoint I've set up. If I switch him to the opposing team he'll chase the player around until you leave his range of vision.
All in all it's been a decent couple of development days. The navmesh issue burnt a lot of time but appears to be mostly conquered at this point.
I've also implemented a very basic GUI using DaikonForge. The design time tools are great but I found out after purchasing it that it doesn't handle world space GUIs at all. This means I'll have to roll my own healthbars and damage numbers.
Time for the obligatory video:
this shows a creep chasing me around and then attacking a tower, it also shows the tower attacking the creep and me attacking the creep. Nothing fancy yet, still a lot of plumbing work to do.
The navmesh system builds simple geometry and you use this geometry to navigate around your map. The problem I ran into is my towers are static, meaning they never move so Unity was cutting out holes in the navmesh for them. This is intended behaviour. Later, when I tried right clicking to attack them I would have to move my player within range of the tower to use his auto-attack. This is where the problems began.
The intended behaviour is that Unity provides a position that is the nearest edge to where you clicked. However, this turned out to vary wildly per click and made closing to weapon or spell range sporadic and sometimes just plain buggy.
The fix I used was to include a navmesh obstacle onto the tower and to re-bake the navmesh without the tower. This allows the right click to always land on the navmesh and for the player controller to accurately close distance so you are in spell or weapon range.
The downside is you can walk right through the tower as if it isn't there.(per the navmesh system it isn't), the navmesh obstacle makes your character controller avoid it, so you could technically still walk through it, or be pushed through it by another agent, however in light testing it appears to be holding up as intended.
That worked through, I've implemented a very basic combat system. Right clicking an actor that is not on your team causes you to close to auto attack range and start auto attacking. I've equipped the player with a fireball spell that autocasts every 2 seconds as long as he's in range.
Attacks do damage and the tower will quit firing when it's "dead". The player has health, but is still immortal at the moment.
I've also begun the basics of the creep AI. Right now if he's on your team he'll attack enemy towers or move to a waypoint I've set up. If I switch him to the opposing team he'll chase the player around until you leave his range of vision.
All in all it's been a decent couple of development days. The navmesh issue burnt a lot of time but appears to be mostly conquered at this point.
I've also implemented a very basic GUI using DaikonForge. The design time tools are great but I found out after purchasing it that it doesn't handle world space GUIs at all. This means I'll have to roll my own healthbars and damage numbers.
Time for the obligatory video:
this shows a creep chasing me around and then attacking a tower, it also shows the tower attacking the creep and me attacking the creep. Nothing fancy yet, still a lot of plumbing work to do.
Wednesday, January 1, 2014
January 1 Game a Month Challenge
January 1st 2014, a new year, a new month, a new game. This month's entry is much more ambitious than last months. The working name for this game is SOBA. Single-Player Offline Battle Arena. A fun riff off of DoTA2 and LoL style MOBAs.
The bare bones is what I'm going for so I'll use simple primitives and base materials for the game "art". I'm trying to tackle a bunch of functionality so I'm going to focus on code and placeholders, maybe even through the end of the month.
The 1 game a month challenge now allows you to revisit previous entries and expand on them. The key concept being "save-points" that is, the game must be finished at the end of the month and be an actual game. This is to avert tackling ambitious projects that go nowhere. At the end of the month you may only have an unattractive, mediocre game, but you WILL have a game.
For a project this ambitious I'm going to have to rely on lots of coding and functionality to complete the entire feature set. I'll worry about the art pass if I have time, and if not I'll hit my goal of a complete game that lacks polish, and swing for a 2.0 version in February.
Lots to do so wish me luck. I'll post videos and web builds throughout development to show the various iterations as the game goes from an empty project file to a completed game.
The bare bones is what I'm going for so I'll use simple primitives and base materials for the game "art". I'm trying to tackle a bunch of functionality so I'm going to focus on code and placeholders, maybe even through the end of the month.
The 1 game a month challenge now allows you to revisit previous entries and expand on them. The key concept being "save-points" that is, the game must be finished at the end of the month and be an actual game. This is to avert tackling ambitious projects that go nowhere. At the end of the month you may only have an unattractive, mediocre game, but you WILL have a game.
For a project this ambitious I'm going to have to rely on lots of coding and functionality to complete the entire feature set. I'll worry about the art pass if I have time, and if not I'll hit my goal of a complete game that lacks polish, and swing for a 2.0 version in February.
Lots to do so wish me luck. I'll post videos and web builds throughout development to show the various iterations as the game goes from an empty project file to a completed game.
Wednesday, December 25, 2013
Br'er Rabbit 1.5 - Final Submission
The artwork is in, the game play is complete, the control system could use some work but I've determined that this will be the final state of my first 1 game a month submission.
I need some time to recharge before the January challenge and I'm hitting the busiest week of the year in my day job.
Once I have some space I'll try and write a proper post-mortem but in case I don't here are my current thoughts.
1)I have a lot to learn but that is no real obstacle. Every little issue I ran into is just a matter of learning the API or medium level problem solving.
2) Unity is made for this type of stuff. Having written 3 relatively sophisticated 3d engines over the years it is clear how unsophisticated they actually were. You make games with the toolchain and that's where Unity shines.
3) I can make a game in a month. It's not beautiful or ground breaking but it's a game, cut from whole cloth and made in 25 days. I definitely intend on repeating this success in January.
4) Artwork is fully 1/2 of the equation. Unfortunately for us programmers it's the important half. The difference between the game when I was using placeholders and when I put the skin on it is wild. I'd love to find an artist that was interesting in making a game in a month and see what we could do combined.
5) Unity Asset Store is a great resource. All of the art in the game is a free asset excluding the wolves and the rabbit. Grand total cost for all of the art. $25.
Here's the final video:
Here's the final link to the game:
Br'er Rabbit
Time to recharge and reload, for January I'm going for a much more ambitious project.
I need some time to recharge before the January challenge and I'm hitting the busiest week of the year in my day job.
Once I have some space I'll try and write a proper post-mortem but in case I don't here are my current thoughts.
1)I have a lot to learn but that is no real obstacle. Every little issue I ran into is just a matter of learning the API or medium level problem solving.
2) Unity is made for this type of stuff. Having written 3 relatively sophisticated 3d engines over the years it is clear how unsophisticated they actually were. You make games with the toolchain and that's where Unity shines.
3) I can make a game in a month. It's not beautiful or ground breaking but it's a game, cut from whole cloth and made in 25 days. I definitely intend on repeating this success in January.
4) Artwork is fully 1/2 of the equation. Unfortunately for us programmers it's the important half. The difference between the game when I was using placeholders and when I put the skin on it is wild. I'd love to find an artist that was interesting in making a game in a month and see what we could do combined.
5) Unity Asset Store is a great resource. All of the art in the game is a free asset excluding the wolves and the rabbit. Grand total cost for all of the art. $25.
Here's the final video:
Here's the final link to the game:
Br'er Rabbit
Time to recharge and reload, for January I'm going for a much more ambitious project.
Sunday, December 22, 2013
Rabbit 1.4 - A facelift
I made a detour the last couple of days because I hit a wall in development. Every line I code I was writing was suspect and I just couldn't get it going. In an attempt to practice useful procrastination I started adding art assets to the game so what I had relegated to "nice to have" made it in before a few "must haves".
I did get the progressive score system working and tune the game quite a bit though. It's more difficult now and the game adds extra wolves at a faster rate. So not a total loss. It is sometimes frustrating to me how important good artwork is in the actual construction of a game as that is an area I have a lot of work left to achieve a reasonable level of competency. Just not enough hours in the day, especially with the hard 1 month deadline.
I'm already looking forward to the next months challenge and have been thinking about some game ideas for January.
Here's the current state of the Rabbit 1.4
and here's a link to this build
https://dl.dropboxusercontent.
Enjoy and I'd appreciate any feedback.
I did get the progressive score system working and tune the game quite a bit though. It's more difficult now and the game adds extra wolves at a faster rate. So not a total loss. It is sometimes frustrating to me how important good artwork is in the actual construction of a game as that is an area I have a lot of work left to achieve a reasonable level of competency. Just not enough hours in the day, especially with the hard 1 month deadline.
I'm already looking forward to the next months challenge and have been thinking about some game ideas for January.
Here's the current state of the Rabbit 1.4
and here's a link to this build
https://dl.dropboxusercontent.
Enjoy and I'd appreciate any feedback.
Thursday, December 19, 2013
Rabbit 1.2
To trudge... the slow and determined march of a man bearing a heavy load...
Ok, enough melodrama. I'm posting this on the 19th but this video was recorded on the 17th and reflects that progress. The simple flashing of the "wolves" required me to refresh my memory on how coroutines work in Unity. After a few stumbles I finally figured it out and also added a sound for when you eat the "carrot" power up.
With 11 days remaining on my first entry for the 1 Game a Month blog, I've hit on what I believe to be the final scope of this project.
I initially hoped to have several maps, and to progress through the maps as you cleared levels. Maybe 5 or 10 plays per map and then I'd alter the maze, move the power ups around, perhaps introduce additional wolf types.
Here's my final punch list. If I have time beyond this I'll spend it on small features I can add in a single coding session or polish.
More importantly than what I will be able to implement is what I won't be able to implement. That's the sort of lesson the 1 Game a Month challenge teaches, you must ruthlessly attack the scope of your game.
Ok, enough melodrama. I'm posting this on the 19th but this video was recorded on the 17th and reflects that progress. The simple flashing of the "wolves" required me to refresh my memory on how coroutines work in Unity. After a few stumbles I finally figured it out and also added a sound for when you eat the "carrot" power up.
With 11 days remaining on my first entry for the 1 Game a Month blog, I've hit on what I believe to be the final scope of this project.
I initially hoped to have several maps, and to progress through the maps as you cleared levels. Maybe 5 or 10 plays per map and then I'd alter the maze, move the power ups around, perhaps introduce additional wolf types.
Here's my final punch list. If I have time beyond this I'll spend it on small features I can add in a single coding session or polish.
Will do:
1) One more score dynamic - A progressively higher score for each wolf you eat per power up.(1 wolf gives say 500 points, second 1000, third 2000, etc... resets when you lose your power up status)
2) One more presentation update - A pause when you are killed, then a "you got killed sound" then a reset, then a go! Death is abruptly handled currently with no time to gather yourself before the game continues.
3) Play-balance the game - It is currently too easy. My primary plan is to adjust the scoring system to reduce the number of extra lives you get per map.
4) Polish - The sounds get the point across but a few hours working on the sounds and adding a few particle effects will go a long way as far as the feedback the system gives you. Without pretty visuals I need to insure that the feedback is tight and obvious.
More importantly than what I will be able to implement is what I won't be able to implement. That's the sort of lesson the 1 Game a Month challenge teaches, you must ruthlessly attack the scope of your game.
Won't do:
1) Multiple mazes/levels - I have a great idea for a dark level where a spotlight follows the rabbit around the level and you can't see what you've "eaten" and what you haven't. Not going to happen for this entry. Maybe some other entry I'll pick it back up and go for it.
2) Proper artwork - I could buy appropriate models and pick up the game visuals by using a proper shader. Maybe, maybe I can hit this mark but I'm putting this weight down as far as a "must have". It's definitely in the "nice to have" list.
3) Intermissions - I wanted a black background cut scene similar to the intermissions in pacman between map changes. No map changes though, so no cut scenes for sure. This would have to wait for a round 2 attack on this project. I simply won't have time to implement this.
4) Android release - I've yet to tackle an Android release but even if its easy as pie I know I'll have to re-write the control scheme for a virtual D pad. As fun as this would be it won't make the cut for December.
Still on target to make my first challenge. I deployed a web player and linked it to a few friends just for the fun of it. I intended to provide links to incremental builds so you could follow along as the game progresses but I got caught up in making the deadline and slacked a bit on blogging my progress.
Here's the link to Rabbit 1.2 - https://dl.dropboxusercontent.
In all its splendor! OK, in all its programmer art, still missing a few key features, splendor!
and here's a short video of a play through.
Wednesday, December 11, 2013
Rabbit hits 1.0
Pretty exciting to be honest. A 1.0 revision simply means that the game is playable. You can win, you can lose. The fundamental criteria of a game is in place. This feels like quite an accomplishment given this is the busiest month of the year at my day job.
Next round of development involves adding some variety between levels and improving the feedback the game gives you.
One idea along this line are to add a variety of wolves, and to have the spawn rate increase as you go up levels. The alpha wolf will hunt your current position ruthlessly. A hunter wolf will wander randomly until he picks up your scent and will follow it until he gets you. What's pictured currently is the soldier wolf. He just wanders randomly around the map with no chasing ability at all.
Another idea is to add a power-up spawn that randomly traverses the level at a slow pace. The power up will give you a point bonus and a variety of temporary power ups. What these are is still anyone's guess. A speed increase, invulnerability, maybe some other effect. I need to play test a few ideas and see where the fun is.
Here's the underwhelming, but inaugural 1.0 Video.
Next round of development involves adding some variety between levels and improving the feedback the game gives you.
One idea along this line are to add a variety of wolves, and to have the spawn rate increase as you go up levels. The alpha wolf will hunt your current position ruthlessly. A hunter wolf will wander randomly until he picks up your scent and will follow it until he gets you. What's pictured currently is the soldier wolf. He just wanders randomly around the map with no chasing ability at all.
Another idea is to add a power-up spawn that randomly traverses the level at a slow pace. The power up will give you a point bonus and a variety of temporary power ups. What these are is still anyone's guess. A speed increase, invulnerability, maybe some other effect. I need to play test a few ideas and see where the fun is.
Here's the underwhelming, but inaugural 1.0 Video.
Sunday, December 8, 2013
One Game a Month Entry
I've decided to work on a One Game a Month entry to put a finished project in my portfolio. The game is a riff off of PacMan, but I'm going to alter the mechanics enough that it should play quite differently.
I'll also document development on this blog. My process will be to get a functional game up and running, primarily with programmer art and royalty free sounds I make or find online, and then I'll hopefully get to spend quite a bit of time on polish.
I started December 1st and have until December 31st to complete the project. As of the eighth I'm probably 7 or 8 good days of coding away from being able to say "game"
Once I've gotten to the point where you can actually "win" and "lose" I'll start working on the mechanics and try and maximize the fun. After that, time allowing, I'll replace the programmer art with something that is higher quality and put proper animations and User interface skins in.
I'll also document development on this blog. My process will be to get a functional game up and running, primarily with programmer art and royalty free sounds I make or find online, and then I'll hopefully get to spend quite a bit of time on polish.
I started December 1st and have until December 31st to complete the project. As of the eighth I'm probably 7 or 8 good days of coding away from being able to say "game"
Once I've gotten to the point where you can actually "win" and "lose" I'll start working on the mechanics and try and maximize the fun. After that, time allowing, I'll replace the programmer art with something that is higher quality and put proper animations and User interface skins in.
Subscribe to:
Posts (Atom)