• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.
This looks awesome. Reminds me of PS2 style burnout ^_^

If Game development were a marriage, prototyping is certainly the honeymoon phase. I think polish, QA and release is the phase that leads to divorce and embitterment.

Thanks, ps2 style burnout is the aim :D

Mostly just working on getting the driving model right atm so all the other stuff is customised prebuilt assets from unity store, going well though

And yeah, always get hard and very bitter toward the end but I think once you release something it ends up being worth it
 

MagicD

Member
While I already voiced my support for your conclusion, I want to nitpick a little here. Going to school helps you write elegant algorithms. On the other hand, whether writing games is "about linear algebra" depends very much on what you do in games specifically. A graphics or physics programmer lives and breathes it, while some engine core programmer or tools programmer or game logic scripter might not end up using it much at all. Most of the theory is situational.

Yes, I agree with you that there are some programming positions that don't use linear algebra all that much day to day, but I'd follow that up saying that it's not going to hurt having that knowledge either. It's especially helpful to have a wide breath engineering experience to help you rise up the ranks to become Lead Programmer or CTO. Not having a solid math background will almost certainly cap your growth at some point.
 

MagicD

Member
How are people here dealing with localization?

I've found that with my current setup (Unity + free plugin SmartLocalization + free Microsoft Translator) is very easy to get an automatic translation and put a lot of language options but I will still need a human to check for errors and words too long for some UI elements.

For example, I have no idea if this is good russian or not:

RF4PSckl.png


There are places out there that specialize in game localization like this one: http://www.testroniclabs.com/games/qa-localization. You'll most likely have to talk with them to get prices for the languages you're interested in.
 

ant_

not characteristic of ants at all
So I downloaded Unity about 2 months ago and got heavy into the tutorials for about 2 weeks. Then it kinda dropped off.

I'm back on it, and going to finish off all of Unity's tutorials before I dive into my own project.

I have moderate programming experience and graduated with a degree in Physics / Astro last year and it took me this long to figure out that games are what I want to do. As a hobby right now is ok.

Mostly I want to build my portfolio so have more proof of my skillset. Hopefully I'll be in this thread a lot more
 
TLDR
Not saying I'm right - but decoupling an object that is controlled by peripheral input and moving it's vector through an animation (i'm assuming keyframed) sets off too many red flags.

Using animations (root motion) to drive character movement is a fairly standard practice in 3D games
 
Olympia Rising is finally headed to Steam for PC and Mac on July 23. My god it's taken so much longer than anticipated.

Feels good. It's awesome to have a game up there that I had a huge part of.

Congrats! That looks really good.

If I could make a small complaint, I don't think waiting almost a full minute into the trailer to show gameplay is a good idea. The storybook intro is classic, and definitely would be welcome in the game proper, but it's a bit much for people who aren't fully invested yet.
 

Jobbs

Banned
Olympia Rising is finally headed to Steam for PC and Mac on July 23. My god it's taken so much longer than anticipated.

Feels good. It's awesome to have a game up there that I had a huge part of.

Nice. Must feel good. Congratulations! I agree with LTP that you need to put gameplay near the start, people who click around and watch these things tend to get bored and leave very quickly. They may not think/care to skip ahead or wait around. I give the same advice to Kickstarter projects.

Awesome - Congrats!

We're also headed to Steam for Early Access starting July 9th

Nice! I have one too! Apparently it's coming this Fall. God I hope that happens. XD Timelines, timelines...

Into The Stars looks gorgeous, by the way, jeez.
 
Using animations (root motion) to drive character movement is a fairly standard practice in 3D games
That seems awkward, to me, at least. I suppose if you can tweak the animation every frame if needed it wouldnt be as bad. I'm too used to just coding everything. I use animations a plenty but never for motion so yeah. There's a lot that seems alien in gamedev when I move away from programming, not that I don't understand the tools, I feel I am more efficient with text than anything else. If it can be done with code and fits my performance budget I do it in code. Faster, for me anyway.
 
Hm. Given that you move on a "2D" plane, you don't use controller yaw, do you?

So our character can move along the X axis (forward and back) and the Y axis (towards and away), our camera is just fixed; movement is similar to the old school Ninja Turtles arcade game.

We have a character blueprint setup and we are not doing anything other than checking "orientate rotation to movement" on the character movement component. (everything so far has been done via blueprints)
 

Turfster

Member
We have a character blueprint setup and we are not doing anything other than checking "orientate rotation to movement" on the character movement component. (everything so far has been done via blueprints)
Yeah, that overrides UseControllerDesiredRotation.
I poked the answerhub and unreal's twitter and I'm going to let it lie for now.
Wasted enough time on it already.
 
That seems awkward, to me, at least. I suppose if you can tweak the animation every frame if needed it wouldnt be as bad. I'm too used to just coding everything. I use animations a plenty but never for motion so yeah. There's a lot that seems alien in gamedev when I move away from programming, not that I don't understand the tools, I feel I am more efficient with text than anything else. If it can be done with code and fits my performance budget I do it in code. Faster, for me anyway.

Typically root motion isn't used to actually drive the movement of the character. For example, you wouldn't use it for walking or running (but I guess you could). Instead, it's great for transition animations (turn arounds, run stops, etc), attacks that move that character (or stop all controller input), climbing, getting up, or anything else where you want to move the character + update its world location and not have controller input affect the character's movement.
 

Jintor

Member
it took about two hours but I think I might have successfully transitioned the basics of my bare bones platformer into a state system. Hopefully this will mean my increasingly unwieldy code is easier for me to understand.
 
it took about two hours but I think I might have successfully transitioned the basics of my bare bones platformer into a state system. Hopefully this will mean my increasingly unwieldy code is easier for me to understand.

Nice! As a matter of curiosity, where are you using your states?

Right now the PC in our game has seven different states, but the main state is 495 lines of code and each of the others are 20–50, or nothing at all and just waiting for an animation to finish. The secondary states handle hitstun, being dead, and hanging onto ledges, monkeybars and the like.
 

Jobbs

Banned
Nice! As a matter of curiosity, where are you using your states?

Right now the PC in our game has seven different states, but the main state is 495 lines of code and each of the others are 20–50, or nothing at all and just waiting for an animation to finish. The secondary states handle hitstun, being dead, and hanging onto ledges, monkeybars and the like.

Sounds like you guys are more organized than I am. My PC does 8 million different things with separate animations depending on what direction she's facing or what way she's aiming and the amount of states is "clusterfuck". XD I'm not even sure what you mean by "states". I sorta just control everything by way of a million different variables.
 

Jintor

Member
Nice! As a matter of curiosity, where are you using your states?

Right now the PC in our game has seven different states, but the main state is 495 lines of code and each of the others are 20–50, or nothing at all and just waiting for an animation to finish. The secondary states handle hitstun, being dead, and hanging onto ledges, monkeybars and the like.

at the moment it's just three states, idle, walk and jump. I just needed to get proof of concept down to prove to myself I understood what I was actually doing. I think I get it... there was like a period of almost a full hour where I couldn't understand why my collision wasn't working and it was because I forgot that I changed my onGround variable name.
 
Sounds like you guys are more organized than I am. My PC does 8 million different things with separate animations depending on what direction she's facing or what way she's aiming and the amount of states is "clusterfuck". XD I'm not even sure what you mean by "states". I sorta just control everything by way of a million different variables.

I think we have a mix of both approaches. Basically, any time that normal gravity applies (including standing on the ground, since a platform may disappear or you might run off the edge) the PC is in the main state. We use other states for irregular movement, like scrambling across monkeybars or climbing up a ledge or similar.

Originally melee attacks were in a separate state, but then that meant either no attacking in the air, or gravity stops when you attack in the air (like DMC), or duping the collision code. So that's not in a separate state anymore, but instead managed by variables like isShielding, isCrouched, isAttacking, et cetera.

Ultimately, I think it comes down to what method has you copying less code. If you have to check onMonkeybars or onLedge before nearly every action, then it's probably best to handle those meta states in a wholly separate code block.

at the moment it's just three states, idle, walk and jump. I just needed to get proof of concept down to prove to myself I understood what I was actually doing. I think I get it... there was like a period of almost a full hour where I couldn't understand why my collision wasn't working and it was because I forgot that I changed my onGround variable name.

Interesting. All of those are in the same state for the game I'm working on. Why do you still need the onGround variable if you have entire separate states for being on the ground?
 

Jobbs

Banned
I think we have a mix of both approaches. Basically, any time that normal gravity applies (including standing on the ground, since a platform may disappear or you might run off the edge) the PC is in the main state. We use other states for irregular movement, like scrambling across monkeybars or climbing up a ledge or similar.

Originally melee attacks were in a separate state, but then that meant either no attacking in the air, or gravity stops when you attack in the air (like DMC), or duping the collision code. So that's not in a separate state anymore, but instead managed by variables like isShielding, isCrouched, isAttacking, et cetera.

Ultimately, I think it comes down to what method has you copying less code. If you have to check onMonkeybars or onLedge before nearly every action, then it's probably best to handle those meta states in a wholly separate code block.

Oh, okay, gotcha.

Incidentally, I saved myself some trouble by basically just having no code at all pertaining to the PC for anything cutscene related, including stuff like death animation. I just lock the PC in place and hide the sprite, and spawn whatever animation as a separate object.

-----

I've been looking at all this UE4 blueprint stuff -- on the UE4 channel -- and wow, it really makes a lot of sense to me. It looks totally approachable. I know I mentioned this here the other day, but, yeah, it really looks great. In many ways it reminds me of the sort of visual scripting I already do, just arranged a bit differently.
 
Oh, okay, gotcha.

Incidentally, I saved myself some trouble by basically just having no code at all pertaining to the PC for anything cutscene related, including stuff like death animation. I just lock the PC in place and hide the sprite, and spawn whatever animation as a separate object.

That's essentially a state machine right there, albeit with only two states. We do the same thing with the death animation, turn the player invisible and spawn a bunch of explosions and effects. It's easier than ensuring a proper hand-off of persistent data, or making sure nothing is relying on it to be there.

Speaking of which, having an exploding character was such a good call for us. Originally we had specialized death animations for each position and way you could die, but it was super gruesome and time consuming, so that got changed.
 

Jobbs

Banned
Sorry, feeling talky tonight. Third cup of coffee.

Death animation for me was so friggin tricky to figure out. Initially, as a placeholder in the original beta build way back, I just put a copy of the classic 8 bit mega man death. Humorously enough, some testers played the game and didn't recognize the reference, and just thought it was my idea. Many of them liked it.

When it came time to put a more final death animation in, so many of my cooler ideas kind of spoiled things a bit too much or made it a bit too overt the nature of the story and the character. You don't want to undermine your story with a death animation. That's a pickle.

So I said, okay, let's just make it simple. The player falls back and hits the ground. I drew all of those animation frames and coded it in, but it just lacked impact. It felt odd. It lacked drama.

At the time I had recently been playing The Last of Us. I liked the death animations, they were effective in conveying shock because you suddenly see something bad happening (like a clicker gnawing your neck or whatever) and we get some shocking sounds but basically doesn't linger, it just cuts out. You get some sudden horror, but before you have much time to dwell on it, it's over. I realized THAT is the way to do it.

So I have the character sort of float back as the screen shakes, purple energy exploding out of it, but the whole thing cuts to black before you get a lot of time to think about it.
 
Yeah, I don't mean to disparage cinematic deaths in cinematic games. They're right at home in The Last of Us, Dead Space, Tomb Raider et al. It's just not a good fit for our game.


I think there's 1.25 seconds in our game before it cuts to the respawn. Maybe it's only a second. Just long enough for you to get a look at where you were and what killed you, but short enough to not be frustrating or depressing.

Aesthetically, I suppose Mega Man is the progenitor for exploding PCs. But we're mostly drawing inspiration from Alice: Madness Returns. I really liked the idea of the player's world shattering, and plus it draws attention right to the point of impact to have a huge shatter effect on there.

 

Jobbs

Banned
Show that in motion.

BTW, Alice MR was the inspiration for me using multijump (several small air jumps instead of just one big air jump as seen in typical double jumps). I always loved the jump controls in Alice.
 

Jobbs

Banned
Oh, nice! BRB, uploading to YouTube for 1080p60 instead of GIF. Link when it finishes: http://youtu.be/G7_GXyzILzc

edit: mmkay, it's live

How eventful is death in this game?

Is it a roguelike whereby one death ends it all and that's that? Or is it more like Meatboy or (if I recall) Guacamelee where dying is constant and sends you back very little?

If it's a rapid, constant thing, where difficulty is high and the penalty of death is low, then I'd say it's okay. But I think it possibly lacks impact if death is more eventful than that.

edit: sorry back to back replies
 

Jintor

Member
Interesting. All of those are in the same state for the game I'm working on. Why do you still need the onGround variable if you have entire separate states for being on the ground?

Just to separate out how the gravity works if I'm grounded or not grounded (I stuck friction, accel and gravity into a seperate step event on the player_obj just because I want to make sure that stuff works consistently whatever state the player is in; I'll change it if need be). My grounded variable is also useful for detecting landing, at least at my current stage of skill level.

To be honest I haven't thought ahead for this too much because I'm kind of bad at logical thinking and theorycrafting if I can't poke at something to see how it works.

Anyway, in terms of a game I'd like to make, I've been toying around with the idea of a metroidvania/fighting/roguelike game where your lives are currency. But that's still probably many moons away.
 
How eventful is death in this game?

Is it a roguelike whereby one death ends it all and that's that? Or is it more like Meatboy or (if I recall) Guacamelee where dying is constant and sends you back very little?

If it's a rapid, constant thing, where difficulty is high and the penalty of death is low, then I'd say it's okay. But I think it possibly lacks impact if death is more eventful than that.

edit: sorry back to back replies

I don't know if there's a simple answer to that. If you have any candles left, you get placed back at the last safe location you were standing on. The little skull guy following you around is shorthand for this, as he lingers behind and doesn't enter dangerous areas with you (until you've cleared the enemies or passed through it) and embedded in his head are up to three of the candles you're holding (though you can hold more at a time). So the candles are somewhere between lives and HP since the PC is a one hitpoint wonder.

If you run out of candles and die, you'll be taken back to the last checkpoint you're at. I've circled the checkpoints on a given map in the image below. Most of the junk piles on the ground (pumpkins in the video) can be broken open for a few coins and a wax glob. Five wax globs can be melded together to make a new candle at any of the checkpoint locations. Also, there are a couple stores in the stage that sell enhancements and candles, and you usually find candles tucked away in chests if you're running low. Finally, in an idea stolen from Shovel Knight, you can smash apart the checkpoint altar to gain a couple extra candles, but at the cost of not being able to use that checkpoint for the rest of the run.

All this to say death can be pretty painful, but usually it just puts you back somewhere in the current room. The video I linked earlier shows a particularly mild setback, but sometimes it might be a long stretch of platforming and you get put back there. I think the trade-off is that while death is just a slap on the wrist the first few times, eventually it can be quite punishing, so you really don't want to die too much. Though I'd love to hear any of your thoughts.




Just to separate out how the gravity works if I'm grounded or not grounded (I stuck friction, accel and gravity into a seperate step event on the player_obj just because I want to make sure that stuff works consistently whatever state the player is in; I'll change it if need be). My grounded variable is also useful for detecting landing, at least at my current stage of skill level.

To be honest I haven't thought ahead for this too much because I'm kind of bad at logical thinking and theorycrafting if I can't poke at something to see how it works.

Anyway, in terms of a game I'd like to make, I've been toying around with the idea of a metroidvania/fighting/roguelike game where your lives are currency. But that's still probably many moons away.

Oh, okay. That makes more sense. It's not the way I'd do it but I don't think it's a bad approach either.

Yeah, there's definitely something intriguing about metroidvanias and roguelikes. I'm excited to watch your progress!
 
Yeah, I get what you're going for, I'm sure it's fine. You probably want a quick death.

DS4, nice :) Have PS4 plans?

The build quality on the DS4 isn't awesome, but the ergonomics are, so it's my PC controller most of the time.

Since GameMaker supports PS4 and XB1, they're both on the table, but we don't have any official plans yet. It'd be easy to say yes if it were as simple as pressing a button, but I don't know much about who to contact, whether we'll need to form a business entity, what the fees are, et cetera. So we're saving those discussions for later. AKA we should probably court a publisher who'll help us out.
 
Well, the translation process might have failed if you're doing quadriped stuff, it might not be possible. Go into the avatar and make sure all 20 nodes or whatever are "green"...

Yeah, it's not recognizing the legs, they're red. Looks like I'll have to get the animations mirrored in 3ds max somehow.
 

Jintor

Member
by the way, for pure prototyping, does it make sense just to work in this 640x380 box with a 32 x 32 avatar for now and just scale up if required?

I'm, like, really new to this all
 

Jobbs

Banned
The build quality on the DS4 isn't awesome, but the ergonomics are, so it's my PC controller most of the time.

Since GameMaker supports PS4 and XB1, they're both on the table, but we don't have any official plans yet. It'd be easy to say yes if it were as simple as pressing a button, but I don't know much about who to contact, whether we'll need to form a business entity, what the fees are, et cetera. So we're saving those discussions for later. AKA we should probably court a publisher who'll help us out.

There are different ways to go, a publisher is definitely one. I want to get Ghost Song onto console(s) but it's still pending technological concerns. There's what may be a solution in the works but it hasn't come to fruition as yet.

Best of luck :)

by the way, for pure prototyping, does it make sense just to work in this 640x380 box with a 32 x 32 avatar for now and just scale up if required?

I'm, like, really new to this all

Depends what you're prototyping. :) If you know what the game is you're making and have established the screen resolution it may be wise to work from that, but if you're just experimenting around I can't imagine why the dimensions matter that much.
 
There are different ways to go, a publisher is definitely one. I want to get Ghost Song onto console(s) but it's still pending technological concerns. There's what may be a solution in the works but it hasn't come to fruition as yet.

Best of luck :)

Thanks! Good luck to you too.


by the way, for pure prototyping, does it make sense just to work in this 640x380 box with a 32 x 32 avatar for now and just scale up if required?

I'm, like, really new to this all

Yes and no. In theory it's fine, but GameMaker doesn't always handle interpolation and scaling well. It's going to be a pain if you have to add some multiplier into every draw event later on, and the default collision handling can sometimes wig out with non-integer amounts. Mind you, I'm talking about HD art -- pixel art should be fine.
 

Jintor

Member
i'm guessing it'll be pixel because i like pixels but who knows?

just fooling around right now. know any good hitbox tutorials?
 
i'm guessing it'll be pixel because i like pixels but who knows?

just fooling around right now. know any good hitbox tutorials?

I don't, so my Google search is probably going to look the same as yours. But I can pull out the code we're using for hit/hurtboxes and run you through it if you like. PM if interested.
 

Jintor

Member
I don't, so my Google search is probably going to look the same as yours. But I can pull out the code we're using for hit/hurtboxes and run you through it if you like. PM if interested.

perhaps later - i'm gonna get my state machine platformer up to speed first. Cheers though!

indiegaf is goodgaf
 
Status
Not open for further replies.
Top Bottom