🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Trial by Viking - WIP

Started by
50 comments, last by dqhendricks 8 years, 4 months ago

The boss battles and enemies look awesome in this. I especially liked the giant rock golem.

I chuckled when the player missed the viking boat jump and was devoured by that shark by surprise.

This game keeps looking better and better.

Watch videos of new indie games, updated daily. Promote your game on http://www.joinindies.com

Advertisement

The boss battles and enemies look awesome in this. I especially liked the giant rock golem.

I chuckled when the player missed the viking boat jump and was devoured by that shark by surprise.

This game keeps looking better and better.

Thanks Join Indies! Been working real hard on this.

Update #27:
Been revamping the throwing axes. Check it out and let me know what you think.
axes.gif

Good looking game! Visually, it reminds me of Gods.

Good looking game! Visually, it reminds me of Gods.

Thanks Lenny!

Update #28:
Today I would like to talk about player tracking flyers. This basically applies to any sort of player tracking where the enemy can move in any direction.
In essence, the idea is simple enough. Move the enemy towards the player's position. There are a few things you can do to improve on this however.
You can give the enemy a direction, a target direction (toward the player's position), and a maximum turning speed. This gives the enemy more of a homing missile movement feel, where they have actual momentum and cannot just change course at full speed on a dime. It's much more interesting to battle against as well.
You also have to worry about obstacles like walls. With just the basic code (following the player position), your enemy will run up against walls while aiming towards the player, making it extremely easy for the player to evade it. You can do some sort of path finding, but I don't really think that's fair, unless we are assuming the enemy is tracking the player using hearing alone at any distance with walls in between. Instead, I like to use line of sight to set the enemy's target. Line casting to find obstacles between the enemy and the player can be pretty expensive processing-wise, so I run it on a timer that only executes every 0.15 seconds or more, with a randomized lead time so the line casts for all of the enemies do not all fire on the same frame. The effect is, the enemy only sets it's target position when it can actually see the player (has a clear line of sight). This way the enemy chases the last position it saw the player at, allowing it to follow the player around corners.
Here is a gif comparing the flying enemy tracking the player's current position, versus having the enemy tracking the player's last "seen" position:
flyertracking.gif
Update #29:
Due to popular demand, I have added a melee ability. If you hold still and press up or down while attacking, you can do a high or low melee attack. This, along with the dash ability, helps a lot when you are trying to get a small critter, too low for throwing axes.
melee.gif
Update #30:
I wanted to talk a little bit about how I do cutscenes using the game engine. The cutscenes move the actors around the screen according to a script. It may include dialog, position movements, rotations, following with an offset, most with easing options. Here's a sample of what a piece of one might look like:
scene1.gif
I used to use a giant state machine to handle this, which was very difficult to edit. Now I use a helper class with a bunch of coroutines to handle each of the movements, then just put yields in to wait for their completion. Yields basically wait, and resume the code after a certain length of time. Coroutines are like functions, except the calling code does not wait for them to complete before continuing.
This way I can stagger movements in any way I like. I can start a position change on an object that occurs over the course of 2.0 seconds, then wait until 0.5 seconds in to that movement, then start a rotation change on that same object that occurs over 1.0 seconds. The rotation movement will complete before the position movement finishes, because this is all going on at the same time. It makes it really easy to make complex synchronous movements in one big linear script.
The helper class I created to move things around the screen is full of functions that look like this:
scenehelper.jpg
It lerps over a period of time. It can ease in, out, or in and out if needed. So you can imagine the helper class has functions for rotations, beziers, fades in and out, music changes. Basically everything that I'm going to be using in cutscenes over and over again (Except for dialog, which is handled in a separate class). For dialog, the main cutscene script can choose to wait until the player has clicked/closed the dialog window before continuing.
The result is a fairly easy to read linear script (sorry for the lack of comments):
scene1script.jpg
You could take this a step further, and make it run off of a text file full of text instructions that the class decodes into actual instructions for the cutscene. Something like that might be useful if you have a non-coder scripting your cutscenes.
@0xlastlifegames
Update #31:
Have been working on the melee attacks a bit. They are now all one button, and you can combo your attacks with increasing damage. A little bounce back on the hits feels really good, but it does have the tendency to knock you off of small platforms, so I'm not sure exactly what to do yet. I'll keep tweaking this until the end.
melee2.gif
Update #32:
I have ben working on redoing the lighting and adding lightmaps to the game. I like the way it's turning out. Here's a few new screenshots.
1.jpg
2.jpg
3.jpg
4.jpg
5.jpg
6.jpg

This topic is closed to new replies.

Advertisement