I'm completely new to Godot and I'd like to make an underwater game. I feel like one of the first steps is to generate something like a trench. I've touched on Perlin noise in Processing, but I have no idea how to manipulate it to make something resembling a trench. I also don't know how to write in Godot, but I assume that will come with yt tutorials and time.
I haven't tried it yet, simply because I have no clue how to or where to start.
Related
I know how a basic PID works but am getting to a point where I need something more advanced to account for more complex movement. I've seen that there is often an acceleration term added to a PID, but have not been able to find anything online that introduces me to the basic theory of how it works (and the math involved). I can take a guess that it involves kinematics equations, but would rather see what's already developed before reinventing the wheel (and probably it won't be a great wheel). Could somebody please explain this to me or point me to some documentation that will?
i'm working on a simple game project with libgdx and i need some help to make a random infinite world. After googling for hours i knew that many games use the "chunk theory" to generate an infinite map and also implement tiles. There are many things i don't understand... for example:
What is a tile? and a chunk?
How can i implement this "chunk theory" in a game?
Is this the best way to generate an infinite random map?
can someone answer my questions to make some clarifications in my mind?
Thanks in advance
Tile-based maps are maps, which are organized as a grid. A Tile is then a cell of this grid and objects are placed inside this Tile/cell and can't be placed between to cells. Think about Minecraft, every Block there is one Tile.
A chunk is a part of the map, containing many Tiles. It has a fixed size and is used to be able to load only part of an infinite map.
Imagine a map with a size of 1600*1600 Tiles. You won't be able to see all Tiles at once. Also you don't need to update the logic for the whole map, as it won't affect you anyway. So you split your map into little parts, so called chunks, which have a fixed size (for example 16*16).
Depending on your position, adjacent chunks are loaded and far chunks are unloaded. So if you move from south to nord, chunks in the nord are loaded, chunks in the south are unloaded.
I never implemented a chunk-system myself, so i can't tell you how to implement it, but i guess there are many tutorials out there.
This is not the way to generate infinite maps, but the way to store, load and work with huge maps. The generation is usualy done with some noise functions, but thats a different story.
Anyways i suggest you to start with something smaller and simpler. Rushing into to complex things will just discourage you.
http://app.geokone.net/ is an open source javascript app for generating shapes (if you can look at it, it's really fast, for 5 seconds, I'm sure you'll get the idea).
It's hard for me to go through it because it's a lot of code, what is the general idea?
also, I need those shapes as GameObject with polygon collider around them (anything from 0 to 20 of them on the screen at the same time, could be different shapes also), is it even possible with GL?
would GL help me? I think GL would be fast for just 1 shape or something (as it's using recursion), but for what I want, I think drawing them in real time to a texture, then using the texture as a sprite would be faster (as I can save the sprite for shapes that are the same), or maybe I should use a shader? any other method that you can think of?
and for the algorithm itself, what is the general idea?
You don't want to use GL, look into custom mesh generation with MeshFilter. It is required for the colliders anyway.
Meshes have to be updated just once and probably will be faster than any optimisation you proposed. You might need a shader to draw it, though.
As for the algorithm, I'm afraid you have to look into it yourself or hire someone for it. StackOverflow is for helping with issues, not doing the work for you. If you need a hint, look into basic fractals
I'm a hobbyist game programmer. I only do 2d games, no 3d stuff. I don't have a math background and lots of things are tripping me up like bullet projections and angles.
I took two college level Algebra courses at the local community college, but really disappointed. I got As in both, but really don't feel like I'm using any of it in my everyday 2d game programming and still stuck on angles/bullet paths, etc
I dropped out this semester to self study. The advisory at the community college said I want to be in Statistics for this and was really pushing me hard to enroll in that class. He said Statistics then Calculus I & II would get me what I needed.
I've been reading up a lot and not so sure on this. I think I should start with a a Geometry book and then move into Trigonometry? Is that the right approach?
Anyone suggest any good self-study starter books?
I got a lot out of "3D Math Primer for Graphics and Game Development". I know it says 3D but there is a lot of stuff in there for 2D. And the math is fairly simple linear algebra.
It sounds like statistics is useless for what you want to do. Calculus might be marginally useful, but not until you are really solid with it. You probably need to learn trigonometry more than anything else. I could offer more explicit advice if you give an example of a problem you're trying to solve.
There are a few points here:
1) The statistics suggestion is a complete misdirection, and this advice should be completely ignored, along with the person who gave it to you. Statistics is an interesting topic, but not at all useful in game programming (except maybe for a few esoteric approaches to esoteric topics, maybe, like, drawing clouds).
2) (Not that you seem to but...) it's not uncommon for programmers to make the mistake of assuming that they can just learn everything on the job, but most science topics (including math) can not be effectively learned this way. With these, one needs a much more structured approach, building an elaborate structure of ideas, with each new idea built on top of the previous. You could certainly program games with a few equations that you learned to use from a game programming book, but it's unlikely you'd ever have the ability to solve problems that you hadn't already seen solved somewhere else.
3) The best way to get comfortable with math is to solve lots of problems, and not on the computer, but with pencil and paper. For example, you can easily write a program to test that sin2+cos2=1, but to prove it, you need to understand it.
4) Of the topics you'll need, trig is the most time effective place to start. Geometry would be a bit useful, but probably not so much. Another useful topic is linear algebra. Calculus is also useful for calculating trajectories that have acceleration (and gravity), but it's a much bigger topic and involves so many new ideas that it's probably a bit difficult to pick up on your own. Maybe for this topic it's best to try to glean a few useful approaches and equations.
Final suggestion: I recommend starting with trig, and use a book that gives concise explanations followed by lots of problems that are solved in the back. For example, Schaum's Outline of Trig for $13, would probably be a good choice. You don't need to solve a every problem in the book, but work them until you're comfortable, and then move on.
I'm trying to create a game similar to this (Note:When you click 'play', there are SFX in the game which you can't seem to turn off, so you may want to check volume). In particular, I'm interested in knowing how the 'infinite' landscape is generated. Are there any tutorials/articles describing this? I came across procedural generation, but I'm not quite sure what topics I should be looking for (or if it's even procedural generation).
(I'm using C#, but I don't mind the language as I assume the theory behind it remains the same)
That one seems like it would be pretty easy to duplicate -- I would imagine an algorithm that calculates the next "step" of the landscape (the part that is off the screen). It would need to know the prior height (and maybe even the previous slope) in order to then (randomly) increment or decrement the step. You could then tweak the algorithm to be more fluid (gently sloping), or extreme (whipsawing back and forth) as time passes/levels are completed.
Before I clicked the link though, I thought you might have been talking about voxel landscapes -- which I haven't thought about for over a dozen years, but amazed me when I first saw them. I did some googling, and thought you might be interested in this:
http://www.gamedev.net/reference/articles/article655.asp
(Not sure if the Mars demo still exists, or if anyone has a DOS machine to play it on, but this is a good example that shows what it used to look like: http://www.codermind.com/articles/Voxel-terrain-engine-building-the-terrain.html )