|
Pfhreak posted:Now I tend to start with small goals in mind -- get the player moving, get the camera panning, add an inventory, how about bad guys, etc. I tackle that one problem in code with little planning.
|
# ? Feb 17, 2012 17:35 |
|
|
# ? May 12, 2024 08:05 |
|
I'd also recommend prioritizing said feature list as well. I find that once I've already put something down as lower priority, it becomes a lot easier to decide I don't really need that feature when I'm behind schedule.
|
# ? Feb 17, 2012 17:45 |
|
Anybody here ever played around with the C4 3d engine? http://www.terathon.com/c4engine/index.php I like Unity but I feel with each new release they keep making the free version less and less appealing and the $1500 is not a price I'm really wanting to pay right now. UDK has some great features but I don't really care for the whole scripting aspect of it. I know it's possible to make a variety of games with it but the way it's put together makes it feel as if I'm still just making a complicated mod. Not to mention I'd like to play around with implementing some 3rd party libraries and that's not really possible with UDK. The C4 engine is $250 and it has some pretty impressive features, including a nice voxel terrain system. Not to mention the full source is included. Just curious to know if anybody has had any experience with it.
|
# ? Feb 18, 2012 00:42 |
|
I don't see a Minecraft-related development thread, so I figure I'll ask here just in case. Does anyone know the method by which Minecraft generates the initial player spawn based on the seed? All I can find from googling is a general "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" And that's all well and good except it's not random. If I start a world with a particular seed, open it up, check my spawn coords, then delete the world and re-create using the same seed, I get the same spawn point. So...does anyone know what method it's using to choose? Thanks in advance.
|
# ? Feb 18, 2012 01:05 |
|
In this context, "seed" is short for "random seed". The whole point of entering the seed is that exactly the same "random" numbers will come up when you use it.
|
# ? Feb 18, 2012 01:35 |
|
Zhentar posted:In this context, "seed" is short for "random seed". The whole point of entering the seed is that exactly the same "random" numbers will come up when you use it. Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is.
|
# ? Feb 18, 2012 01:37 |
|
HaB posted:Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is. It is as you described. Minecraft picks a random point within a few hundred blocks of (0,0) until it finds one that's an acceptable spawn location.
|
# ? Feb 18, 2012 01:41 |
|
HaB posted:So...does anyone know what method it's using to choose? Thanks in advance.
|
# ? Feb 18, 2012 01:45 |
|
ShoulderDaemon posted:It is as you described. Minecraft picks a random point within a few hundred blocks of (0,0) until it finds one that's an acceptable spawn location. If it's random, then it wouldn't be the same every time the same seed is used. That's what I'm saying. Here's a test to prove it: Load Minecraft. Create a New World, Select More World Options Enter 1 as the seed Create World when it loads, don't move and hit f3 to look at your coordinates. You are standing at: (251.5, 65.6, 232.5) If it's random, then how do I know where YOU are standing? It's based on the world seed. I'm trying to figure out HOW.
|
# ? Feb 18, 2012 01:48 |
|
There is a minecraft modding thread in Games which would probably be more able to answer your question.
|
# ? Feb 18, 2012 01:55 |
|
HaB posted:If it's random, then it wouldn't be the same every time the same seed is used. That's what I'm saying. Here's a test to prove it:
|
# ? Feb 18, 2012 01:56 |
|
HaB posted:If it's random, then it wouldn't be the same every time the same seed is used. Sure it would be. That's what random seeds are. If you use the same seed, you'll always get the same sequence of pseudorandom numbers. The seed you give to minecraft doesn't go into some fancy "world gen seed algorithm". It's just used to seed the standard random number generator, which is then used to build the world. Immediately after building the world, that same random number generator is used to pick the spawn point. There's nothing clever or unexpected going on. If you give a fixed seed to a random number generator, it will always produce the same sequence of numbers. Minecraft uses some of those numbers to generate the world, then it uses some of them to pick a spawn point. Because you provided a seed, you get repeatable results.
|
# ? Feb 18, 2012 01:56 |
|
Orzo posted:I'm not sure I follow. The algorithm which generates worlds is using a random number generator with a seed. The algorithm which places the player is using the same seed. So it appears 'random', although it is deterministic when you give it a certain seed. As for what the algorithm is, you'd need the source code. Jeez, guys. I know how pseudorandom number generators work! The same as they have worked since time immemorial. I bolded the ACTUAL answer above. But I know other people have already decompiled and deobfuscated the code, so I was just asking if anyone knew the algorithm offhand or could at least point me in a direction other than "this is how random number generators work." MonsterUnderYourBed posted:There is a minecraft modding thread in Games which would probably be more able to answer your question. Ah-ha! I only looked in Cavern of COBOL. Thanks.
|
# ? Feb 18, 2012 02:01 |
|
HaB posted:Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is. The "equation" is a psuedo random number generation algorithm. To determine the output of a specific call, you need to know not only the algorithm, but the position in the sequence. If the worldgen process always performs exactly the same number of random calls before that point, then you'd just need to figure that, say, the 127,403rd time random() gets called it's to pick the spawn point. However, I would assume that the worldgen process also involves testing and rejecting candidates, in which case the position would be variable. You'd likely have to perform most of the worldgen process to determine what the random value used to pick the spawn point is.
|
# ? Feb 18, 2012 02:03 |
|
e: derp.. Heh, random!
|
# ? Feb 18, 2012 02:06 |
|
Zhentar posted:The "equation" is a psuedo random number generation algorithm. To determine the output of a specific call, you need to know not only the algorithm, but the position in the sequence. If the worldgen process always performs exactly the same number of random calls before that point, then you'd just need to figure that, say, the 127,403rd time random() gets called it's to pick the spawn point. However, I would assume that the worldgen process also involves testing and rejecting candidates, in which case the position would be variable. You'd likely have to perform most of the worldgen process to determine what the random value used to pick the spawn point is. But if the world gen tests and rejects the same seed, it would have exactly the same amount of tests and rejects everytime! The point of the "seed" is so that you can have deterministic randomness.
|
# ? Feb 18, 2012 03:28 |
|
I've heard several times that the best way to get better at a craft is to practice it every day. I was wondering how one could apply this to game design. The answer of 'make a game every day' seems like an unreasonable starting point. Simply writing down game mechanics in a notebook doesn't seem the same taking an idea and putting it into practice. I suppose simply changing it from 'per day' to 'per week' could work.
|
# ? Feb 18, 2012 04:13 |
|
Iteration is a very important part of most game design processes.
|
# ? Feb 18, 2012 04:16 |
|
Serenade posted:I've heard several times that the best way to get better at a craft is to practice it every day. I was wondering how one could apply this to game design. How about working on a game every day? Sounds pretty simple to me. Do you think authors write a new book every day? How about an architect designing a new building every day? A composer writing a new symphony every day? A developer (of any sort) building a new application every day? What I'm trying to say is you should think about what that adage means before you try to put it into practice. There are very few things in life worth doing that can be done in a day.
|
# ? Feb 18, 2012 04:38 |
|
Nippashish posted:How about working on a game every day? Sounds pretty simple to me. A lot of musicians do write songs every day as practice actually!
|
# ? Feb 18, 2012 06:08 |
|
HaB posted:If it's random, then it wouldn't be the same every time the same seed is used. That's what I'm saying. Here's a test to prove it: Because once you have a seed, it's no longer random. A random generator is deterministic for any given seed. For example, seed 332 might produce HHTHHTHT for random coin tosses. It will ALWAYS provide that output. So games will generate a random seed using something that isn't known in advance -- the current time for instance. In minecraft's case, when you enter 1 as a seed, you determine ALL the outputs of the random number generator for the rest of the game. The first coin toss it makes in generating the world will ALWAYS be a heads. So once you know the seed, you know exactly how world generation will go. Smug guy posted:Jeez, guys. I know how pseudorandom number generators work! Clearly this is not the case.
|
# ? Feb 18, 2012 08:31 |
|
Vinterstum posted:1. Figure out the simplest thing you can possibly put on screen, as your first step. This is pretty much exactly how I code, but in addition to step 1 and 2 I like to write out the basic idea of what I'm going to do with just comments. Make a short list of goals to complete step 2, and then once you get in the groove it's easy to keep going.
|
# ? Feb 18, 2012 09:34 |
|
Pfhreak posted:Clearly this is not the case. Could you people get of your high horses for a second and actually read his initial question. He clearly does know how the seed for the terrain generation works. He was asking how the spawnpoint is determined afterwards, as Minecraft has/had the tendency to not always spawn you at the same point on the same seed. That's why the web is telling him it's a "pick some random locations near 0,0,0 till you find sand" approach, but his observation is that it's not. So he thinks it's probably connected to the seed and therefor not random at all. Somehow some of you only read every second word and post to form "Hey guys, wtf, this seed generates the same terrain every time, how does it do that?" The post you quoted was him showing the spawn isn't random, not him trying to show the world generation with the same seed isn't random and trying to figure out why...
|
# ? Feb 18, 2012 13:37 |
|
It's probably just doing something along the lines of x = randomNumber(), y = randomNumber(), z = randomNumber(), in which case, all you need to know is how random numbers are generated. It might be incrementing the coords by the random numbers or something so you don't repeat or run through all the spaces in whatever limit you supply your random number generator, but that isn't really much of an algorithm, which is, I think, why everybody is giving similar answers about how random numbers are generated.
|
# ? Feb 18, 2012 14:52 |
|
westborn posted:
Bless you, sir. ZombieApostate posted:It's probably just doing something along the lines of x = randomNumber(), y = randomNumber(), z = randomNumber(), in which case, all you need to know is how random numbers are generated. It might be incrementing the coords by the random numbers or something so you don't repeat or run through all the spaces in whatever limit you supply your random number generator, but that isn't really much of an algorithm, which is, I think, why everybody is giving similar answers about how random numbers are generated. I spent a few hours last night wading through the Minecraft sources, but following the chain backwards from where the player is actually spawned only leads me to one spot where it's grabbing 3 int values from an NbtTree (which seems to work like a hashtable but can return multiple types instead of just one). I assume the tree is populated using the map seed but hell if I can figure out where that's happening. Specifically: from WorldInfo.java: code:
|
# ? Feb 18, 2012 16:01 |
|
Can anyone suggest some good articles/links on how to set up a rendering engine? My dumb gut-sense guess is that you'd send all your Draw calls to a common graphics manager component that would sort them somehow (by shader type?) and then stream the data to the actual graphics device in a post-draw step. Am I on the right track or wrong track here?
|
# ? Feb 18, 2012 16:09 |
|
westborn posted:He clearly does know how the seed for the terrain generation works. He was asking how the spawnpoint is determined afterwards, as Minecraft has/had the tendency to not always spawn you at the same point on the same seed. No, he clearly doesn't. Here: quote:If it's random, then it wouldn't be the same every time the same seed is used. It's pseudo-random, and it uses the same seed, so it always spawns you at the same point on the same seed. It just uses the generator as it does when it creates the terrain. This uses x numbers from the pseudo-random series. The next 3, x+1, x+2, and x+3 are used to generate the first location it tries to put the player on. These are always the same if you use the same seed, because of how pseudo-random generators work. He clearly does not understand this, or he wouldn't be asking why they're the same every time. And yes, you misread and thought he was arguing that it doesn't spawn at the same point for the same seed, next time read a little further. To answer you, it uses the first 3 numbers it gets after generating the world, then, if they aren't valid, increments each one by 1 until it gets a position that works. Considering the same seed will give you the same sequence of 3 numbers after world generation every time, obviously you'll get the same position for the same seed.
|
# ? Feb 18, 2012 17:17 |
|
Red Mike posted:No, he clearly doesn't. Here: I have no idea how this derail got so far so fast. I assure you, several condescending explanations aside, I know exactly how pseudorandom number generators work. Picking the coordinates for spawn is obviously not as simple as "hurrrrrr get the next number from the generator" because NOTHING in Minecraft is that simple. Chunk generation uses an algorithm which goes beyond "hurf durf here's another number from the generator." It uses a bunch of constant values PLUS the random numbers and does something that eventually results in a chunk full of blocks. It does the same thing with the spawn point, not just "grab 3 random numbers and check if that's valid, increment if it doesn't" In my second post I said: quote:Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is. So FORGET I ever mentioned the words "seed", "random" and "pseudorandom". I REALIZE it's deterministic based on the seed provided to the random number generator. So let's pretend x, y, z are numbers pulled out of thin air. Minecraft then does something to those 3 numbers that results in Spawn.X, Spawn.Y and Spawn.Z. ALL I want to know is - what is something in this instance. And as I have already determined on my own, Minecraft loads up a hashtable (NbtTree) of all the pertinent game values, and then spends the rest of the time just doing lookups in that hashtable. I have found where it does the lookup in the table for spawn x, y, z. What I can't find is where those 3 values get populated into the hashtable. And as far as your "answer" - can you point me to the lines in the MC source where it does that? Or even just the class file it's in?
|
# ? Feb 18, 2012 17:34 |
|
I think I see what's going on here. Most of us are abstracting your question of "How, exactly, does Minecraft generate a starting location?" into, "How do games typically generate a deterministic random set of variables?" For most of us, and for most of the questions in this thread, working at the abstraction level is pretty common for helping someone understand whatever problem they are working on. It sounds to me like you have a project in mind ("I would like to be able to predict a start location for a given seed so I can use that value in my mod/hack/web thing/whatever.") But you haven't really talked about what it is, so it sounds like what you are asking is for general details about random world generation, of which Minecraft is an example.
|
# ? Feb 18, 2012 17:41 |
|
HaB posted:I spent a few hours last night wading through the Minecraft sources, but following the chain backwards from where the player is actually spawned only leads me to one spot where it's grabbing 3 int values from an NbtTree (which seems to work like a hashtable but can return multiple types instead of just one). I assume the tree is populated using the map seed but hell if I can figure out where that's happening. Specifically: That looks like code for loading the spawn location from a save file. World.java has getInitialSpawnLocation() which boils down to this: code:
Edit: For me, at least, a big part of the confusion with this whole thing is that this is an algorithm I would not be shocked to find described as "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" so it's been weird that HaB seemed to want something more. ShoulderDaemon fucked around with this message at 18:01 on Feb 18, 2012 |
# ? Feb 18, 2012 17:49 |
|
Pfhreak posted:I think I see what's going on here. Most of us are abstracting your question of "How, exactly, does Minecraft generate a starting location?" into, "How do games typically generate a deterministic random set of variables?" For most of us, and for most of the questions in this thread, working at the abstraction level is pretty common for helping someone understand whatever problem they are working on. I agree with you, so let me be specific about what I am trying to do. I'm basically writing a map search/view utility. I am using Substrate which a C# library someone wrote for use with Minecraft. (Yes, I already am discussing this in a thread on the minecraft forums with the developer of Substrate). So basically, instead of needing to load a level.dat file, I am generating the map in memory from the seed. The map itself is generating perfectly. That's all Substrate built-in functions for the most part. However, the dev seems to have glossed over the setting of the initial spawn location part, because he just sets it to (0, 64, 0) and leaves it at that. So if I save my generated map and load it in MC and compare against the MC version, everything is the same except for the spawn point, because mine is always (0,0) and Minecraft is picking a different one. My search utility will search within a certain number of chunks from the player's location, or if it's a new world, from the spawn point. So I need to be able to determine the spawn point based on the world seed - which is how everything else is determined. ShoulderDaemon posted:World.java has getInitialSpawnLocation() which boils down to this: I want something more because I need to duplicate it elsewhere, and that description, while generally correct is useless for writing actual code. I will look at world.java to see if I can find what you're referring to. Thanks. Edit: one step closer. the 5 biomes returned are: forest, plains, taiga and two still obfuscated ones. That's closer, tho! HaB fucked around with this message at 18:34 on Feb 18, 2012 |
# ? Feb 18, 2012 18:21 |
|
Well there's probably where the biggest confusion came from... You sound like you're trying to reverse engineer something minecraft does so you can do it exactly the same, now. Before it just sounded like "I'm making a minecraft-like, how does minecraft do this?" to which we all responded with basically "who gives a crap how minecraft does it, just do something simple".
|
# ? Feb 18, 2012 23:01 |
|
Actually, the biggest confusion came from the first post, the following part clearly showing lack of understanding of pseudo-random number generators, whatever way I look at the phrasing.HaB posted:Does anyone know the method by which Minecraft generates the initial player spawn based on the seed? All I can find from googling is a general "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" Unless you suddenly moved from that question to another, what you said then has no relevance to what you ended up with as a solution now. So it doesn't just pull 3 numbers from the generator and plug them into the coordinate system, it pulls one number from the length of the list of biomes, then keeps iterating and incrementing until it reaches a grass block. This doesn't change the fact that if you did understand how a pseudo-random generator worked at the time, the fact that it wasn't different for the same seed shouldn't have surprised you at all. Even moreso, it should have been expected, and the question would have become 'I don't understand how it's choosing the first random position from which it starts incrementing.' Back to the actual topic at hand, the last two should be desert and tundra, if that helps. e: Christ almighty, I'm being pedantic and unhelpful. I'll stop this, my apologies. Red Mike fucked around with this message at 23:31 on Feb 18, 2012 |
# ? Feb 18, 2012 23:25 |
|
I'm having an issue with figuring out decent collision detection for my 2d sprite-based Android game. I've tried implementing some pixel perfect solutions I found online, but they all seem like they're made for an image that never changes in size from the original bitmap. This obviously has some pretty big faults as I draw my images in my game at various sizes, which then get scaled according to the screen size. I was thinking of creating a bunch of smaller boxes per sprite, each representing a part of the object. IE an arm, a head, a torso, and then the legs. This removes a lot of empty space, the alpha, from being false-detected. It's not perfect but it would be a lot closer. Then I could use a tiered system, ie: Check the sprite A's box against other sprite boxes, to see if they will collide at all. If true, check each smaller box section from sprite A to sprite B and if any intersect, a collision happened. These boxes could be scaled and placed where I want them, much easier than per-pixel. It's just very messy and not 100% accurate. My question is, am I just totally misunderstanding pixel perfect detection? I have no experience with collision detection so I may be doing this totally wrong.
|
# ? Feb 19, 2012 00:01 |
|
Unless you're constantly changing the scale, you should be able to just generate a collision bitmask (like a grid of boolean values for solidity) based off the image that you'll render to the screen after scaling, either in the constructor and/or during a setScale type property. If you're worried about memory you can cache the different sizes you make so you can reuse them too. You can do a multiple hitbox approach and it will almost always run faster (unless pixel collision is done in hardware these days), but it's a pain to make new units and so on with, plus for objects that change animation heavily you'd have to update the hitboxes in line with the animation. Either way when doing pixel perfect stuff you want to make sure it only does it when needed, this typically means having bounding box tests before pixel collision tests and if needed making it so only stuff that directly affects the player uses it. If you've got a lot of objects colliding a lot physics engines may be your best bet too.
|
# ? Feb 19, 2012 02:08 |
|
Thanks! I actually managed to get a PixelPerfectBitMask setup working properly, or at least good enough for now. I can start with a high res image, say 512x512, and have OpenGL refer to that for drawing, then for the bitmask I just used Android's createScaledBitmap to the object's actual size and presto, it works perfectly. Edit: Ok apparently it still doesn't work properly. Goddamn this is hard. I don't know how to create a scaled bitmap. I tried the above method by basing it off of Android's createScaledBitmap but that doesn't seem to work either. Only works when I set BOTH objects colliding to the same exact size.. MrZig fucked around with this message at 02:52 on Feb 19, 2012 |
# ? Feb 19, 2012 02:21 |
|
Red Mike posted:*sigh* Red Mike posted:e: Christ almighty, I'm being pedantic and unhelpful. I'll stop this, my apologies. This. So much this. HaB posted:Does anyone know the method by which Minecraft generates the initial player spawn based on the seed? All I can find from googling is a general "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" I bolded the only part you really needed to pay attention to. The other part was pointing out that the google results I was seeing kept saying "picks a random location blah blah" and I was pointing out that it's NOT random because I know how pseudorandom number generators work. I even said it's "based on the seed" at which point this dumb derail got started. K. I will stop now too. Great googly moogly.
|
# ? Feb 19, 2012 02:33 |
|
MrZig posted:Thanks! I actually managed to get a PixelPerfectBitMask setup working properly, or at least good enough for now. I can start with a high res image, say 512x512, and have OpenGL refer to that for drawing, then for the bitmask I just used Android's createScaledBitmap to the object's actual size and presto, it works perfectly. I guess make sure there aren't any offsets you're not aware of are at work and step through with a debugger or debug text write what the mask looks like internally and make sure it lines up with what you think it's meant to look like. I mean other than that it's just a case of getting the logic for the test right.
|
# ? Feb 19, 2012 02:55 |
|
brian posted:I guess make sure there aren't any offsets you're not aware of are at work and step through with a debugger or debug text write what the mask looks like internally and make sure it lines up with what you think it's meant to look like. I mean other than that it's just a case of getting the logic for the test right. It definitely works 100% when both objects sizes are the same, so I'm thinking offset. I'm using the detection system from AndEngine, as can be found in the reply here: http://stackoverflow.com/questions/7461781/android-opengl-pixel-perfect-collision-without-bitmap-data To call it, I'm using this code code:
|
# ? Feb 19, 2012 03:57 |
|
|
# ? May 12, 2024 08:05 |
|
Well for a start you're doing test(enemy.x - this.x, this.y - enemy.y) when you want it to be test(enemy.x - this.x, enemy.y - this.y). Other than that I don't know. Just work out what should be happening on one test and what's actually happening and work out what you're doing wrong from the difference. It's really what you end up doing most of the time in game development.
|
# ? Feb 19, 2012 05:11 |