• Advertisement

Alberth

Member
  • Content count

    1717
  • Joined

  • Last visited

  • Days Won

    2

Alberth last won the day on April 2

Alberth had the most liked content!

Community Reputation

9604 Excellent

5 Followers

About Alberth

  • Rank
    Contributor

Personal Information

  • Interests
    Programming
  1. In c++? Since std::string, I'd say, except as string literals.
  2. I'd see your first wall as 2 tiles high and 7 tiles thick Pointing out good examples and bad examples is quite easy most of the time. The trouble is always finding a rule that allows you to decide "good" vs "bad". My first attempt failed, how about "Every wall must have a non-wall neighbour at most thickness/2 tiles away" ?
  3. It's Python indeed, so much nicer for explaining ideas and for experimenting implementations. Apparently I don't understand what you see as "thickness of wall" then, could you state a precise definition of thickness please? I don't see how you want to allow to fill in holes, and also have your requirement "I DON'T want the player to be able to just fill in any amount of tiles to make a super thick wall.". If you allow filling gaps, how would I not be allowed to make a big area of walls with gaps between them (thus avoiding the thickness restriction), and then as a second step, fill all gaps to get a massive wall? (Since above you say I should be allowed to do that, it seems.) Good point, but afaik Dune2 walls have no direction, they just attach to any wall nearby (in all directions). As another point of discussion, what is the problem with building a fat wall exactly? You can just go around it, right? Just make sure a path exists to whatever the player is protecting?
  4. In each direction, count the number of wall tiles. If the maximum is more or equal to the max thickness, do not allow. def test(x, y, max_thickness): for dx, dy in [(-1, 0), (1, 0), (0, -1), (0, 1)]: ok = False for n in range(1, max_thickness + 1): xpos, ypos = x + dx * n, y + dy * n if xpos < 0 or ypos < 0 or xpos >= MAX_X or ypos >= MAX_Y: ok = True break if tile[xpos, ypos] != WALL: ok = True break if not ok: return False return True
  5. Collect all the values as a list of strings or so, and at the end, concatenate it to a single string. Alternatively, insert already existing text as "%s" into the next string, so the "%" signs in it are not interpreted.
  6. Start with library or complete engine?

    Game loop sounds mysterious, but it's just a loop running at animation frame rate, handling user input from mouse/keyboard, updating game state, and rendering graphics to the screen. LibGDX looks like you have to write that loop yourself, so yep, low enough Drag & drop is generally not enough with engines, you always have to write logic, generally by programming it in C# with Unity. Unreal has blue-prints, for users afraid of typing code, but that's of course programming with the mouse Engines are mostly a framework with a lot of default functionality that you can extend, from what I understand of it (I also prefer the DIY solution, as it's more fun for me that way).
  7. Start with library or complete engine?

    Engine versus a library are complementary, I think. Using a library means that quite some of the ground work needs to be programmed by you, so you get to see how the core game loop works for example. An engine hides much of the low level stuff, and you step in at a much higher level of things directly relevant to the game, where motion, physics, and details of getting the images to the screen have already been done for you. Both are valuable to understand in the long term, imho. As for what to do, nobody said you can't do both. You can for example just play with both for a week (or make 1 game, or whatever you want as first experiment), and see how you like it.
  8. Developing 2D sports game

    While math is always useful to know, I don't think you need to go down to physics for a simulation for a retro game, you can just draw a random number to decide the outcome, then have an animation that shows it to the user. (Much of games is smoke and mirrors, you only want to make it appear like a realistic game, that does not mean you also have to code it like that!) EDIT: If you do need physics, a falling body under gravity is a simple second degree polynomial y=0.5*g*t*t + v0*t + x0 (with g gravity=9.8 on earth, v0 is initial velocity, x0 is initial vertical position, t is time in seconds), Compute y for increasing t.
  9. Developing 2D sports game

    Game engines are much geared towards 3D, 2D is mostly 3D where the camera looks at a flat space, ie the scene has no relevant depth. If you're looking for a more bare-bones approach with C++, using a 2D library like SDL2 would be a feasible option. LazyFoo has a nice tutorial about it, make sure you pick SDL2 and not SDL1.2 tutorials there. Since you don't have an engine in this setup, you have to write more C++ code for low-level stuff like loading graphics and handling user input etc.
  10. Choosing programming language

    So you had about 5 years experience then. Would it be sensible for a newbie that doesn't even know what a 'variable' is, to see the hero videos? Would it make sense? I have some doubt about that. Writing code at that point is really total magic, it mostly looks like a jumble of weird symbols with english words. I think I can understand what you're saying with the revelation. A higher level language is hiding a lot of low level stuff from the user. I can see that may feel awkward. I have that problem with Eclipse. I have been using it for many years, and t's a mostly working system, but I just don't understand it at all even after all those years, it still feels like a number of plates randomly floating on bottom-less quick-sand. There is no foundation under it to start understanding it for me (at least I haven't found it so far). C, C++, and even OOP on the other hand, I can perfectly use and understand. The reason is that I started from assembly language (can't get much more solid than that), and climbed up to C, C++, and further, for the past 35 years, and still learning new things today. Each step was weird, but since I always had a foundation under it from which I could build and extend to understanding the new thing, it worked for me. (ie Eclipse is different for me, as I fail to recognize what knowledge under it relates in what way to whatever Eclipse is doing.) For you, I can see that stepping down from high level OOP language like Java or so, to C can be experienced as a revelation. You suddenly got a solid context to build your knowledge and experience from, and all the puzzle pieces in your head suddenly matched and "clicked" together in one big body of knowledge. It's always an extremely good experience when that happens!
  11. Choosing programming language

    At what point in your programming career was this? How much knowledge does he assume? Since you say "revelation", I assume you had some experience in programming and OOP already? That means you already knew a lot of stuff compared to a total newbie?
  12. How to start the journey

    Actually, game design and programming are different things. Game design is dealing with the problem of what to present to the user, how to make the game interesting to play. What choices does the player have, and how does that affect eg other players of the same game. What problems does the game throw at the player, and what are ways to solve those problems. What should happen if a player doesn't progress as fast as other players, and so on. Game programming deals with the more technical problem of explaining to a computer to perform the above design, that is, to implement the design for computer games only. It involves writing program code, thus learning a computer language like Python or C#. For game design you don't need to do programming, although if you want to design computer games, it would be useful to know at least some of it. On the other hand, if you want to design card games or tabletop games (ie non-computer based games), you can do that without knowing how to program a computer. There is a game design sub-forum here, to discuss about game design. I have no experience with game design at all, but I'd guess the best way to start is to make actual games, and try playing them. Lots of "on the job" learning thus Likely the game design forum has a few starting points ready in a FAQ or a stickied post, and otherwise, just ask there. Good luck, and have lots of fun!
  13. Choosing programming language

    @erpeo93 I think most discussion comes from the fact that you do push new users in "your" direction. In your first post you claim that "C and handmade hero is EVERYTHING you need". Give the OP the chance to discover such things by himself. Give him all the options, not just the one that works for you. It's fine to explain that some things are popular but didn't work too well for you, or you don't know about much, but do mention them, and be honest. As for your OOP-fobish, maybe you were taught wrong? There are lots of bad ideas told around OOP. Totally strict OOP is indeed not a good idea I found as well. However, rather than discarding the entire idea, I change coding paradigm to get around the weak spots, and I now use a happy mix of imperative and OOP paradigms to get the job done. Use OOP when it fits the problem nicely, switch to more imperative programming style when OOP is less useful. I do have classes, and a bit of inheritance, but also a large number of functions ("static methods") with "if (foo instanceof Bar) { ...}" dispatching code to avoid scattering a function all over the classes in the hierarchy. (Code does lots of recursive calls to itself, having it all in one function with dispatch statements simplifies writing and debugging a lot.) At some projects I do have to code in C (C89 even for crying out loud), and then I do miss the nice things from classes here and there. Sure you can mimic it in structs (and I do), but being able to express that in the language itself does work better. As a suggestion to you, experiment with OOP. Try things, find out what works and what does not work. If it doesn't work one way, try a different approach. Leverage the strong points of paradigm, and make your own happy mix. Pure OOP is not the answer, but pure C is not the answer either, or the entire IT industry would not have embraced the advances that broadly.
  14. Problem serializing small ammount of data

    I don't agree that using binary data file formats is better. Yes, the input/output code is simpler to write, you don't have the data -> string -> textfile conversion (and vice versa on loading), and binary data is harder to inspect and modify for the user. On the other hand, debugging from a binary data file is more complicated, since you cannot simply open the file and read what it says. You can also not easily edit it, or author new files (eg new levels for your game). I think that's a lot to give up for gaining simplicity of writing input/output, especially in non-commercial games.
  15. Problem serializing small ammount of data

    The problem, is that constructing a large string is quite deadly for performance, so that's what you should try to avoid. I don't know C#, so I used Java, which is close enough I hope to get the idea across: byte[] bytes = {1, 2, 35, 8, 127}; // Open a text file for writing BufferedWriter handle = new BufferedWriter(new FileWriter("output.txt")); // Convert each byte to a string, and write the string for (byte b : bytes) { String s = Byte.toString(b); handle.write(s); handle.write(' '); // Add a space after each number. } handle.write('\n'); // Add a newline at the end. handle.close(); // Close the file. The code constructs a string for each value, and writes that string to a text file. This code makes many small strings, which is not a major problem. And the file looks like (as you'd expect) 1 2 35 8 127 I hope you can convert this to something C#-ish if you like the idea.
  • Advertisement