Jump to content
  • Advertisement

a light breeze

  • Content count

  • Joined

  • Last visited

  • Days Won


a light breeze last won the day on March 29

a light breeze had the most liked content!

Community Reputation

26 Neutral

About a light breeze

  • Rank

Personal Information

  • Website
  • Role
    Creative Director
    Game Designer
  • Interests


  • Github
  • Steam

Recent Profile Visitors

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

  1. a light breeze

    Custom size_t

    I'm pretty sure that size_t in C predates C99 anyway.
  2. a light breeze

    Custom size_t

    Short version: yes, use std::size_t in C++ and plain size_t in C. There are a handful of cases where you want more than 32 bits even in 32 bit mode (e.g. when dealing with the size of multi-gigabyte data files that are never loaded into memory in their entirety). In those cases, use std::uint64_t instead. But don't try to reinvent size_t. As for the Unreal engine code, I can think of two possibilities: Workaround for crappy console SDKs. This may be a valid reason for reinventing size_t, but only if and when you actually run into it. NIH syndrome. This is never a good reason for doing anything.
  3. a light breeze

    How to react when people say my game looks like shit?

    If you're looking for low-hanging fruit to fix, then I suggest making the grass darker. You have this cool dark-with-glowing-lights æsthetic in your structures, but the glowing lights are being drowned by the grass, which is almost as bright and much bigger. Maybe change the lighting from daylight to dusk or night so that the grass doesn't receive as much light, or maybe just use a darker grass texture.
  4. a light breeze

    Managing a growing project

    I've found that it's best to keep working until the code starts getting hard to manage, then refactor until it's manageable again, then write more new code. Up-front planning sounds good in theory, but it has a few problems in practice: If you spend too little time planning, then you'll run into problems that your design didn't anticipate. If you spend too much time planning, you run the risk of your design becoming just as unmanageable as your code. Worst case, you never manage to leave the design phase. A lot of ideas that sound great in the design phase turn out to be unworkable in the coding phase. Some of my worst spaghetti code came out of a beautiful up-front design that had to have new incompatible features patched in to meet new requirements.
  5. a light breeze

    How to make combat interesting? (RTS)

    It looks like you've got a really simple system, and it looks like this is intentional. Until you get to the late tech, it's basically all peasants and spearmen. There's no room for rock-paper-scissor with just these two unit types. There are lots of ways of adding depth to the system, but they pretty much all involve adding complexity. For example: You could add more unit types. Tons of options there; I'm not even going to try to list them. You could add the concept of hunger and supply wagons. Supply wagons move more slowly than soldiers, so you can move more quickly by moving your soldiers without the supply wagons, but the longer the soldiers are away from the supply wagons, the weaker they get. Also, supply wagons are vulnerable targets that can be attacked if the soldiers are elsewhere. You can add the concept of giving soldiers high-level orders, e.g. fight aggressively, fight defensively, hold ground, orderly retreat, run!, pursue the enemy, take out the archers. You can let individual soldiers level up, which increases their effectiveness but also makes you try harder to keep them alive. You can give different unit types different bonuses based on terrain types, e.g. archers are more effective in rough terrain. You can add a system where you can give temporary or permanent bonuses to particular soldiers. On the other hand, if you want to keep it simple, then you can make it more interesting by making it more interesting to look at. That means lots of interesting animations. Let your units actually choose strategies and implement them instead of just walking up to the enemy and attacking. Let units randomly go berserk. Let units panic when they are outnumbered. Let panicked units retreat and regroup.
  6. a light breeze

    Pixel rounding problem... (c++)

    Then the problem is probably with the scale variable. If it's an integer, then my code should work. If it's not, then I'm out of ideas. Oh, and the x and y variables need to be integers too, but it's easy to correct them if they're not. Just cast them to int.
  7. a light breeze

    Pixel rounding problem... (c++)

    That's not quite the case. There are certain numbers that can be exactly represented in a floating variable. These include all sufficiently small integers, but also all sufficiently small fractions so long as the fraction has a power of two in its denominator. In other words, it is possible for the called function to losslessly convert its floating point arguments back into integer coordinates. To see this, try the following: Make sure that you have an image with power-of-two dimensions. Make sure that you use rounded_progress as defined above. Replace the picPartRel function with one that prints out the following values as floating point: posX posY xStart * pic->GetWidth() yStart * pic->GetHeight() xEnd * pic->GetWidth() yEnd * pic->GetHeight() If all of the printed results are perfect integers, then you have passed in the correct parameters, which means that the problem is in the picPartRel function. If the results are not perfect integers, then either you didn't follow all of the instructions or I made a mistake, which has been known to happen from time to time.
  8. a light breeze

    Pixel rounding problem... (c++)

    The problem is either in the function you're calling or in the parameters you are passing into the function. In the former case, find another function to use instead (if it's from a library) or fix the function (if it's yours). In the latter cases, you can try rounding your progress variable to an integer number of pixels: rounded_progress = float(int(progress*pic->GetHeight())) / pic->GetHeight(); gfx.picPartRel(x,y+(1.0-rounded_progress)*pic->GetHeight()*scale,pic,0,1-rounded_progress,1,rounded_progress); It helps if pic->GetHeight() is a power of 2, because then the division in the rounding operation is lossless.
  9. a light breeze

    Pixel Art Resolution

    If you think that example is sharp, then you might want to get your eyes checked. That screenshot looks barely tolerable to me in its native resolution, and downright painful at x2. Yes, if your scaling factor is small as 2 or 3, then scaling like this will look bad because there is a huge difference between 2 and 3. If your scaling factor is 16.5, then the scaling artifacts will be a lot less noticeable because the difference between 16 and 17 is a lot smaller. It won't look perfect, but it'll certainly look better than anything that uses bilinear filtering. In my entirely subjective opinion.
  10. a light breeze

    How to chart out the flow of the economy of a game

    That's not what your link says. It uses the term flow diagram, which according to Wikipedia is a term can be used either as a synonym for flow chart or as a more general term for the kind of thing a sankey diagram is.
  11. a light breeze

    Pixel Art Resolution

    Pixel art will scale correctly if you turn off all texture filtering, so long as you scale by an integer number. Pixel art will scale mostly correctly even if you scale by a non-integer if your scaling factor is large enough, so long as you turn off all texture filtering. Pixel art will always look like ass if you use texture filtering. This has nothing to do with texture resolution.
  12. a light breeze

    Pixel Art Resolution

    Sprites can have an resolution you want. Textures should be powers of two, but you can just leave blank space around the sprite to fit it on the texture. With sprites as small as 28×12, the blank space doesn't matter because you have vastly more video memory available than you'll ever need. With larger sprites, you can reduce blank space by fitting multiple sprites on a sprite sheet, where the sprite sheet has power-of-two dimensions itself.
  13. So, use template specialization instead of overloads? You can specialize functions. The following works: #include <iostream> //=== INITIAL LIBRARY CODE ===// template <typename T> void foo(T const& arg) { std::cout << "default = " << arg << std::endl; } //=== FINAL LIBRARY CODE ===// template <typename T> void bar(T const& arg) { foo(arg); } //=== USER CODE (AFTER) ===// template<> void foo<int>(int const& arg) { std::cout << "overload = " << arg << std::endl; } int main() { char c = 'c'; int i = 1; bar(c); bar(i); return EXIT_SUCCESS; }
  14. I think you're wrong about the requirement that the definition that bar must come after the specializations of CFoo, at least if bar is a template function. I tried this test program: #include <iostream> template<class T> class CFoo { public: void f() { std::cout << "default implementation" << std::endl; } }; template<class T> void bar(CFoo<T>& x) { x.f(); } template<> class CFoo<int> { public: void f() { std::cout << "specialized implementation" << std::endl; } }; int main() { CFoo<int> x; bar(x); return EXIT_SUCCESS; } It printed "specialized implementation" as expected. That's because the code for template functions is only generated at the point where the function is actually called.
  15. A lot more people than "nobody" bought your game, and $600 is a lot more than nothing, even if you did spend more than that on advertising. Here is why this matters. Suppose you could, through X amount of effort, multiply the number of people who buy your game by a factor of ten. Should you go for it? Well, that depends on how highly you value your time and effort. If X amount of effort is worth $5400 to you, then doing it would be a good idea. If that amount of effort is worth more than $5400 to you, then doing it would obviously not be a good idea. Now consider somebody who put just as much effort into the game, but only made $60. If this person puts in X amount of effort to multiply the number of people who bought his game by ten, then he would only gain $540. Meanwhile, the guy who only made $6 would only gain $54, and the poor schmuck who didn't sell a single copy of his game wouldn't gain anything at all. And yes, there are games that have actually not sold a single copy. $600 is not bad for an amateur effort made "just for fun". Most people don't make any money at all from their hobbies.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!