Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Alberth last won the day on December 9

Alberth had the most liked content!

Community Reputation

9733 Excellent


About Alberth

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Alberth

    Properly stretch texture on quad unity

    I'd say start by showing how you made picture 1. Obviously something is wrong in the settings, but without you telling us what you did, we can't point out the error. In other words, show the core code for making picture 1. For comparison with a simpler case, your question is like "The answer I got is 3. I want the answer to be 7. What did I do wrong?" No way to tell what is wrong without having the steps to obtain 3.
  2. Alberth

    I think my game is so terrible

    So your game is not bad, only the graphics are not so nice (A bad game would be a game that is not fun to play.) Assuming you use Pygame, did you have a look at the tutorials? https://www.pygame.org/wiki/tutorials The first entry "Tutorials by DR0ID" looks useful. At least https://dr0id.bitbucket.io/legacy/pygame_tutorial01.html draws an image to the screen, and flips the display (ie the back surface thingie).
  3. Computers are very good at storing insane amounts of data, and computing everything really fast. In other words, don't make the table yourself, write a program that performs the computation given some input data. If your input data can be systematically computed from other input data, you can repeat this trick of course. I think the bigger problem is what to do with the huge amount of numbers. People are bad at finding their way in numbers. I think you should spend some time on how you're going to present the computed result to a user.
  4. With my limited knowledge of American Football, I'd suggest you start with something much simpler. Say your field is 100 units long. For each 'run' (the ball becomes available, people play a bit, and the game is stopped again), the most basic progress is that everything moves a few units on the field, and possibly the defending team can take possession of the ball(???). For simplicity, let's assume that the team scores a point if they reach the opposite side of the field. This means you have somewhere near 3 numbers for a team. "average progress while in ball possession" (on the field), "average ability to defend against progress", "chance of getting in ball possession". In a game, you have a fixed number of runs (just keeping things simple at this stage), and for a run, from the 6 numbers that you have from above, you need to compute the amount of progress in the field, and who owns the ball afterwards. Special case is reaching either side of the field. I agree it's not football as you see it on TV, it lacks a zillion number of details. There are however two reasons why this is a good first start. - Currently you have nothing at all, and you're struggling to decide what data you need. You have that struggle, because you lack knowledge of what works. By building this simple thing first, you have a start (ie something is working), and you can better judge what is lacking. - Secondly (but probably just as important as the first point if not more), a game is a game, In particular, it's not reality. The only thing that the game has to produce is convincing end scores (right?). It's all smoke and mirrors. The game only has to pretend a game is being played. It doesn't necessarily actually need to simulate every little detail. I got into games because I am fascinated by this phenomenon. You can pretend very complicated behavior by doing something totally different (not feasible in reality) and solve the whole problem in a very simple way. As long as the smoke and mirrors are done well, players are easily convinced the real thing is being done, while the actual code is just a few trivial calculations and a few random die throws to make the decision. Of course, like a good magician you never tell the public your secret for writing such a good game
  5. You'll need a Node and an Arrow (or Edge), where Arrow represents the dependency between two nodes. For uni-directional dependencies, a Node has a collection of Arrows, an Arrow points to the other Node. Also you need to decide what A -> B means. Does it mean that A needs B, or B needs A? What you pick isn't very important, except you have to select one. You can also have bi-drectional arrows, where both nodes can find the Arrow, and the other side. The arrow becomes fully symmetric in that case. Another way to code a bi-drecional arrow is to use two uni-directional arrows. How to actually represent that in code depends on the kind of information that you have, and the scale of things. If a Node is a single integer number, you can have a list of lists. (First list indexes on the node number giving you the container of links to other nodes,) The link can be as simple as another node number (ie no attributes on the Arrow), or you can make the inner list a List of Arrow, where the Arrow class stores the attributes of the link and a node number. If a Node is an object, the simplest is to store the container with links in your Node, and directly point to other node objects, Having a list of Arrows works nicely if you don't remove Arrows often, and you typically need to access all successors in any order. If you need a specific successor node, you may want to use a map of arrows at the cost of some memory overhead. In fact, the map may become the arrow, the key points to the successor node, its value can contain the attributes of the link. There really isn't a single best solution. It all depends on how much information a node or edge has, how many nodes and edges you have, and the kind of graph operations you want to do. There are many dedicated algorithms for performing graph operations, and they typically expect a special form of the graph for maximum performance. You may want to start at this end, so you can design your graph structure to fit the needs of the algorithms you want to perform.
  6. The problem with arrays is that you get all these magic index numbers sprinkled throughout your code. Say you have a colour stored in an array. When you pass it to the drawing code, you need to write something like "draw(array[0], array[1], array[2])" (C# and most other languages start counting at 0. Lua is one of the exceptions there.) The problem is now, you have "array[2]", but after a year you don't know what it represents. Was it a colour or the alpha channel? If a colour which component? Instead of arrays with magic indices, a better solution is to make a Colour class (if it doesn't exist already) and write something like "new Ball(new Colour(1,2,3));". Bit more work, but you can write "ball.colour" or "ball.colour.red" which gives much more information what data you're passing around through the program.
  7. In that case you know the x position, so you can use that in the 2nd line to find n2 (unless the 2nd line is vertical as well, then you end up in the parallel case, see below). Use the 'x position' equation of the 2nd line where you use the x of the first line as resulting x position. This gives n2, and y of the shared point. Next you can use the 'y position' equation of the 1st line to get n1. Good point. I didn't interpret the result, I just mechanically performed equation rewriting. Make sense though, that the equation can't be solved in that case 😛 Technically, both lines can also be on top of each other, which means you will need to check if the segments overlap. I think it's sufficient if one of the end-points is part of the other line segment. I wonder if a simple AABB (axis aligned bounding box) check would suffice.
  8. Simple straight formula shuffling I think 1st equation a1 + n1 * dx1 = a2 + n2 * dx2 move a1 to the right <-> n1 * dx1 = a2 + n2 * dx2 - a1 divide by dx1 at both sides (dx1 != 0 thus!) <-> n1 = (a2 + n2 * dx2 - a1) / dx1 (#) 2nd equation b1 + n1 * dy1 = b2 + n2 * dy2 fill in n1 from above <-> b1 + ((a2 + n2 * dx2 - a1) / dx1) * dy1 = b2 + n2 * dy2 split the big / dx1 into seperate terms b1 + (a2 / dx1 + n2 * dx2 / dx1 - a1 / dx1) * dy1 = b2 + n2 * dy2 same with * dy1 b1 + (a2 * dy1 / dx1) + (n2 * dx2 * dy1 / dx1) - (a1 * dy1 / dx1) = b2 + n2 * dy2 move terms without n2 to the left, with n2 to the right factor n2 out b1 + (a2 * dy1 / dx1) - (a1 * dy1 / dx1) - b2 = n2 * dy2 - (n2 * dx2 * dy1 / dx1) = n2 * (dy2 - (dx2 * dy1 / dx1)) divide by (dy2 - (dx2 * dy1 / dx1)) (which should not be 0 !) n2 = (b1 + (a2 * dy1 / dx1) - (a1 * dy1 / dx1) - b2) / (dy2 - (dx2 * dy1 / dx1)) n2 in terms of line segment number, is computable fill n2 into the first equation at (#) and get n1
  9. Alberth

    How to program smarter??

    Wouldn't a switch over the enemy type work? At least it beats sequentially testing so many values. The compiler will likely convert it to a dispatch table, so it jumps directly to the right piece of code.
  10. Alberth

    Actual logical code theory resources

    Never even seen BP, but the closest thing that exists in graphical style is likely the flow chart. https://en.wikipedia.org/wiki/Flowchart There is also the Nassi-Shneiderman diagram, which is equivalent, but it uses sub-sections of an area. https://en.wikipedia.org/wiki/Nassi–Shneiderman_diagram Maybe UML also has a few interesting diagram types as well. While the diagram names may give you a more concrete starting point for a search, I am not sure how much help it actually is. Typically, it's a lot more work to draw one of these diagrams compared to writing a few lines of pseudo-code. It also costs more space. I have never seen game structure being explained in diagrams but then again I have never looked for it either.
  11. Except I stated as input conditions a full circle as non-negative number. I don't know why you need 2 full circles to state a direction, looks very complicated to reason what happens in the game that way, as any direction has two valid answers. Also you may want to clean up your code, variables with a constant value are polluting, especially when they have the wrong name (neg_rot means negative rotation, and that's not the same thing as "half a circle"). Your if/else to catch too large jumps is quite convoluted. It will get a lot cleaner if you first compute the actual jump you want to make and then update your rotation, rather than jump a fixed distance, and compensate in an opposite direction afterwards. The second rotation calculations in the if/else branches are totally unnecessary, realize what pos_rot (and neg_tor used to) compute, and relate that with your jump.
  12. You shouldn't treat code as a black box that magically produces the correct answer. The computation is right there and it's not difficult, so take some time to study and understand it. Once you understand how it is intended to work, get an example where it fails, and do the computation step by step (either in a debugger or even manually with a calculator). At which point does the example deviate from the intended answer? Why? That is the information you want to start thinking about a solution. If you want to discuss it here, please provide a concrete example of from_angle and to_angle where the code fails, so others can verify your findings, and play with the code to find the cause. It may also clarify what you mean, eg I have no idea what "left" means, the code only has positive and negative rotations, there is no left or right in there. As I ran an exhaustive test while writing that code, my first random guess of your problem is that you're not obeying the input conditions. Of course my tests may be flawed as well, so I am quite interested in an example where the code gives an incorrect answer.
  13. Ideas are never detailed, and tend to skip over most details. They are a "birds-eye view", a global dot at the horizon. As a result, ideas may look sane from high in the sky, but silently skip over many important details which may or may not break the whole idea. Code exposes the weak points in the idea, as you are forced to take small steps in high detail, as you explain to the computer how to realize your idea. If you cannot code something, it is not the code that fails, it's the idea that skipped a relevant (breaking) detail in the plan. Trust the code to be telling the truth and adapt the plan around obstacles found in the code, instead of trusting the idea and code it as you originally planned it. The latter will fail, in fact when you're stuck it already did exactly that.
  14. This is indeed the tricky bit, and it's inherently connected to doing new things. Tutorials always look so easy, as they just code the program fluently in one go, without hesitation, and without (big) errors. However, what they don't show you is the 10 rehearsals they had to do before they could do it that fluently. In other words, they show a movie, the final successful result where everything runs smooth and perfect, rather than the entire path from literally no knowledge about the problem to that result. Unfortunately, reality works differently from a movie. If you try something new, you're inevitably making mistakes. You don't have the experience yet to know what to avoid. On the negative side, things that look reasonable when you write it turn out to be blocking obstacles further in the process. Ideas that you had how things should work turn out to be large tar-pits of complicated edge cases that are not solvable. On the positive side however, some parts of what you coded do look ok, don't they? It's not that you have a blank file, type a single letter and think "oh, this is too difficult, I quit", right? You're currently putting too much trust in your initial idea of how to solve the problem. When you get stuck, it's hard to break out of that situation, since you trusted your idea to be solid and it failed you! The way out is to trust your code more than your idea. Ideas are nice, they show a direction and a very vague end-point, but they may miss major obstacles, or have large blank areas even if you don't see them. An idea is like pointing out a far away destination at a map. "There I want to go". At that time you haven't considered how to actually get there, which streets to pick exactly, checking there is actually a connection from street to street, and each street can be passed in the direction you want (and is not a one-way street in the opposite direction). Coding on the other hand, is all about streets. In fact, it's about every single stone in every single street. No big holes between every two stones, are they sufficient level so you can move from stone to stone? street not flooded or jammed? Can you drive there? How fast may you drive? Do you have enough gasoline? If not, where can you get more? etc etc. All the little details you have to deal with when actually getting from A to B. As such, a failure to code something is not about not being able to write code, it's about bad planning. Pointing at a destination wasn't enough, you should have taken more care in the details of the plan. The failed coding experiment is actually helping you here. At the point where you got stuck, there is something that breaks the plan you had. An unexpected barrier due to road works. It tells you exactly what in the plan was incomplete, and this is great. Instead of a very global "nah, you can't go there" without any explanation as to why, your code says "nah, won't work, as at that turn in that street in that city, you can't pass, since the 32nd stone is not level with the 33rd stone". This is very useful information, as you can specifically adapt your idea to work around that obstacle!!! Time to get creative, adapt the plan, and try again. Obviously, your coding abilities do make a difference. You'll find more obstacles on your way than I would, after 40 years of traveling. However, for both you and me, if coding fails, the plan is basically too complicated to achieve, we wanted more than we could deliver. Making the plan simpler is often a good way to make progress again.
  15. An infinite line in 2D has a base-point (a, b), and direction vector (dx, dy). All points of the line are at (a + n * dx, b + n * dy) for all values of n. Line intersection is the problem of 2 lines (line 1 and line 2) sharing a point, ie a1 + n1 * dx1 = a2 + n2 * dx2 and b1 + n1 * dy1 = b2 + n2 * dy2. Alll values are known except n1 and n2, so you can solve this set of equations for non-parallel lines, giving you n1 and n2. The shared point is then (a1 + n1 * dx1, b1 + n1 * dy1). For line segments, you solve the above infinite case first, and then check if the shared point is in both segments. The simplest way is to select a smart (dx, dy) value for that. A line segment from point (a, b) to (c, d) gets direction vector (c-a, d-b). This maps n=0 onto point (a, b), and n=1 onto point (c, d). Values of n larger than 1 or smaller than 0 are outside the segment. Thus, after finding n1 and n2 in the above infinite line intersection, you only have to test "n1 >= 0 and n1 <= 1 and n2 >= 0 and n2 <= 1".
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!