1 2
6 7 8 9
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
It's not really worth solving them yourself except as an exercise.
Well, for me this is a good exercise to see if I'm capable of realizing my plans. Google has been my only help and even so I'm making satisfying progress and I don't see unsolvable problems lying ahead yet. I have figured out how to implement a check that lets my character walk on slopes (I was really happy that I made it work) and I want to see if I can figure out how to implement some physics (speed, acceleration, velocity). In particular, I want to add a "ball" item which will bounce through the room. I will have to figure out how it behaves when it touches left slopes, right slopes, ceilings, grounds and walls so it's going to be interesting. I'm doing this to see if I can do this and for fun. And in future job interviews it will not hurt to be able to show a game I coded myself, a platform game, no less. I can see this project may end up taking a long time before it's near completion. I think once I finish coding some basic items and weapons, it's going to be all about designing the levels and the character sprite. I'm going to check out Unity later this week.
Publisher
Joined: 4/23/2009
Posts: 1283
OmnipotentEntity wrote:
If I had to do it all over again,...
Holy ****, when I saw your name on that site originally a year ago, I was thinking, nah, can't be the same person.... So much for that!
Joined: 7/2/2007
Posts: 3960
MUGG wrote:
It's not really worth solving them yourself except as an exercise.
Well, for me this is a good exercise to see if I'm capable of realizing my plans. Google has been my only help and even so I'm making satisfying progress and I don't see unsolvable problems lying ahead yet.
Hey, that's great, and I didn't mean to demean the "exercise" aspect of it. You absolutely will learn a lot in trying to implement your own engine. It's just a question of if you're more process-oriented (i.e. "I'm writing this game because I want to write a game") or goal-oriented ("I'm writing this game because I want to have a game"). A goal-oriented developer would be trying to avoid duplicate effort wherever reasonable, but that's much less critical for a process-oriented one. And I know lots of process-oriented developers (and was one myself for quite some time). There's a lot of satisfaction to be had in being able to point at something and say "I wrote all of that". It just takes a hell of a lot longer that way. Kind of like the difference between building a house solely with handtools and raw lumber vs. building it with power tools, prefabricated fittings, precisely-dimensioned lumber, etc.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Player (36)
Joined: 9/11/2004
Posts: 2623
Aktan wrote:
OmnipotentEntity wrote:
If I had to do it all over again,...
Holy ****, when I saw your name on that site originally a year ago, I was thinking, nah, can't be the same person.... So much for that!
Essentially, if it's OmnipotentEntity and it's on the Internet it's probably me <3 Thanks though. :)
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
I've found a rather serious glitch in my html5/javascript game. If the browser lags, variables seem to be updated not at the same time, or maybe some operations are skipped. This can cause my character to jump twice as high, for example. Maybe the "request animation frame" thing forces a framerate and if operations take too long it skips some? My question is how to prevent this? I can share my files via PM if someone wants to look at the source code to help me. I read that distributing html5 games as files is not good. There is no telling what the javascript in my files would do, theoretically it could collect whatever files it can find on the computer and send them to the internet or something.. So it was said that html5 games should be uploaded to a server and linked to. I think this should be easily possible later, right?
Joined: 5/13/2006
Posts: 283
In absence of a server of my own, I use dropbox for hosting html/javascript. They do have bandwidth limits though, if that's a concern.
<Zurreco> if so called professional players cant adapt to every playing field, theyre obviously not that great
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
I deleted the previous two posts that were about a problem I struggled with some weeks ago. I just came here to leave this link of my current progress. Please feel free to let me know what you think. Level design is not done (the level is basicly a debug level), menu is not done, many other things aren't done so keep that in mind. Use arrow keys to move and jump. http://mugg1991.altervista.org/v19/21.html
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
Here is the latest version of that one little incomplete html5 game I made. There is only one test room without anything to do but jump around. http://mugg1991.altervista.org/V28/28b.html <-- without debug info http://mugg1991.altervista.org/V28/28.html <-- with debug info I haven't worked on this since 2015 March or so and don't plan on continuing. But maybe I will redo this game someday, maybe in another language. Developing games gives me too much headaches and I'm not patient. I lack dedication, but maybe I will take another try at this later. One huge problem with the game I linked was that it had no plan. I just wrote code however I pleased so there is a lot of unfinished stuff everywhere in the code. Also the physics and mechanics are way too ambitious. It needs to be simpler and cleaner. I could probably do with half the amount of variables that I ended up using. Also, with one big room where the camera only focuses on a part of it, I would need to figure out how to deal with hitboxes/checkboxes. Because the way it has always been is that my code just checks each tile (slope, wall, lava, water) on the entire room instead of only those that are close to me. I think it could save performance if I figured out how to do it better. If I do figure it out, then maybe I could just do it like Terraria and not have multiple rooms, but just one huge room. About my game idea: It's like a huge maze. I think I'm really inspired by Terraria because in that game you can go on clouds, on the ground, across lakes, through caves, through hell, through ruins, etc. and I envision something similar for my game. But instead of the game being sandbox, it would be an adventure and puzzle type. You would find items and keys that you could use elsewhere on the map to progress and there would be multiple ways to progress. It wouldn't be clear which way was the fastest and I would have liked a time-attack mode where players try to go to the goal with the route they think is fastest. I'm not sure about the time-attack mode idea anymore, though - I don't really imagine it to be that fun. Also there would be a variety of enemies, sword swinging knights, goblins, but also high-tech things like robots that laser at you, etc.
Publisher
Joined: 4/23/2009
Posts: 1283
Too bad you don't have the motivation to continue. You same to have the basics down, with a good rewrite you could make your engine cleaner.
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
Here is another game idea I wanted to share. I specifically made a screen design for it: The objective would be to craft words by inserting new letters, swapping the existing letters, replacing the existing letters with new ones, or deleting existing letters. Finishing a level fast will earn more points. Not sure if this idea yields much playability and interest, but it's been floating in my mind for a while now. Not sure if I should script it quickly in emu-lua for the sake of it, or if I should get into javascript/Html5 again or maybe learn a new language (which I don't plan to do in the near future, but maybe later)... Any input on this game idea is welcome, including improvements to the screen design or the idea itself.
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
Ok so I have a question. I'm making a game in Bizhawk lua and it's going to be a grid-based system where map tiles are 0 or 1 (nothing or walls). The character has a hitbox of a given width and height. My collision check checks any map tile that the hitbox covers. My question is, how should I code the wall ejection? I've tried a few things but I can't seem to make it good. Any ideas?
Editor, Skilled player (1404)
Joined: 3/31/2010
Posts: 2086
MUGG wrote:
Ok so I have a question. I'm making a game in Bizhawk lua and it's going to be a grid-based system where map tiles are 0 or 1 (nothing or walls). The character has a hitbox of a given width and height. My collision check checks any map tile that the hitbox covers. My question is, how should I code the wall ejection? I've tried a few things but I can't seem to make it good. Any ideas? https://i.imgur.com/QxDkhiD.png
From what I know, you generally want to move the character in one axis first and check for collision along that axis, before looking at the other axis. If you move the character entirely first before checking for collision, you generally run into trouble. This means that when the character is moving right and up, you want to check what tiles the right and up edge of his hitbox overlap with. If you notice a collision, you can move the character to the edge of the previous tile. It's solid, but you'll get very harsh zipping if you do get the player embedded into the wall. There's probably better and smoother ways to do it. (oh, also, this does no motion interpolation between frames - if your character moves fast enough, there's nothing stopping you from clipping through. you can counteract this by making sure your character never moves more than a tile's width in one frame or on each frame, you make sure to check each tile between the character's base position and his destination)
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Collision detection can be surprisingly complicated, even in extremely simple scenarios (such as having all obstacles be axis-aligned squares in shape, and positioned in a regular grid, and even if the moving object is itself also an axis-aligned square or rectangle). One thing that makes it complicated is that in a computer program objects move, by necessity, in nonzero-sized steps. Thus if you were you just check for an overlap of the moving object with obstacles, the moving object may miss some of them (even though they should have collided if the object had moved contiguously). For example, if one corner of the moving object would have just barely touched a corner of the obstacle, it could easily skip over it, with this kind of overlap check. If you need an accurate collision detection, you need to actually calculate whether the entire polygon formed by moving the object over its path from its position in the previous frame to its position in the next frame, overlaps with an obstacle. The problems don't end there. Even if you do implement this, and get an accurate point of collision (and thus the distance that the object moves before it collides, ie. the exact sub-frame in which the collision happens), you then need to decide how the object should behave. Let's say that the object is moving diagonally, and let's mark the first frame as having a t=0 and the second frame as t=1, and the collision having been calculated to happen at t=0.32, where should the object end? If the object should just stop at the point of collision, then the answer is of course trivial: At the point of collision (duh). But what if you want it to eg. slide along the obstacle, when it collides with it, for instance? Or what if you want it to bounce, as if it had been a billiard ball hitting a wall? You would need to calculate its path from t=0.32 to t=1, taking into account the collision that happened at the former (and thus the new direction that the object takes). (A simplistic approach would be to simply stop the object at the collision point for the remaining of the frame, and then start moving it in the proper direction for the next frame. This is much easier to do, and might work with simpler simulations.) And heaven forbid you have several moving objects, colliding with each other. That's a huge, huge can of worms. So it's not an easy question in any way.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
That video reminded me that I forgot to mention in my previous post that even with one single moving object and a bunch of static obstacles, you can furthermore run into the problem of what happens if the moving object collides with more than one obstacle at the same time. This is especially problematic if you go the route of accurately calculating the new direction of movement based on the sub-frame time of collision, as I described. (In other words, if you calculate that at t=0.32 it collides with obstacle A and you proceed to calculate where it will move from there when t=1, you might find that it collides with another obstacle eg. at t=0.74. If you then proceed recursively from there you might find that it collides again before t=1, perhaps even with that first obstacle, and so on and so forth.) The moving object may even collide with two obstacles at the exact same time (eg. the inside of a corner). In a tight axis-aligned grid-based system of obstacles this might even become likely. So yeah, it's not a trivial thing. All physics engines need to deal with this, and it's not at all easy. (Especially in older ones you often encountered unrealistic behavior, like an object on the ground constantly moving back and forth, because the physics engine is unable to find the equilibrium point, as the object is constantly colliding with an uneven ground.)
Player (96)
Joined: 12/12/2013
Posts: 376
Location: Russia
Warp wrote:
So yeah, it's not a trivial thing. All physics engines need to deal with this, and it's not at all easy.
Nope. You can just forget about that perfectness and make something simple. For exampe: 1) Save unit position. 2) Move unit as if there is no collision. 3) Check, is he colliding to anything right now. 4) If he collides -> restore saved position, optionaly change its speed (for example to zero). 5) If he doesn't collide, you can now check all non-physic collision like: hitboxes, collection of items. etc. 6) Done. Also, this leaves nice window for TAS with zips :b
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Even if you don't care if the moving object may go through obstacles (because it makes too large of a jump from frame to frame), you still have the problem of what should be done when in the next frame the moving object is partially inside the obstacle. Where do you put it? If the moving object should never go inside obstacles, you still need to calculate the point of collision, even if roughly.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Easy: just make a game where everything is made out of clouds :D
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
Right now my code lets the character move and the collision check is supposed to adjust the character position. An idea, like r57shell suggested, could be to save the previous position and / or let the character only move if no collision was detected. I will have to test around with that. Otherwise it boils down to:
you still have the problem of what should be done when in the next frame the moving object is partially inside the obstacle
This. My image summarizes my results so far: https://i.imgur.com/sGDCx4h.png I wish there was a prettier solution because this what I'm showing off in the image would require taking into account which corner of the hitbox is in a wall, and that means writing code for all of these special cases. It's probably also not very nice on the performance. Thanks so far!
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
As said, it depends on how accurate you want the collision to look, and how you want the moving object to behave when it collides. The easiest situation is if the moving object simply stops moving when it collides with an obstacle. However, as a game mechanic this is usually also one of the worst possible solutions (with the possible exception of certain games). When the object just stops dead, it feels clunky to the player. Most often you would want the moving object to eg. slide alongside the obstacle, or possibly bounce from it. But even when it's enough for the object to just stop at the collision point, you need to calculate this point. You could try an iterative process, using what effectively amounts to a binary search (ie. see if the object at half-way between its previous position and its new position overlaps with any obstacle, and depending on whether it does or not, look at one quarter way to either direction, and so on, up until the desired accuracy). Or you could use an exact formula (which would require essentially calculating intersection points between lines and rectangles).
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
This is what I have right now. https://pastebin.com/jswhChWd https://paste.ofcode.org/DmXjDgGgE54YGxMrpaAuHz (Longer pastebin freezes my PC so I use different site) https://www.youtube.com/watch?v=P8EHWhcxYgc I ended up with a better collision check than before, but I'm wondering if it could be shortened and optimized further (see function named playerWallCollision).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
The moving object bouncing like that from the wall is one possible solution, but doesn't look&feel very good and polished. Just an opinion. But I understand perfectly why it's such a difficult problem, as I described in great length.
Player (96)
Joined: 12/12/2013
Posts: 376
Location: Russia
Can't tell for sure without digging into code, but from video looks like you understand my idea a bit wrong. Save, move, test collision, and restore - should take in single frame, so it will not glitchy bounce in/out. Next assumption: if you fall and collide -> you land on ground, thus you should push up. if you raise and collide -> you hit ceil with head, thus you should push down. if you move right and collide -> you zipping in wall by right side, you should push left. if you move left and collide -> you zipping in wall by left side, you should push right. Main point here: you don't actually check all facts from right side of sentences. You assuming this happens. Summarizing all of this, you'll get that push is always opposite to speed vector.
Editor, Expert player (2313)
Joined: 5/15/2007
Posts: 3855
Location: Germany
@r57shell Thanks, but I considered that your approach wasn't quite trouble-free. For example, when falling and entering a wall tile, restoring would mean lifting the character, wouldn't it? And:
if you fall and collide -> you land on ground, thus you should push up. (...)
This is not so simple. a) What if the upper half of the character touches a wall while falling? In that case, he should continue falling. b) What if the character falls alongside a wall and touches it? He is falling in a wall, so according to your rule, he needs to be pushed up. But that wouldn't make sense. When moving left and into a ceiling, you shouldn't be pushed to the right, either, contrary to what your rules suggest. Sorry but I was very quick to go right ahead what I envisioned. And it works nicely now. It's not impossible for me to fix the repeated bouncing, maybe I will look at it later (It's just a matter of ejecting character 1 pixel less).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
r57shell wrote:
Save, move, test collision, and restore - should take in single frame, so it will not glitchy bounce in/out.
If you simply test if the moving object would overlap with an obstacle in the next frame, and just keep the object in its current position, it will often stop before visually touching the wall. It will only work ok if in the current frame it's perfectly adjacent to the wall.
1 2
6 7 8 9