If your whole game is built around your player character having Unity's physics where everything can impact it - yes. That's a difficult switch. Like others are saying, there are workarounds. We dropped Unity's physics and player controller in week 1 of our game during play testing. Its difficult to add and remove things from your game late in development like this which is why details at the start of development are key. There are a LOT of unknowns even if you have every last detail (or think you have every last detail in our case) that spring up and make you slam your face on the desk and sometimes there is no clean way of handling them. You just play test and make changes early and hope everything goes smooth and deal with unknowns as you cross them. We had a few pain in the ass moments like this so far. Sometimes its a clean fix, other times you look at your workarounds and shake your head and are glad nobody can see the bandaid you threw on something to get it done haha!Good luck with that
I put up with PhysX because, well, PhysX and I don't want to fall into the trap of rebuilding systems for everything from scratch again.
That's how most of my other projects died on the cutting room floor.
Edit: The fact that they added 2 totally different black box physics systems is still crazy, of course.
-
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.
Indie Game Development Discussion Thread | Of Being Professionally Poor
- Thread starter chubigans
- Start date
- Status
Thank you very much
. We're aiming for Oculus support for it as well, so hoepfully we'll get a little demo or trailer for that done soon too.
taku
Member
Aw man, it's not working for you guys? Weird, there shouldn't be any impossible gaps. Oh well, I guess I'll fix it later, and maybe make it a bit easier..
Edit: Made it easier, but now it's too easy. Oh well!
Yeah, I've had a gap at the top to a gap at the bottom immediately afterwards regularly, within the first few gaps.
In other news, Unity really needs a god damned break state option, though... or at least splitting the Editor into a separate thread, because this endless loop "kill the editor process and go find what happened in the log file" bullshit is getting tiring.
First try, 2 mm gap that went up half a screen. Sorry
Also, someone else say something!
AxiomVerge
Neo Member
Oh yeah! I used to love that game. Maybe the aesthetic seeped into my brain. Gonna check out some screenshots now for inspiration.
Edit: omg, look at this speed run:
https://www.youtube.com/watch?v=IJKUpHIQIGc&feature=youtube_gdata_player
I can't stop laughing. It's like in the 80s, it seemed completely plausible that you could take out the Soviet Union with just a knife... and this is exactly how it would play out.
taku
Member
HAHA! Um, it might be your cookies? Try in incognito mode!First try, 2 mm gap that went up half a screen. Sorry
Also, someone else say something!
That looks, plays, and sounds great man. I really like the weightiness of the controls. I managed to get 77!
TheHollowNight
Member
Looks lovely man. Also you get extra points of awesome for using some Erik Satie for the music
I've often wondered why people don't roll their own 2d 'physics' code. It's really not that difficult, and it'll just do what you want it to do.
taku
Member
Thanks, peeps!Looks lovely man. Also you get extra points of awesome for using some Erik Satie for the music
Kind of like me. "I'll just make my own engine." "This GUI framework is so limiting I'll just make my own."
Then you end up working on something like 5 years.
At any rate, physics, like custom GUIs or engines, can be very educational, but sometimes that education may be very painful.
BomberMouse
Member
Congrats Razu for making it to the indie royal bundle.
Hey, it involves programming!
No button, no buy! xD
For physics, I'm seriously considering doing my own system for my joint project, since it has lots of quirks that the regular 3D physics don't handle (even though the game has in 2D gameplay), but then again I'm not that experienced with coding decent physics systems in the first place. The only thing I ever did was a simple circle testing system in AS3 about four years ago, and a platform game system complete with tile graphics in AS3 as well (it lagged like hell because of how badly it was implemented, though).
I've also been seriously thinking about rolling my own input manager for Unity, since its generic Input axis system is really backwards (can't even change the key bindings in-game? really?). Would it be any good if I created a middleman class that uses the Input class to get commands, a way to change the key/button/axis bindings for each of them, and a callback system that other objects can listen to?
I've also been seriously thinking about rolling my own input manager for Unity, since its generic Input axis system is really backwards (can't even change the key bindings in-game? really?). Would it be any good if I created a middleman class that uses the Input class to get commands, a way to change the key/button/axis bindings for each of them, and a callback system that other objects can listen to?
bumpkin
Member
The hours (possibly days) I've wasted trying to get basic 2D collision detection working reliably says otherwise.
Of course with my luck, the problem(s) are timing or frame rate related. Either way, it still vexes me to this day; I gave up on trying to figure it out the last time.
AxiomVerge
Neo Member
I wrote my own 2D physics system a few times now . . . I have to say it's my least favorite part of programming (especially those bugs where some collision in the the innermost loop is off due to a bug in a collision check several iterations back . . . nightmares!)
For physics, it can vary depending on needs. For one of our games we have complete control over the player from any state he is in and can fine tune to our needs to really knock control out of the park.
For key input that is customizable in game - ignore unity's input manager altogether. Set constants in your player prefs ot wherever you like for buttons and change those via input by the user on the options screen. So say you have moveLeft set to "a" by default, when a user changes it have it replace the default value then simply call moveLeft in your Update.
Some folks even use simple .txt files like "options.config" to save all game options so they can be edited outside of the game, as well. There's a bunch of ways to handle it but you are correct, Unity's input manager is... Ehhhh.... Ehhhh... Lacking. It would be nice if they included language to let us overwrite it at runtime to make it easier to change settings.
I love Unity but sometimes I tilt my head to the side and "huh, really"
The guys I work with, Team Junkfish, did an announcement trailer for our survival horror game Monstrum yesterday.
Have a looky here and let us know what you think
Yeah man!! I'm playing Outlast right now. I will totally play your game!!
Which wasn't even a physical problem (it's a geometric one).The hours (possibly days) I've wasted trying to get basic 2D collision detection working reliably says otherwise.
Congrats Razu for making it to the indie royal bundle.
Thanks!
Might get some people actually playing the PC/Mac versions
Kind of like me. "I'll just make my own engine." "This GUI framework is so limiting I'll just make my own."
Then you end up working on something like 5 years.
At any rate, physics, like custom GUIs or engines, can be very educational, but sometimes that education may be very painful.
The hours (possibly days) I've wasted trying to get basic 2D collision detection working reliably says otherwise.
Of course with my luck, the problem(s) are timing or frame rate related. Either way, it still vexes me to this day; I gave up on trying to figure it out the last time.
You definitely need a game to drive the development of engine code, to limit your feature set.
I'd *guess* writing 2d physics from scratch would be quicker than getting a 3rd party system to do *exactly* what you want it to do. There'll always be exceptions, every game is different.
Ha. Well, we know you're on god tier coding, so your 'programming' isn't the same as ours ;D
Just_myles
Member
Jack_AG said:
razu said:
Well honestly, because it as simple as a click. I think, it's what in Unity(?) a rigidbody, kinematic or something like that.
So from what I am gathering, is that if you set up your player to collide with objects that have tags (that you can set up in unity), and have your player react to the 'world' while not moving(meaning set limits to their movement?), you created a physics engine? I know I am over simplifying but, this is how I grasp things.
Thanks guys.
There are a lot of problems for which I'd have to step outside of basic Newtonian physics to solve, and without prebuilt physics engines I would be completely lost. :|The hours (possibly days) I've wasted trying to get basic 2D collision detection working reliably says otherwise.
Of course with my luck, the problem(s) are timing or frame rate related. Either way, it still vexes me to this day; I gave up on trying to figure it out the last time.
Perhaps the best advice in here!
I would say it like this; I'd *guess* writing 2d physics from scratch would be
quicker than understanding a 3rd party system up to the point to do *exactly*
what you want it to do. And, once understood, debugging the 3rd party system
begins plus writing posts in forums beggin for help while saying how bad the
system actually is! Don't get me wrong; There'll always be exceptions, every
game is different! xD
Hey, I just hit buttons like everybody does! Alas I like the keyboard buttons
much more. So what? xD
You nailed the sound that plays when you crash. I just want to crash again and again to hear it, so satisfying.
Actually I made a Flappy game too for the Flappy Jam, I called mine Flippy Star... also it doesn't have to much to do with Flappy Bird.
Mental Atrophy
Banned
Should remind you more of Ninja Gaiden 2.
Anyway, lately I've been using my free time to make a new engine in Python/Pygame for fun. Right now it's just a tile engine with sprite layers, a GUI module for windows/buttons/scrollbars/etc, an entity class, and other basic stuff. I also rewrote my graph class, and by extension my pathfinding technique.
Entity scripting is done via Tiled map editor just using object properties to setup what the entities will need. For example, the above image's entity looks like this in Tiled:
Such that its entity.clicked() method looks into its "talk" field. Such that its behavior loop just pathfinds to a random location within ten nodes.
Motion is vector-based, so entities have a velocity (magnitude) and angle, with corresponding xvel and yvel components. Point-and-click controls only so far, such that right-click pathfinds to that pixel coordinate, while holding the mouse button moves the player towards that vector.
My pathfinding scheme is done in phases. It's A*, but I've separated out the while loop into its own evaluate() method, which searches once. There's a total number of evaluation() method calls that can be done per scene.update(), as configured in the game settings. Then, when an entity's PathFind behavior updates, it calls that evaluate() method by the maximum number of evaluations allowed per scene.update(), divided by the number of entities with a PathFind behavior currently updating. Once the path returns True, having found the solution, a new graph is generated from the results, with all adjacent nodes being connected. At which point, any graph node that is within line-of-sight but not parallel (occupying the same row or column) is connected. Then I A* that new graph. Almost every time, it produces a path where the entity takes the most direct path, at any angle. The heuristic is imperfect though, so on occasion it 90-degree turns when I don't want them, usually when there are multiple chokepoints it needs to guide itself through, putting enough nodes between it and its destination that it prefers the 90-degree turn... but this is pretty rare and minor. After this solution is found, it returns the list of nodes to the PathFind object, which then produces corresponding Move behaviors for the entity. Does that make sense?
Thanks!
Might get some people actually playing the PC/Mac versions
Congrats, man.
Hope this boosts the greenlight so you'll be rolling in that Steam money pile soon
bumpkin
Member
Hmm... So something that has been vexing me is the concept of regulating frame rate so that things behave consistently across different tech specs. Most of the scenarios I've heard revolve around padding a delta time to things like movement. This works fine when coordinates are floats. Not so much when they're integers. The thing is, I want to use integers.
I've been having trouble wrapping my head around a lot of the tutorials I found around frame rate regulation. Can anyone provide a really dumbed-down example?
For the sake of context, let's say my engine has an update function and a render function. Should both be affected by it?
I've been having trouble wrapping my head around a lot of the tutorials I found around frame rate regulation. Can anyone provide a really dumbed-down example?
For the sake of context, let's say my engine has an update function and a render function. Should both be affected by it?
Mental Atrophy
Banned
Just a general suggestion to update your data at a fixed time step and only use delta time for rendering. If your update method can't run at 60 Hz or whatever time step you're using, then you have a big problem. Also, store your coordinates as floats and then cast to integer when you need to. The only downside to using floats for coordinates is they become less accurate the larger they become, but that is a special case for huge worlds and even then that's a solvable problem.
Code:
step_size = 16
def execute_scene():
now = time.get_ticks()
while not done:
t = time.get_ticks()
while t - now >= step_size:
input()
scene.update()
now += step_size
scene.render()
display.flip()t is the amount of time that passes each time it loops. step_size is 16, such that input() and update() only execute every 16ms. If that takes longer than that, the loop will play catchup but this should never happen. It renders as fast as possible and then updates the display. Does this make some sense? This loop doesn't interpolate for rendering, so if you want frame times faster than your step size to matter, you need to pass the delta time to that method too. This isn't ideal, but this is probably the simplest example of separating your rendering and updating to help you get your head around the idea.
Proof of Concept 2 is finished. We are happy with it. Taking the weekend off, might finish my Castlevania Unity Engine this weekend (or just take a fucking break) and come Monday we start PoC 3. Then a few more months before we nail this 3rd down and we are off to the races. I'm super excited for this one because its a completely different direction than the first two and far more refreshing. We are digging deep with it and pulling out all the stops and calling in every damn favor we can to get the PoC up.
I've never built a procedural engine before so this will fun and/or/probably frustrating as hellDD Runtime bugs should be fun.
Sometimes I wish I would have just stuck with audio design and music but nooooooo, I decided to program instead XD
I've never built a procedural engine before so this will fun and/or/probably frustrating as hell
DD Runtime bugs should be fun.Sometimes I wish I would have just stuck with audio design and music but nooooooo, I decided to program instead XD
Yeah man!! I'm playing Outlast right now. I will totally play your game!!
Cheers
! I really need to play Outlast myself. Have it sitting on my PSN account (Thank you PS+~) but no PS4 to play it on ha ha. I know a few of the folk on the team've played through it though!RelentlessRolento
Member
hours lost suck good luck re-optimizing
Wooh! feels good to get a two player player working now with player 1 and player 2 being able to duke it out. Gotta head home to my lady for valentines but tomorrow I'll be making the basic versions of the three other character that all play differently. From there, all the menus and screens will be integrated and after that it's just making more art, polishing, adding sound and other things... should be good then.
Still mostly placeholders (and bad GIF framerate):
I'll need playtesting so don't be surprised if I ask help here for anyone who wants to do some input for me.
good luck re-optimizingWooh! feels good to get a two player player working now with player 1 and player 2 being able to duke it out. Gotta head home to my lady for valentines but tomorrow I'll be making the basic versions of the three other character that all play differently. From there, all the menus and screens will be integrated and after that it's just making more art, polishing, adding sound and other things... should be good then.
Still mostly placeholders (and bad GIF framerate):
I'll need playtesting so don't be surprised if I ask help here for anyone who wants to do some input for me.
Whitebison
Member
Hey guys, I've been the last couple of days looking up game engines and I can't decide which one will be best suited for a 2D pixel art Metroidvania....what do you think?
BomberMouse
Member
I'd vote Gamemaker for ease of use and decent support.
Btw; What's the game/concept your are talking about?
Construct 2 is certainly up to the job.
As long as you can keep your images small huhuhu or vector art
Whitebison
Member
Yep, Game Maker Studio and Construct2 are the best contenders...GM community looks great with tons of tutorials and examples...
Btw, I'm reading on the first post that C2 is buggy as hell :S
Btw, I'm reading on the first post that C2 is buggy as hell :S
I've been working with it for almost a year and I have yet to encounter any real gamedevelopment breaking bugs.
Congrats, man.
Hope this boosts the greenlight so you'll be rolling in that Steam money pile soon
Greenlight, ha! I don't think that'll ever take off.. Worthwhile lesson in not bothering with cross platform mobile-desktop. PC people like to feel special. Probably because they spent more on their GFX card than a console
Cheers
Yeah, PS+ has paid off for me already, (had to get for the company PS4, which Chopper Mike funded, thanks Mike!). Resogun and Outlast is worth the subscription alone for me.
I take it you've heard of Markiplier, the youtube dude? He plays a lot of horror games and apart from being hugely entertaining, does go into his personal opinions of what makes a great horror game. Well worth a watch!
I started making a torch-based maze game a few months back. It's funny how your own game can scare you!
I was confused on how passing parameters into RPCs worked. I wanted to pass my Array of enum variable Lists, but it wouldn't accept it. Had to bite the bullet and convert my data structure to a string. It doesn't actually work yet, but some of the data got through so I know I just have to fix the encoder/reader.
Other than that, network programming has been a magical experience.
EDIT: Got it.
Other than that, network programming has been a magical experience.
EDIT: Got it.
Huh? C2 can do high res stuff, and it doesn't even use real time vectors without a third party plugin. Otherwise vector art would have to be rasterized to use pixels anyway, so it doesn't matter if the images are pixel art, rendered 3d, vector or hand drawn, they're all just a grid of pixels.
There is the problem of it loading everything at the start of the game, though. I and others are hoping for C2 to allow more manual control of that later, but haven't gotten a response if it'll be implemented. However, I heard a while ago that game maker games can have long initial loading times too, though it was a while ago that I heard that, so I don't know if it is still true.
That post was made in 2012 and is seriously outdated. It now has the things that the review says it doesn't, like pathfinding, functions and tile maps, and is far more stable. I've had it crash on me I think once or twice in the past year. I think the post should be updated, and the reviews for other engines should be updated if they're outdated as well.
Good man, I support this quest 100%. I've always been a big opponent physics engines in general
If you're not doing angry birds or stupid Half Life 2 puzzles, you don't really need anything more than a basic collision system for the most part, which isn't that hard for 2D. All the other stuff in a physics engine just gets in the way and craps up the controls and the precision and limits your gameplay possibilities
Yes, writing an engine doesn't have to be a massive project if you know what you want to do. When I first started working on mine I probably spent less than a week before moving on to game code. Granted it's been a number of years since then, but I haven't really spent that much time on the engine in total and it's still pretty simple, and I've released games on 5 different platforms with it (and ported it to 2 more).
got a bit nostalgic and found this on youtube: http://www.youtube.com/watch?v=XkGem5Ab32Q. My engine was only a few months old here, and running what would eventually become Gunman Clive on Wii homebrew. Weird to think how far it's come since then
This is the big thing. You won't fully own the behaviour of your objects, which for arcade type games, is kinda important!
That said, for my game, Unity physics were great. No way I could have implemented that on my own.
Mystic River
Member
screenshot Saturday, still work in progress but testing fire inside space ships.
I've actually had time to work on Super Chopper Squad a little!
I tried out chamfered edges and painted metal shader. Happy!!
I tried out chamfered edges and painted metal shader. Happy!!
- Status