Support NeoGAF

[Jobbs]

This environment is pretty temp here (I plan to put something cool here).

http://gfycat.com/DisfiguredMilkyFlamingo

I know you guys love this effect, so I thought I'd share.

 

[TunaUppercut]

This environment is pretty temp here (I plan to put something cool here).

http://gfycat.com/DisfiguredMilkyFlamingo

I know you guys love this effect, so I thought I'd share.

It looks really cool. Such great art direction. keep it up.

 

[cbox]

This environment is pretty temp here (I plan to put something cool here).

http://gfycat.com/DisfiguredMilkyFlamingo

I know you guys love this effect, so I thought I'd share.

whoa caught me off guard, looks slick!

 

[Rubikant]

Hey, anyone here interested in helping me figure out a good way to implement a shotgun blast effect in my upcoming game, Eternal Helix? The game will be in an overhead perspective.

Keep in mind I'm the programmer/designer, but not the artist, so I'll need to explain what elements are needed to the artist once I figure out how to make this work. Also all the artwork you see is of course still a work in progress!

Here's the problem - I'm going for the standard game trope of the shotgun having very little range but high attack power. At first I thought an easy way to implement a shotgun is to just display a single "shotgun blast effect" in front of the gun that's drawn at the right size for the range of the gun, and assign a single collision box to cover the entire shotgun's range at once, and forgoing bullet physics altogether. Like this:

The green rectangle represents the potential collision - imagine there was also an animated sprite representing the blast from the shotgun and giving a visual indicator of its range based on that green rectangle.

That seems like a nice simple way to do it, but then you have the problem of the player shooting at a wall:

While I can easily come up with a code solution to prevent this shot from actually damaging enemies on the other side of the wall, the canned "shotgun blast" sprite the artist will make will be visible on the other side of the wall, which makes no sense. So I need something that looks decent but can still take walls into account and shorten the visual effect. Corners make it even more tricky, compared to a straight bullet from a pistol or rifle.

Here are some thoughts I've had about this thus far:

1. Some games just have shotguns shoot 3-5 bullets in a wedge pattern from the shotgun. This nicely solves the wall problem but it doesn't really feel like a shotgun at that point to me, it feels like a short-range spreadshot gun. I'd rather not use that if I can figure out something that looks more natural, but if all else fails I can fall back on this.
   
2. One solution is to have the shotgun blast effect come out of the end of the gun only a short distance (less than a tile) and not actually include a visual indicator of the full range of the shotgun. The player would have to learn through experimentation how long the actual range of the blast is rather than just being able to see it. It would be nice to show it, but I'm not completely opposed to the idea of making players figure things out through experimentation. I have seen some games do this with shotguns (FPS's in particular don't generally have any obvious indication of a shotgun's range without experimentation, but I've seen some 2D games do the same).
   
3. I've thought of doing the 2-5 bullets in a wedge pattern solution, but making the bullets invisible and having each frame the bullets spawn some kind of dust/smoke effect (the effect would just be stationary and quickly fade out) at their current position as they travel. That way if they go the full distance, the entire blast area would be briefly filled with dust/smoke particles for a moment, but if one of the invisible bullets hits a wall and stops, the dust effects couldn't end up on the other side of the wall. This also nicely solves the collision as well by just using the standard bullet physics used by other shot types.
   
4. Another solution I've considered is making the artist just make multiple shotgun blast sprites, each of a different length - one that's 1 tile long, one that's 2 tiles long, one that's 3 tiles long, etc. Then I pick which sprite animation to use based on how much distance there is between the gun and the closest wall. The effect would still be partially clipped by the wall (the walls would draw on top of the effect) but it wouldn't ever be a large enough graphic to punch through to the other side of a wall. One issue I had with this idea is that shooting near corners along the edges of the wall might look odd if the algorithm selects the shorter effect even though it seems like some of the pellets could have made it past the corner.
   
5. Similar to above, I could just manually clip the single full-length shotgun blast effect via fancy code applying a clip rect when drawing the effect in the cases where it would end up poking out the other side of a wall, alongside the code that figures out to ignore enemies hit by the collision rect that are on the other side of the wall. This would be one of the more difficult solutions on the code side but would then not require anything fancy on the artwork side (would just draw a single effect for each cardinal direction of the appropriate size). Still not totally sure how it would work out for shooting at a corner though...
   
6. I thought I saw a game once that had a small blast coming from the barrel of the gun and then a separate dust/smoke puff at the eventually final position of the shot, but nothing in between, even if the end position was in mid-air instead of an obstacle/enemy. I'm not sure this really makes sense but it would at least show the range of the shot and solve the wall problem without just being a 3-way split-shot gun.

I welcome any thoughts, questions, or advice on this. Even better, if you can point me at a sprite-based game (even if its a different perspective) that had a decent-looking shotgun blast effect to indicate range to the player that also made sense when shooting at close-by walls, that I can use as reference for the artist, that would really help! Thanks!

 

[Jobbs]

Hey, anyone here interested in helping me figure out a good way to implement a shotgun blast effect in my upcoming game, Eternal Helix? The game will be in an overhead perspective.

I think the most authentic and best way to do it is to simply spawn a bunch of bullets. This is what I did. I also made it so the individual shotgun bullets damage amount and crit chance decreases the further they travel. End result is a devastating point blank weapon, but a weak ranged weapon.

If you don't like how it looks, make the bullets invisible and move very quickly (whatever it tkaes to match the rest of your game's asthetic) and cover it up with whatever graphic or graphics you want.

 

[More_Badass]

Hey, anyone here interested in helping me figure out a good way to implement a shotgun blast effect in my upcoming game, Eternal Helix? The game will be in an overhead perspective.

I'm just hanging out here, not a dev, so I can't answer your question, but I just had to say it's awesome that one of the devs of Volgarr is on GAF! Looking forward to Eternal Helix, will it be as punishing as your last game?

 

[V_Arnold]

Rubikant, here is what I would do in your case!

a. First, I would determine the visibility box of the shotgun blast. To do this, I need these information:
- Position of the character
- Distance between character and the wall
- The image (spritesheet-right?) dimensions.

b. Based on this, I would calculate how much of the shotgun blast is going to be needed to drawn. Or, if we are going to be fancy, it would determine how much *distance* will the shotgun blast have "available" to it.

So from this point forward, you can do two things with it:
- Shorten the hitbox of your attack
- Shorten the displayed effect (OR scale the effect to be visible on a distance less than initially planned).

If you go for a rough solution, you can say that if you shoot, and you can determine that there is an obstacle within your target and your hitbox, then you will miss/deal no damage. If you go for an elegant solution, you incorporate hitboxes with every single bullet check, and make the hitbox suspectible to such obstacles.*

*Or alternatively, do not even calculate it based on bullets+obstacles, but simply have a "line of sight" check only being updated when you or your enemies move

I hope this mess helps you in any way

(Edit: Jobbs's idea is great as well! If you simply spawn some smoke at your gun and spawn a bunch of bullets, then it will be up to your collision engine to let the bullets only travel towards the wall and end their journey there.)

 

[Rubikant]

Keep in mind I'm not really too concerned with the collision, its more the visuals I'm concerned about. How to make it LOOK like a shotgun blast and yet look correct when shooting at a wall or a corner as well. While it would be convenient if the collision and visual solutions were the same or related, I'm not concerned with how to do the collision checks accurately.

I know the graphic I displayed just had collision showing, but that's just because I haven't made the artist do an effect yet because I'm not yet sure how it should be set up visually.

Anyway thanks for the thoughts thus far! I didn't really consider just having literally a bunch of visible pellets. Given that at the base resolution each pixel is the size of a fist though (the GIF's I posted are at x4 scale), those would be some pretty large shotgun pellets...

I'm just hanging out here, not a dev, so I can't answer your question, but I just had to say it's awesome that one of the devs of Volgarr is on GAF! Looking forward to Eternal Helix, will it be as punishing as our last game?

Actually both of us are on GAF (and CVS is only a 2-man studio). I can't say for sure how hard people will find it compared to Volgarr since its such a different style of game, some may find it harder, some easier, but Eternal Helix will definitely not be an easy pushover game, I can promise you that.

 

[Ashodin]

I think the most authentic and best way to do it is to simply spawn a bunch of bullets. This is what I did. I also made it so the individual shotgun bullets damage amount and crit chance decreases the further they travel. End result is a devastating point blank weapon, but a weak ranged weapon.

If you don't like how it looks, make the bullets invisible and move very quickly (whatever it tkaes to match the rest of your game's asthetic) and cover it up with whatever graphic or graphics you want.

Yep just go for a small blast of bullet sprites, and have them collide with the wall and destroy on impact.

 

[Rubikant]

Yep just go for a small blast of bullet sprites, and have them collide with the wall and destroy on impact.

Well again considering just the visuals here, my concern with that solution is that the pellets would be too big given the resolution the game is at and the size of the other sprites. The main character is only 13 pixels tall, so those would be some massive pellets and having a lot of them might just look like a solid clump of color.

But making the pellets invisible and "covering it up with whatever graphic you want" just leads back to the primary problem - if I have a single graphic covering the range of the shotgun, what happens when the pellets don't make it very far due to a wall being in the way? I can't just slap a single graphic over top of all the pellets because that graphic might be large enough to poke through to the other side of a wall. That's why I considered possibly having the invisible pellets spawn smoke/dust effects as they travel until they hit something, but I'm not sure if that would look sensible (can't think of an example of a game that did that for a reference).

 

[Jobbs]

Well again considering just the visuals here, my concern with that solution is that the pellets would be too big given the resolution the game is at and the size of the other sprites. The main character is only 13 pixels tall, so those would be some massive pellets and having a lot of them might just look like a solid clump of color.

But making the pellets invisible and "covering it up with whatever graphic you want" just leads back to the primary problem - if I have a single graphic covering the range of the shotgun, what happens when the pellets don't make it very far due to a wall being in the way? I can't just slap a single graphic over top of all the pellets because that graphic might be large enough to poke through to the other side of a wall. That's why I considered possibly having the invisible pellets spawn smoke/dust effects as they travel until they hit something, but I'm not sure if that would look sensible (can't think of an example of a game that did that for a reference).

what about a few different "blast" graphics with the appropriate one playing if you are close to a wall, to give the illusion that you're blasting into a wall at point blank?

 

[Rubikant]

what about a few different "blast" graphics with the appropriate one playing if you are close to a wall, to give the illusion that you're blasting into a wall at point blank?

That sounds like what I was saying as possible solution #4 in my original post. The potential pitfalls with that solution is 1) more work for the artist and 2) not sure about the case of shooting at the corner of a wall, where theoretically, say, half the pellets would logically hit the wall but the other half would continue past the wall around the corner - do I go for the full-size graphic or the shorter wall-hitting graphic at that point?

EDIT: To better demonstrate what I mean by the corner problem, if I use the "blast" graphic desired for when you are close to a wall when shooting at a corner, I get this (remember think of the green box as a representation of the graphic sprite rather than collision):

but if I use the full graphic whenever at a corner instead, I get this:

 

[justjustin]

Maybe use this as reference: http://spritedatabase.net/files/neogeo/834/Sprite/Shotgun.gif

But instead of hand-drawing every possible shotgun blast, have the artist draw a small fireball that turns into a puff of smoke and dissipates. Then, have the shotgun shoot out a cone of these overlapping fireballs/smoke that only travel as far as a wall or as far as the collision box. Maybe you have some way to scale and rotate sprites, and a way to control which frames pop up first for variation. Pellets would be to hard to represent at that size, so go with flashy fire and smoke-- maybe tiny pixels to represent fragments. You could give the fireball sprites single pixel hitboxes so they done't get stuck/disappear on corners as easily.

edit: Another good reference: http://www.sprites-inc.co.uk/files/X/X4/Misc/Effects/X4Explosion.gif

An explosion from Megaman X4. The artist drew an animated puff of smoke and then strung a bunch together using varying frames rather than drawing each entire frame from scratch. The animation plays very quickly so no one notices the repetition.

 

[Blizzard]

Maybe use this as reference: http://spritedatabase.net/files/neogeo/834/Sprite/Shotgun.gif

But instead of hand-drawing every possible shotgun blast, have the artist draw a small fireball that turns into a puff of smoke and dissipates. Then, have the shotgun shoot out a cone of these overlapping fireballs/smoke that only travel as far as a wall or as far as the collision box. Maybe you have some way to scale and rotate sprites, and a way to control which frames pop up first for variation. Pellets would be to hard to represent at that size, so go with flashy fire and smoke-- maybe tiny pixels to represent fragments.

edit: Another good reference: http://www.sprites-inc.co.uk/files/X/X4/Misc/Effects/X4Explosion.gif

An explosion from Megaman X4. The artist drew an animated puff of smoke and then strung a bunch together using varying frames rather than drawing each entire frame from scratch. The animation plays very quickly so no one notices the repetition.

I don't know whether it would be feasible in the engine, but it might be possible to do some sort of render clipping if a shotgun is fired at a corner, so that only part of the sprite gets drawn past the corner.

Tiny individual pellets seem like the more guaranteed approach, as long as there's no significant performance impact and one is sure high-speed sprites will not clip through thin walls when doing collision checking.

 

[Rubikant]

Maybe use this as reference: http://spritedatabase.net/files/neogeo/834/Sprite/Shotgun.gif

But instead of hand-drawing every possible shotgun blast, have the artist draw a small fireball that turns into a puff of smoke and dissipates. Then, have the shotgun shoot out a cone of these overlapping fireballs/smoke that only travel as far as a wall or as far as the collision box. Maybe you have some way to scale and rotate sprites, and a way to control which frames pop up first for variation. Pellets would be to hard to represent at that size, so go with flashy fire and smoke-- maybe tiny pixels to represent fragments.

edit: Another good reference: http://www.sprites-inc.co.uk/files/X/X4/Misc/Effects/X4Explosion.gif

An explosion from Megaman X4. The artist drew an animated puff of smoke and then strung a bunch together using varying frames rather than drawing each entire frame from scratch. The animation plays very quickly so no one notices the repetition.

Yeah that's kinda what I was thinking of for solution #3 in my original post - having invisible objects move forward quickly spawning effects like these as they move forward. Thus if they can only move a short distance before they hit a wall, they just don't spawn as many of these fireball->smoke puffs as they would if they made it the full distance. I just wasn't sure if that would end up looking like overkill to have all those smoke puffs overlapping just for a shotgun blast.

I don't know whether it would be feasible in the engine, but it might be possible to do some sort of render clipping if a shotgun is fired at a corner, so that only part of the sprite gets drawn past the corner.

Its possible sure, I had the same thought for a moment, but then realized the artwork being "chopped off" like that on the portion past the wall might look bad and unnatural. As a quick example:

 

[Ashodin]

You can't make it like this?

Or does the bullets being too big bother you?

 

[DarkSiegmeyer]

Totally forgot the Blood Alloy dev was a Gaffer, been following your progress in the Reddit Screenshot Saturday threads. Game is looking great, really like the new animations

Are you the Superhot dev??? GASP FAWN SWOON

 

[Rubikant]

You can't make it like this?

Or does the bullets being too big bother you?

Right, well, that seems to be one of the foremost suggestions I'm seeing so far (just drawing a bunch of individual pellets). I was only pointing out the corner problem for the idea of having a single graphic overlay. With individual pellets corners clearly wouldn't be an issue, the issue there is just if the pellets would look okay at this level of graphic fidelity.

With this answer the question is if it will it bother the artist to have pellets of that size, since he'll take all the blame for anything that looks bad .

I think the best answers I've seen so far are to do it this way, or to do the "smoke puffs spawned by invisible bullets" solution (solution #3 on original post) and make it look like in Metal Slug.

Does anyone have any thoughts on solutions #2 and #6 from my original post? Are those just too crazy?

 

[Five]

I'm not sure how well it'd fit your art style, but I like the idea of seeing the bullets that hit the wall ricochet back slightly, not just stop.

As for the corner problem, what I would do is have a top and bottom hitbox instead of just the one, and then truncate either of the hitboxes if they're more than half occluded.

 

[Rubikant]

I'm not sure how well it'd fit your art style, but I like the idea of seeing the bullets that hit the wall ricochet back slightly, not just stop.

As for the corner problem, what I would do is have a top and bottom hitbox instead of just the one, and then truncate either of the hitboxes if they're more than half occluded.

Good point on the ricochet idea, if I go that route I'll try that .

I'm not concerned with collision here, just visuals, so while your second point would be a fine solution for collisions, I'm not sure if that would solve the graphic issue. Its starting to seem there's no elegant solution to having a single graphic representing the shotgun blast that would look fine in all situations, it would appear that individual pellets or smoke puff trail effects are the best answer unless there's some other solution no one has brought up yet.

 

[Five]

Good point on the ricochet idea, if I go that route I'll try that .

I'm not concerned with collision here, just visuals, so while your second point would be a fine solution for collisions, I'm not sure if that would solve the graphic issue. Its starting to seem there's no elegant solution to having a single graphic representing the shotgun blast that would look fine in all situations, it would appear that individual pellets or smoke puff trail effects are the best answer unless there's some other solution no one has brought up yet.

Maybe reverse-engineer a 2D lighting engine with penumbra support and use that as an alpha mask for your explosion sprite?

Yeah, I have nothing.

 

[Jobbs]

this is a clip of the enemy above that I posted on twitter.

http://gfycat.com/ValuableGiantArmadillo

this clip demonstrates my own enjoyment of fast moving enemy bullets. slow moving enemy bullets look silly.

in case you're wondering, there is counter play to this, once you see him in context, there is a method to fighting him.

 

[klaus]

Good point on the ricochet idea, if I go that route I'll try that .

I'm not concerned with collision here, just visuals, so while your second point would be a fine solution for collisions, I'm not sure if that would solve the graphic issue. Its starting to seem there's no elegant solution to having a single graphic representing the shotgun blast that would look fine in all situations, it would appear that individual pellets or smoke puff trail effects are the best answer unless there's some other solution no one has brought up yet.

I'd suggest combining 4 different effects, which combined should make for a nice Shotgun effect, that also works at corners / walls and that shows the range of the gun:

1) Character animation showing recoil (very important for making the gun feel powerful)
2) Short distance smoke effect (no need to clip to walls)
3) Short distance muzzle flash (dito with clipping, could ofc be in the same sprite / animation as the smoke effect)
4) Spawn a bunch of fast bullets, that ricochet off the wall & disappear after a certain distance

Making the bullets a few pixels long & somewhat transparent would simulate motion blur & keep them graphically unobtrusive..

For a reference what a real shotgun blast looks like, see here. Basically you just see smoke & the recoil, but adding bullets & a muzzle flash might improve the "feel".

 

[Turfster]

So, ran into a new "WTF Unity?!" today and was wondering if anyone else had run into this.

GameObject with a MeshFilter & MeshRenderer attached, mesh only contains vertices and colors (And a vertex color only shader). Updating the vertex colors works, until the MeshRenderer or GameObject has been disabled once. Then it just stays stuck on the last color before disabling, even though I'm still pumping new data to the mesh.

I really hope there's either something I've overlooked, or a simple solution for this, because the only one I currently have is to set transparency to 0 on "hide", which... is not a good idea. (I guess I could technically also just reset the vertex array to Vector3.zero on hide and rebuild it on show, but it's still a fugly kludge where there really shouldn't have to be one)

 

[klaus]

So, ran into a new "WTF Unity?!" today and was wondering if anyone else had run into this.

GameObject with a MeshFilter & MeshRenderer attached, mesh only contains vertices and colors (And a vertex color only shader). Updating the vertex colors works, until the MeshRenderer or GameObject has been disabled once. Then it just stays stuck on the last color before disabling, even though I'm still pumping new data to the mesh.

I really hope there's either something I've overlooked, or a simple solution for this, because the only one I currently have is to set transparency to 0 on "hide", which... is not a good idea. (I guess I could technically also just reset the vertex array to Vector3.zero on hide and rebuild it on show, but it's still a fugly kludge where there really shouldn't have to be one)

Strange, can you give more details on how you implemented the color change, ideally some code? Also, are you using point meshtopology?

For a quick fix, you could simply set the mesh in the meshfilter to null, and reassign your mesh when it should be visible again - that should be performance friendly, even if it's a hack.

 

[Turfster]

Strange, can you give more details on how you implemented the color change, ideally some code?

Simple mesh.colors=colors; every time the colors array has been updated.
Like I said, it works fine as long as the object doesn't get disabled. I'm using it to display weapon ranges for selected turrets with a simple transparent circular triangle fan mesh, but the "in range" color changes only happen if I leave them all "active" all the time.
With my default "enable on select" and "disable when no longer selected", the colors basically never get updated once they've been disabled once.

I can still edit the mesh.vertices array without problems and adjust my mesh however I want, but colors are "stuck" at the last point before disabling, even thought the mesh.colors array returns the exact same values as the local updated copy.


Edit: Okay, this only happens on my colleague's system, with exactly the same code revision.
What the hell? It's gotta be something with his damned FirePro...
False alarm, everyone! It's because my colleague just had to run a workstation =p
(This is what I get for not checking something on multiple systems... and forgetting that I'd done a full useability check on my own system when I wrote that code a month ago)

 

[kennah]

What's my best bet for coding a side scroller on a Mac with minimal code experience? Or should I just install Game Maker on a VM?

 

[lashman]

just testing some stuff out in Unity ... it's pretty meh (definitely much worse compared to what you guys have been posting here lately), but I might as well post it just don't be TOO harsh

 

[Turfster]

What's my best bet for coding a side scroller on a Mac with minimal code experience? Or should I just install Game Maker on a VM?

Have you tried Unity? There's a native version.

just testing some stuff out in Unity ... it's pretty meh (definitely much worse compared to what you guys have been posting here lately), but I might as well post it just don't be TOO harsh

Eh, like I said, I like it

 

[Five]

Jobbs, I'm sorry I doubted you. Your effects look amazing!

Kennah, give Unity a try. If it's too much for you, go with GM on VM.

lashman, it looks good!

 

[Noogy]

It's amazing how much switching to a new programming language/platform can screw with your productivity. I figured I had mastered using rendertargets and shaders with XNA, and am literally starting at square one with Unity. I wonder if I'm just overthinking how this works.

 

[kennah]

Thanks, I'll give unity a shot!

 

[lashman]

Eh, like I said, I like it

no, you only said it's shiny hehe

lashman, it looks good!

well, if you say so thanks then

 

[Blizzard]

I am still slowly making progress on the systems needed to make the game actually playable. Attack selection works, moved units now become grayed and inactive, the beam unit cannot move and attack in the same turn, and the player can only spawn and/or command units that match the player's color.

The GUI should be considered super placeholder since ideally, instead of a dialog box, I probably want some minimal set of icons for attack/stop/cancel (and other special commands some units may have).

Here is a GIF of moving some units around. It's 1MB so I figured I would link it: http://abload.de/img/unit_commandseljqm.gif Moving and attacking animations have not yet been merged into the state machine stuff.

 

[Jobbs]

It looks really cool. Such great art direction. keep it up.

whoa caught me off guard, looks slick!

thanks guys, appreciate it.

Jobbs, I'm sorry I doubted you. Your effects look amazing!

I wasn't aware you doubted me, but I'll take the compliment. thanks.

incidentally, that's probably nearly as large as I'll be doing an enemy the conventional way. (it's hard to see in that gif, but when he stands upright he's pretty friggin huge) much larger and that spritesheet starts to become mammoth. the truly big guys are probably gonna require some spine 2d action.

 

[TheHollowNight]

Time to reveal one of our enemy concepts!

In a few weeks on our devblog we're going to go into depth about the creation process for some of the character designs!

 

[OccamsBlender]

Aww shucks you guys, you are way too kind
Here's pretty much the finished tile piece.

I zoomed the camera right out to get a nice shot!
Tay our art director needs to make some stone step sprites, but he's currently concentrating on some enemy designs - which, you know, is far more rad.

I've also just joined up on TIGSource, so if any of you folks here are part of that community, come say hi!
TIGSource Devlog

Man. Lighting and fog really go far to help create a special atmosphere. Is this all tiles or are you using any new fangled modern stuff too?

 

[TheHollowNight]

Man. Lighting and fog really go far to help create a special atmosphere. Is this all tiles or are you using any new fangled modern stuff too?

it's all just 2D sprites! Some of the elements like the light bridges were made in 3D, then rendered out from an orthographic perspective into a 2D image to be used in game. We'll be adding dynamic particles and effects soon to give the game world more life, but currently it's not our main focus right now.

 

[Jobbs]

I've also just joined up on TIGSource, so if any of you folks here are part of that community, come say hi!
TIGSource Devlog

Looks great. I've had a tigsource account for ages, but never made a devlog for some reason. Wonder if that's a good idea.

 

[TheHollowNight]

Looks great. I've had a tigsource account for ages, but never made a devlog for some reason. Wonder if that's a good idea.

I'd probably say it's worth it. They're a pretty awesome community from my exposure to them so far.

Edit: I should stop replying so quickly haha

 

[missile]

Time to reveal one of our enemy concepts!

In a few weeks on our devblog we're going to go into depth about the creation process for some of the character designs!

The cursive font kills it.

 

[Turfster]

no, you only said it's shiny hehe

Shiny means good!

 

[cbox]

I'd probably say it's worth it. They're a pretty awesome community from my exposure to them so far.

Edit: I should stop replying so quickly haha

I just made an account there, just prepping an intro thread now.

 

[Five]

I wasn't aware you doubted me, but I'll take the compliment. thanks.

incidentally, that's probably nearly as large as I'll be doing an enemy the conventional way. (it's hard to see in that gif, but when he stands upright he's pretty friggin huge) much larger and that spritesheet starts to become mammoth. the truly big guys are probably gonna require some spine 2d action.

Just regarding CA.

Yeah, I was wondering about how big your sprites were. Castlevania had skeletal animations for a number of the larger enemies, and I think Super Metroid did for a few as well (although I'm not as versed in Metroid, admittedly).

Once you go Skeletal, it's hard to go back. Faster to put out animations, little overhead for adding in a a couple extra moves, dynamic adjustments; it's addictive.

 

[Jobbs]

Just regarding CA.

Yeah, I was wondering about how big your sprites were. Castlevania had skeletal animations for a number of the larger enemies, and I think Super Metroid did for a few as well (although I'm not as versed in Metroid, admittedly).

Once you go Skeletal, it's hard to go back. Faster to put out animations, little overhead for adding in a a couple extra moves, dynamic adjustments; it's addictive.

yeah, I was talking to one of the stencyl guys on the forums and I kinda went over my own personal feelings that spine 2d (or similar, but spine seems to be a great way to go) is sort of THE modern way of doing 2D games, and the way of the future, in advocating for really well implemented and fleshed out stencyl integration.

incidentally, here's another look at the enemy I was showing.

http://gfycat.com/WholeTautDinosaur

he stands upright sometimes. there are a couple more animations that I want(ed) to give him, but honestly the spritesheet growing and growing contributes to me wanting to cut some corners.

 

[lashman]

Shiny means good!

ahh, I see ... well that explains a lot then lol

 

[Five]

yeah, I was talking to one of the stencyl guys on the forums and I kinda went over my own personal feelings that spine 2d (or similar, but spine seems to be a great way to go) is sort of THE modern way of doing 2D games, and the way of the future, in advocating for really well implemented and fleshed out stencyl integration.

incidentally, here's another look at the enemy I was showing.

http://gfycat.com/WholeTautDinosaur

he stands upright sometimes. there are a couple more animations that I want(ed) to give him, but honestly the spritesheet growing and growing contributes to me wanting to cut some corners.

I agree. Rayman and Dragon's Crown make a particularly compelling case.

That monster design is really good. Keep it up.

 

[Skinpop]

I'm rolling my own engine for a small project and have some trouble implementing a fixed timestep independent variable FPS loop. http://gafferongames.com/game-physics/fix-your-timestep/

To make this work, as far as I understand I would have to store the previous state to properly interpolate during rendering. Is this as easy as just storing an extra last_transform for every renderable object? What about animation?

 

[razu]

I'm rolling my own engine for a small project and have some trouble implementing a fixed timestep independent variable FPS loop. http://gafferongames.com/game-physics/fix-your-timestep/

To make this work, as far as I understand I would have to store the previous state to properly interpolate during rendering. Is this as easy as just storing an extra last_transform for every renderable object? What about animation?

Yes, every 'animatable' value needs two keyframes. One in the past, one in the future. Each update you generate keyframes until the latest one is in the future. Then you interpolate to 'now' when you come to render.

 

[GulAtiCa]

2 weeks later and still feels weird that I actually created a game, ZaciSa's Last Stand, and published it on the Wii U. heh.

Currently spending last few weeks improving it. Most part it is improvements via feedback from reviews and miiverse comments. Miiverse as a developer is great. People seem to really enjoy it. Currently also spending time adding in new things, like 2 new maps and new bot abilities. Though some of that will take more time and will be in the 2nd patch.

Also, my ESRB rating got changed on me, that was pretty simple to fix though. (From E with no discriptors to E with "Mild Fantasy Violence")