lawnjelly

Members
  • Content count

    238
  • Joined

  • Last visited

  • Days Won

    1

lawnjelly last won the day on July 25

lawnjelly had the most liked content!

Community Reputation

1261 Excellent

1 Follower

About lawnjelly

  • Rank
    Member

Personal Information

  • Interests
    |programmer|
  1. Distributing a game with stolen resources

    IANAL, but as I understand it: At the far end of the spectrum, if you make a fan game with ripped off assets, compile it without any information identifying you, upload it on a VPN / in a coffee shop, and don't use your name, it becomes very difficult for anyone to even identify who it is who is doing the infringing (that's assuming you don't go mouthing off on forums about it, logging in from your home IP etc). Think of it like committing a murder. On the other hand, the moment you start trying to make money off such an enterprise (or even advertise), it becomes much harder, because there is usually a trail leading to the beneficiary. Added to this, once informed, legit 'publishers' / markets / payment processors won't usually want to touch stuff like this because of legal risks to themselves. There is also the issue that in some jurisdictions they don't have the same IP laws as 'insert your country of origin'. Some are very lax about it, and won't give a hoot (compare say, US and China). So there can be international wranglings involved .. where is the game distributed from / to, where are the servers, payment processors? Where is the development company based (developers in Norway, Vietnam, China provide work for a company in British Virgin Islands, selling to Asia, through a Chinese market using a European payment processor and the copyright holder is from the US, whose laws apply and where do you take them to court?) As you can guess it is also a potential nightmare for copyright holders to take action, it is easier for big companies with legal departments to protect their IP than small players. Aside from deliberately infringing, there can also be accidental problems, which can affect even legit developers. If you contract out some artwork from a guy in China and he assures you (and signs paperwork) that it is all legit, and you later find he's ripped off someone else, you can still get sued. So as a developer you need to be super careful where you get all your assets, credit them if necessary, operate as some kind of limited liability company, and still get lots of insurance in case the worst happens (not to mention patent trolls etc).
  2. C# How to reduce data sizes?

    Furthering what Kylotan said about only sending the information needed rather than all the data: If you for some reason want a million zombies on a bunch of clients and a server, I'm guessing the zombies are AI. In which case, if you calculate the exact same numerical zombie AI simulation etc on each client, in theory you only need to send the things that might affect the zombie simulation (i.e. the real players and their inputs). This is a similarish idea to client side prediction, and afaik is useful for RTS games. Presumably you have to be very careful about your simulation to make sure it runs identical on all machines. If you really do have lots (hoping not millions) of players, then usually each client doesn't need to know about them all, only the ones within visible range. An authoritative server might keep track of all the players, but it only needs to send a subset of these to each client. And of course in the other direction the input only comes from one player per client.
  3. Explorer Game

    I'm back working on this after a couple of years off.. it is a little(!) game for me to learn Android (although most work has been on the PC build so far). I've been attempting to learn blender as well as doing the coding.
  4. Freakman 1.2

    I just tried it on my tablet, is well executed, well done!
  5. How I halved apk size

    All the time, saving the difference between values rather than an absolute value is one of the most fundamental compression methods. I've used in it images, video, audio, animation data, both as part of my own compression, or as a pre-process before applying other compression (like png). And nearly all compression formats you use everyday will use the idea.
  6. How I halved apk size

    Always interesting to hear experiences! I guess the runtime footprint and the APK size are quite interrelated, did you have any problems on devices from runtime memory use which encouraged you to load resources only when required? Or was it more a pre-emptive measure to prevent problems on smaller devices (difficult to test there are so many!)? Another good trick with the multiple similar images is to do a 'diff' on them, and then instead of saving the whole image each time, just save the difference. If a lot of the values are the same, the diff will be zero and this will compress well.
  7. Just a little progress video. As well as getting the scripting working a bit more, I've been placing villages and naming map areas. The area names are generated by putting together random chosen syllables. Morphing For variation with the natives they now use realtime bones like the player, and there is a morphing system so you can have fat / thin / muscular natives etc (I only have created fat and thin so far to test, but it works fine). UV Maps As well as the morphing variation, each native has a uv map so it can use different textures for different uv islands (parts of the body). This will allow e.g. wearing different clothing, different faces, jewellry etc. At the moment I've just just put some red green and blue and white over the different areas as placeholder until I create more textures. The conversations are all random from script just for a test .. choosing random animals and people to make random snippets of talk. I will probably make this more purposeful, giving each villager names and relations so they can further the plot. Next Next up I am putting in attachments so they can carry spears etc, and the player can carry sword. Also I may be able to have a canoe as an attachment off the root nodes so they can canoe on the lakes. I will also add female natives. I could do them as morphs, but I think it will be easier for texturing etc to have a different female model.
  8. Pitfalls of pixels as unit in game

    Yes, on our 8/16/32/64 bit computers it makes far more sense to divide a pixel into 256 then say, 100, because you can use bitshifts, bitmasks etc. The fixed point can refer to the number of bits given to the fraction and the number to the whole number, instead of referring to the position of a decimal point. http://x86asm.net/articles/fixed-point-arithmetic-and-tricks/
  9. Pitfalls of pixels as unit in game

    Also consider fixed point (you can for example divide a pixel into 256 units). If you are using pixel perfect sprites there is more of a reason to use some kind of pixel unit, whereas with pure 3d there isn't such a concept as a pixel, so the pixel may not make sense, but you still may choose to use integers. There are benefits to both floats and ints. Although floats are often seen as the 'default choice' these days, integers are good for consistent behaviour, compression, packing, some people use them for units on large scale maps.
  10. The million monkeys approach.

    There is a saying 'too many cooks spoil the broth', and it is quite fitting here. As said a small number of experienced / skilled developers can often achieve a far better result far faster than a large number of intermediate level developers, let alone beginners. The situation is kind of similar to the problems with multithreading. Some jobs are inherently scaleable. If you need potatoes harvesting from a field, you can add workers, and that field will be harvested faster almost linearly as you add the workers. Other jobs are very difficult to scale, particularly programming, as the parts need to work coherently together, and there is a big danger of everyone treading on each other's toes. A large part of software engineering is trying to make modules as self-contained and independent as possible, but this is not a magic bullet and there are limits to scalability. Artwork is more likely to be scalable imo, however, skill level is very important for artists too, and there is need for art direction and a coherent vision. An artist needs to be trained to the level so that they can produce assets of high enough quality, both technically and artistically. Beginners are unlikely to be able to produce anything usable. The job potentially easiest to scale imo would be content creation in terms of simple map editing, asset placement and simple scripting. Providing the tools are idiot proof enough. But this again would depend on careful management / direction, and quality control. As Bregma points out the show stopper in terms of anything commercial may well be intellectual property / legal issues. It may well be easier to invest in procedural map generation tools / helpers than deal with the myriad of issues of employing / directing large numbers of people.
  11. Edit .. Just had closer look, it seems your loop is doing roughly the right kind of thing. I think we are at cross purposes, that's all, I was referring to the update / render in your game objects (player monsters etc) not to the function that gets called by Slick2D.
  12. What game types require zero animation

    Spaceship / airplanes / vehicles you might be able to get away without animations, just particle effects.
  13. I don't really know that much java, or Slick2D, but it looks like you are calling the update and render functions yourself for players / monsters etc in GameState.java (rather than them being automagically called). In which case it would seem you can call pretty much whatever function you want, e.g. MyUpdate(), MyRender(float f), unless there's some particular reason it has to be the exact overridden method they suggest. Sorry, nothing off top of my head for the collision, but google will find lots of articles, just search for things like 'line segment, circle, collision'.
  14. I had a (very) quick look at the source. One thing I notice is you are still propagating your 'time' through the update. You shouldn't need to to do this, as with a fixed timestep everything is based on a fixed 'tick' unit of time. Personally in the more rare circumstances I need to access gametime (for timers etc) I access them through a global mechanism (beware there are lots of gotchas with globals, and some people refuse to use them, but imo there are a few situations where they are a good solution imo). You can pass a fraction through your render function though, for a fraction through the tick, store the previous and current positions / rotations etc then interpolate on the render. To debug stuff like this, first call is to decrease your tick rate, turn off your interpolation and then you may be able to literally 'see' what is going on. If you down the tick rate to say 2 ticks a second, with no interpolation, the game will move slowly, and you can see whether particles are entering the collision radius and not colliding. Bear in mind also there may also be 'ordering' effects with the collisions, from looking at your code. E.g. are you moving the projectiles and colliding checking them before moving the monster on that tick? So what you see may not be exactly what is going on under the hood, unless you move both, *then* do the collision check (i.e. both the projectile *and* the monster may be moving). You may be able to simply solve this situation by giving the projectile volume and 'pushing' out the collision radius of the monster. But personally I'd probably have a lower tick rate than 60 per second .. often 10-20 ticks is enough with interpolation, and put in some kind of hierarchical collision system with a line segment / circle check as vinterberg suggests, instead of just point in circle. As an aside, another option with fixed timestep is you can run multiple schemes at once : game logic at say 10 ticks per sec, physics at 60 ticks per second, which can be a good option in games which demand fast physics.
  15. Fix your timestep. You may still end up wanting to do swept checks for certain fast moving things, but fixing your timestep is fundamental to getting any kind of repeatable behaviour.