It's a bit too late to make a video and post it but I have made a good deal of progress this evening. Creeps are working for the most part as are towers. When the game plays itself with no interference from me they fight back and forth and given enough time one will destroy the others base.
Barracks spawn creeps at a steady rate and they do their thing. Still a long ling way to go but I started the day truly concerned if I'd be able to accomplish what you could technically call a game by the deadline.
I still have to create the player death and respawn functionality as well as create an enemy AI for the anti-hero bots. That said, I'm not quite halfway through the deadline and it's starting to feel like an actual game.
More later.
Tuesday, January 14, 2014
Wednesday, January 8, 2014
More progress, but it's very slow
This entire week has been hitting one unknown after the other. The GUI framework I'm using gave me some issues but the problem was my lack of experience with it.
I've implemented very basic healthbars for the tower and the player. I'm not very fond of the look but they are functional, and with the series of roadblocks I've hit recently I'll settle for functional right now.
I need to go through and clean up the code I'm using to move the bars around over the actor's heads. I'm also not happy with the camera angle still. I think I need a more "ground to horizon angle than I'm getting.
Lot's left to do and tomorrow night is already planned so no coding. That means I'm 1/3rd way through my time limit but definitely not 1/3rd of the way through the work that needs to be done.
I'm going to keep it at and hope I hit a spot where I blow through the workload and exceed my current output. Friday and Sunday are going to have to be good.
I've implemented very basic healthbars for the tower and the player. I'm not very fond of the look but they are functional, and with the series of roadblocks I've hit recently I'll settle for functional right now.
I need to go through and clean up the code I'm using to move the bars around over the actor's heads. I'm also not happy with the camera angle still. I think I need a more "ground to horizon angle than I'm getting.
Lot's left to do and tomorrow night is already planned so no coding. That means I'm 1/3rd way through my time limit but definitely not 1/3rd of the way through the work that needs to be done.
I'm going to keep it at and hope I hit a spot where I blow through the workload and exceed my current output. Friday and Sunday are going to have to be good.
Tuesday, January 7, 2014
A new technique
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.
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.
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.
Sunday, January 5, 2014
Day 5 - Lots of tuning
The last two days i've been implementing very basic combat, and tuning the click to move concept. I've also implemented a very rough version of stats. You can attack a tower and kill it, and visa-versa.
Tomorrow I need to push a lot of the code in the player object down to the player controller object. The abstraction isn't very well defined but it appears to fit in better there.
Currently the player can attack from anywhere on the map because I have implemented a concept of attack range but I've stubbed in some basic functionality to accomplish that. I'll tackle that tomorrow after work.
I need to implement the functionality where if you click on a target that is out of range you will move into range and then begin to fire at it. That's where the leaky abstraction part comes in, it's part player class and part character controller. I'm going with the controller abstraction.
No new videos to show as it's pretty much the same as last except the tower now fires at you.
I'll post a new video tomorrow after I've gotten the movement sorted out.
Tomorrow I need to push a lot of the code in the player object down to the player controller object. The abstraction isn't very well defined but it appears to fit in better there.
Currently the player can attack from anywhere on the map because I have implemented a concept of attack range but I've stubbed in some basic functionality to accomplish that. I'll tackle that tomorrow after work.
I need to implement the functionality where if you click on a target that is out of range you will move into range and then begin to fire at it. That's where the leaky abstraction part comes in, it's part player class and part character controller. I'm going with the controller abstraction.
No new videos to show as it's pretty much the same as last except the tower now fires at you.
I'll post a new video tomorrow after I've gotten the movement sorted out.
Wednesday, January 1, 2014
Night One in the Books
I roughed out the camera control and the player "click to move" in one evening. I'm sure I'll have to touch it again but I was only aiming to finish the camera. Off to a good start.
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.
Subscribe to:
Posts (Atom)