Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411273 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 02:32:30 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsBarbearian - Fast-paced hack'n'slash action in a colorful hand-drawn world
Pages: 1 2 [3] 4 5 ... 13
Print
Author Topic: Barbearian - Fast-paced hack'n'slash action in a colorful hand-drawn world  (Read 42406 times)
gimblll
Level 2
**



View Profile WWW
« Reply #40 on: March 14, 2017, 03:41:19 AM »

Log Entry #13

Drawing stuff, some characters and props and such. Will probably continue for a few days more. Not much more to tell really, so I'm going to just show. I wish I could do this much more, too much fun. Smiley

The Usual Suspects
« Last Edit: March 14, 2017, 07:01:55 AM by gimblll » Logged

gimblll
Level 2
**



View Profile WWW
« Reply #41 on: March 17, 2017, 10:16:17 PM »

Some garden props from this week's drawing sessions.

Logged

gimblll
Level 2
**



View Profile WWW
« Reply #42 on: March 22, 2017, 05:48:44 AM »

Log Entry #14

- Made a first pass at some proper layout for my hub level and put all new props and characters I drew there

- Refactored my level exit portal so I can do some future gameplay changes (planning to change how level ends) Also now you leave the hub world through the same level portal that ends normal levels (that should teach the player that it's not something to avoid as it looks a bit threatening)

- Did a new feature to my localization system (grouping strings under one label) so I can write simple dialogue for story characters. Also did a quick 'tag replacement' system for it so I can write <something> to the localization strings and get that automatically filled into whatever in-game.

- Integrated my old speech bubble system to the dialogue system (picture). It's a bit cumbersome now though, so I'll probably rework it. Now it uses a series of hand drawn speech bubble images and picks one with the closest match to the text size, but I'll probably change it to standard 9-slice kind of system as it's much easier to do assets for that. Did the original system because I thought it would look better to have more hand drawn bubbles (variations in shapes etc.)... but need to cut it, too much work to do assets for it.

Next up: It's one or two days of work on the level-hub still and then... Not sure, might be time to do some gameplay stuff again.

Logged

gimblll
Level 2
**



View Profile WWW
« Reply #43 on: March 29, 2017, 03:25:51 AM »

Log Entry #15

Finished the level hub stuff. It's not finished by any means, but there's something there now to give an idea of what it will be.

Now I've been thinking how to improve the gameplay. It's not very dynamic and kind of enforces a similar play style always. It also kind of leads players to play too defensively often. I'd like it to have more random elements and for there to be more benefits for being attack minded. I'm going to make a new weapon system, so the boost attack is no longer always available, but is one of a number of weapons you can collect. There'll always be the axe melee attack, but the secondary attack is something you pick up. I hope it works a bit better then! I also have a few other ideas, but I'll start with the weapons as it's easily the largest task.

Also drew this 'concept art' during a few weekends. Could put some like these in the game as some sort of story pieces maybe, not sure if it's worth it? Any thoughts?

Abduction
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #44 on: April 04, 2017, 06:17:20 AM »

Log Entry #16

Wrote prototypes for a bunch of weapons. Now tomorrow I'll start to integrate them as pickups into the levels. Should also do a few other improvements to the gameplay flow and see how all this works out. Not much else to report I guess.
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #45 on: April 07, 2017, 11:28:45 PM »

Path Finding in Barbearian

One key element in the game is that there area a lot of units, and they might be all moving at the same time in the worst case. To enable this, they need to have a very fast path finding method. I thought I'd write how it works in my game.

Disclaimer: This is not a guide on how to do a great job at this, this is just how I did it.

The Problem

My gameplay level is 2D grid and I need to know how to get from point A to point B.

Some options I thought about

a) No path-finding at all. Just go towards target with some obstacle avoidance and get stuck if there's a problem. Many simple games work fine like this.
b) Do full A* pathfinding when needed (slow to do all paths separately, annoying to do a cache, maybe...)
c) Some kind of vector pathfinding graph. Complicated. Still needs some processing per unit (never seriously looked into it though)
d) Some kind of dynamic flow fields (never really crossed my mind back then, only later noticed that it might be interesting... probably not suitable to this game though)
e) Calculate ALL THE PATHS

I chose to try option E, because I liked the simple and elegant implementation (+ performance was guaranteed without trickery).

The Solution

For every tile, I store a full Djikstra search, i.e. I store a direction you need to walk towards if going to any other selected tile. The code interface takes a source tile and a destination tile, and the function returns the direction where the next tile you need to walk to is. (Can also return 'path is blocked' or 'path is not yet calculated')

Visualization of one cached path table


Pseudo code
Code:
struct Path_Grid
{
uint Get_Pathing_Direction(vec2 tile) const
{
uint entry = m_pathing_grid[tile];
entry >>= (tile.x % 2) * 4;
entry &= 0xf;
return entry;
}

// 4 bits per entry (neighbour idx, or no path) (X rows contain two entries per cell)
Grid<uint8> m_pathing_grid;
}

Path_Grid Get_Path_Grid(vec2 tile)
{
if (cached(tile)) return cached_grids[tile];
else { prioritize(tile); return not_found; }
}

Path Get_Direction(vec2 source_tile, vec2 target_tile)
{
return Get_Path_Grid(target_tile).Get_Pathing_Direction(source_tile);
}

void Frame_Update()
{
fetch next uncached grid and fill it with Djikstra etc.
}

This happens very often in a frame, so it needs to be fast. With this system, it's just table lookups. Note that when we calculate a full path grid, we calculate all paths from every cell to one target cell.

Problems

- Memory usage is high and grows exponentially with level size.

I store 4 bits of information per tile (walk direction) and I need to store (64x64)^2 of them in the worst case (my max level size for now), so that takes 8MB. Problem is that it grows exponentially if I make the levels larger, so mobile device memories will fill up quite fast.

- It's slow to calculate the full path table cache

I optimized my Djikstra search to the point where it's fast enough, but filling the whole cache takes some time no matter what you do. And my cache invalidates when the level collisions change (could probably do something more intelligent there, but it's not worth the extra code)

I get by this by only doing one full search per frame (which is about the max CPU budget I can spend on this on my lowest mobile target) and prioritizing whatever is currently needed. Sometimes units need to think a few frames before they get their paths, but it's unnoticeable in the game. When there's been no queries for uncached paths, the system continues filling the other path tables until full.

Filling the cache: red squares are the target tiles that have path cache filled for them


Extra Complications

- Some tiles are split in half, i.e. half of it is water and half of it is ground. I just flag these as 'unwalkable' so pathing avoids them. If the unit wonders there regardless, I have filled the path tables so that after the Djikstra fill, I do an extra fill that adds directions away from blocked/unwalkable tiles to the nearest properly pathed tile. (See the 'OUT' tile in the info pic)

- I also store a bit of extra information for if the path to target is 'long' (arbitrary constant). As the path query doesn't give instant answer to how long the path to target is without recursing through the path, this extra bit will allow me to do super simple tests to see if it's worth the trouble to start attacking something (for example if the player is behind a wall really close, but actually walking there would take a long way, then the enemy just does nothing instead of aggroing)

Future Improvements

- Path tables for all tiles are allocated in memory, even though most of them will never be used. Memory usage could be optimized by making a more intelligent allocator and dropping the the ones least likely to be used by some heuristics.

- Some kind of hierarchial path finding system would probably allow me to reduce the exponential memory requirements and grow level sizes, but I haven't really given it much thought as I've so far managed with this.

--

That's about it. On top of that there's some simple steering behaviour (+ army formation movement too). One thing of note is that there is no obstacle avoidance. The enemies just ignore trees for example and trust that the collision engine will push them away. All colliders are round and things are spaced sparsely enough, so there should be no 'collision traps'. That doesn't always work out, but it's good enough for now at least (the gameplay doesn't require infallible pathing).

If anyone found this interesting, let me know so I know if it's worth writing more of these some day. Smiley
« Last Edit: April 08, 2017, 12:13:50 PM by gimblll » Logged

miconazole
Level 1
*


contact through email pls


View Profile
« Reply #46 on: April 08, 2017, 02:03:45 PM »

There's already a game called Bearbarians so you might have to change the name if you're concerned about confusion.
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #47 on: April 08, 2017, 07:51:46 PM »

There's already a game called Bearbarians so you might have to change the name if you're concerned about confusion.

Yeah, it's just a working title, I don't yet have a final name.
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #48 on: April 12, 2017, 04:31:36 AM »

Log Entry #17

- So I did a bunch of weapon tests / prototypes. Really hard to say if it's an improvement, but I decided that I'm going to do them anyway. Smiley I hope that's not a mistake, but the current gameplay is too shallow to stay fresh for long... something I painfully realized after latest playtesting feedback from friends. The weapons are step one in fixing the problems. (I have other things planned too, but let's see about them when I get there)

- So from that, I decided that I'll convert my main character from rendered sprites, to use Spine runtime. That's so I can do switchable weapons etc. without taking a huge amount of sprite memory and I can more easily do the code too. The conversion took some time to do, but now it's done. Next I'll take a few of the weapons from prototype stage to full-polished stage and see how that feels.
Logged

Zireael
Level 4
****


View Profile
« Reply #49 on: April 12, 2017, 06:19:07 AM »

I love the isometric perspective. That special attack which killed mobs and felled trees looks awesome, too.

What are you using in terms of engine/language?
Logged
gimblll
Level 2
**



View Profile WWW
« Reply #50 on: April 12, 2017, 11:27:20 AM »

Thank you!

I have my own engine (with various open source components). I use mainly C++, but there's a bit of Lua in it too. And some Python for tools.
Logged

mrKaizen
Level 2
**


View Profile WWW
« Reply #51 on: April 13, 2017, 08:40:21 AM »

Love the art style of the game, the explosions and efx are GREAT. -_^
Thank you!

I have my own engine (with various open source components). I use mainly C++, but there's a bit of Lua in it too. And some Python for tools.
Nice, you are sure a great coders man Wink respect for using your own engine, I understand all the difficulties of making one: my friend wrote our game engine with python from scratch and it takes years and was a IMMENSE challenge, but at the end your knowledge becomes very high and you have control on everything >> you know where to fix stuff Tongue .

So, good luck with it!
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #52 on: April 13, 2017, 08:22:09 PM »

Nice, you are sure a great coders man Wink respect for using your own engine, I understand all the difficulties of making one: my friend wrote our game engine with python from scratch and it takes years and was a IMMENSE challenge, but at the end your knowledge becomes very high and you have control on everything >> you know where to fix stuff Tongue .

So, good luck with it!

Thanks! It's not that complicated to do an engine, but it is a lot of work. Smiley

A whole engine in Python? Wow, that must've been an interesting challenge. I did one jam-game with pygame years ago, but that's about it.
Logged

mrKaizen
Level 2
**


View Profile WWW
« Reply #53 on: April 14, 2017, 12:30:14 AM »

Nice, you are sure a great coders man Wink respect for using your own engine, I understand all the difficulties of making one: my friend wrote our game engine with python from scratch and it takes years and was a IMMENSE challenge, but at the end your knowledge becomes very high and you have control on everything >> you know where to fix stuff Tongue .

So, good luck with it!

Thanks! It's not that complicated to do an engine, but it is a lot of work. Smiley

A whole engine in Python? Wow, that must've been an interesting challenge. I did one jam-game with pygame years ago, but that's about it.
eheh yes a lot of things to code and then there can be also the problem to export your stuff to other platforms. We made it with Linux, more or less, but we failed with Mac - problems with libraries that weren't that compatible really...
 
I'm not a python programmer but my friend is a pro Tongue (and he don't like that much pygame Tongue even if I've tried it and was fine)and we made this action adv in 3D http://store.steampowered.com/app/324390 - I made design and concept, he everything else. A ton of work but as said it we are very very proud of the result.
And I think you can be too with yours, it looks very promising and all the efx are soo fun to watch.  Kiss
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #54 on: April 19, 2017, 01:24:08 AM »

Log Entry #18

- So now I've got the hero running through Spine runtime instead of sprite sheets. Saves quite a bit of sprite sheet space too, which is great. Also unexpected (or something I didn't think of) side effect is that the player animates at 60fps now, whereas my sprite sheets are rendered at 30fps... looks pretty nice, though not something anyone would probably notice. It took a bit longer than expected, but now I'm happy that I have a framework in place that I can switch from sprite sheet animations to Spine animations transparently without modifying gameplay code (unless I'm doing something special with Spine). I'll probably use it for some larger, less common enemies too.

- Then started building the weapon system visualization properly, drew a few weapons and made a skinning/animation systems for them with Spine... Now trying to put some polish for the first weapon to get a better feel how this system will work in the game (prototypes can only tell so much). I really hope all this work isn't for nothing... Smiley

- Also just tried to do a generic explosion effect I could use in some places, not sure if this looks good anymore... been watching and tweaking it too long. Need to take a break doing something else.

Logged

Schrompf
Level 9
****

C++ professional, game dev sparetime


View Profile WWW
« Reply #55 on: April 19, 2017, 02:58:11 AM »

Thanks for the updates! I need to keep Spine on my radar... always thought it's some Unity plugin, but if it actually got a C++ API, it gets interesting again.

I like the item spawn effect. The explosion, though... I think in reality the smoke wouldn't rise that fast, or not at all. But I feel your pain, just leave a note on some your lists to revisit it later.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
gimblll
Level 2
**



View Profile WWW
« Reply #56 on: April 19, 2017, 03:05:58 AM »

Thanks for the updates! I need to keep Spine on my radar... always thought it's some Unity plugin, but if it actually got a C++ API, it gets interesting again.

Definitely check it out, I really like the whole system and the developers seem really active too. It has a C API (with full source) + it's got runtimes for pretty much every engine out there. Integration to my engine was pretty easy (though the API is probably not the cleanest code you've ever seen).

I like the item spawn effect. The explosion, though... I think in reality the smoke wouldn't rise that fast, or not at all. But I feel your pain, just leave a note on some your lists to revisit it later.

Thanks! Yeah, I'll need to work on the explosion again. Difficult to balance between too "realistic" and too cartoony. (+ all the tech limits I have)
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #57 on: April 22, 2017, 05:59:29 AM »

#screenshotsaturday time!

Testing out one of the new weapons, gravity gun or something. It's a bit too powerful right now, but I'll get around balancing things later.

Logged

gimblll
Level 2
**



View Profile WWW
« Reply #58 on: April 25, 2017, 10:44:03 PM »

Log Entry #19

Feels like a slow week of progress, but I guess I always feel like that.

- Finished 4 different weapons up to polished state. They're pretty fun to use, but need to be integrated better into the game progress (when are they given, etc.).

- Now updating "captains". These are the key enemies that you're supposed to kill in each level. There's already one in, but it's very boring without any interesting gameplay. Just walk to it and hit it enough and that's it. Basically normal melee enemy with more health. It was originally a prototype to test the whole 'level goal' system and as such, they work well I think. So I've decided to make them a little more interesting, draw better look for them and give them a more gameplay personality. And do a couple of different types of captains too (melee, ranged, etc.). So that's going to take a lot of time now. Currently I'm sketching the new look.
Logged

gimblll
Level 2
**



View Profile WWW
« Reply #59 on: April 28, 2017, 10:13:39 PM »

Here's the new-look captain in some #screenshotsaturday action. It works much much better than the old one, quite happy with that. Could try to find some use for the old sprites too, annoying to waste work. Now I'll try a couple of other captain types too (ranged attack captain at least first).

Logged

Pages: 1 2 [3] 4 5 ... 13
Print
Jump to:  

Theme orange-lt created by panic