I'm making an multiplayer game and I bumped into a problem, I want to interpolate player position so it would not look jittery when player is having bigger ping/latency, I'm using vector2 interpolation but every single of the interpolation formula is decreasing/increasing speed in the middle/beginning/middle and I need so that interpolation speed would always be the same (so it would look like player is moving not floating)
The thing you want is the dead reckoning alghoritm which is unfortunately not supported by Libgdx by default. There are many ways to implement this basing on what kind of game you are creating.
There is no one good answer for your question but let say you are making a simple runner where players are going forward and they can jump. The naive implementation for multiplayer like this would be to change opponent's position due to notification he is sending. Now you are interpolating the position between notifications however you should rather assume that the opponent is still runing and when get notification that he jumps then correct position and perform jump an so on...
There are dozens of articles about dead reckoning in the internet. You can start with this one.
I need a bit of counseling. I´m trying to reproduce one of M.C. Escher´s models in Actionscript, but I´m not entirely sure about where to begin. Ideally, I´d want to make something from his Circle Limit series look somewhat like this: http://vimeo.com/4154382
Could anyone provide any pointers as in what approach should I take? I am not an expert coder, so anything would help.
Thanks in advance,
Garfeel M.D.
The different copies of a hyperbolic transformation are related to one another via Möbius transformations which leave the circle fixed. You can represent them as transformations
(a+bi)z + (c+di)
z |-> ----------------
(c-di)z + (a-bi)
You might want to represent the switch from circle to half plane as a Möbius transformation as well, to avoid numeric issues with simple zooming.
I have tools available to make hyperbolic ornaments from Escher ornaments, and zoom into them in real time. But Escher isn't public domain yet, and in my experience the Escher foundation is less than enthusiastic in granting permission for derived works. So if you get ther OK, or decide on some other artist (possibly starting from a Euclidean ornament), feel free to contact me by e-mail to discuss this further.
I recently was a jury member foir an ornament competition where some submissions were hyperbolized from Euclidean drawings. Gaining permissions for those would likely be easier than from the Escher foundation.
AS3.0 newbie here.
My goal: To create a side-scrolling motocross game (horizontal - already have terms on side scrolling methodology).
The bike - should react to jumps, etc.
Wheels need to turn when gas is pressed, etc (is this a basic animation on keyboard events, or is it actually what 'drives' the machine??)
The rider - should hang on to bike, lean forward, backward, etc.
My question lies within where should be the best place to start? I know this isn't going to happen over night, and my primary focus is on the bike & suspension & rider physics (making sure the suspension/bike/rider react correctly to bumps).
The end result (someday) will be something similar to:
http://www.youtube.com/watch?v=mpR0wbE_6Qs
Kind of an abstract question, but any help is greatly appreciated.
Thank you
There are a handful of resources for Flash game development out there,
http://www.seinia.com/ teaches some useful basics.
Adobe has a good list of some engines as well: http://www.adobe.com/devnet/games/gaming_engines.html
I would definitely check out Box2D and Fixel as they are pretty slick.
There is a similar topic with a few good suggestions for side scrolling physics games: Scrolling the 2d world with physics
while playing to this game I wondered how an AI controlling either the detectives either the criminal could work.
For lazy people the aim of the game is simple:
the board game is an undirected graphs that has 4 kinds of edges (that can also overlap for same pair or vertices), each kind is a type of transport that requires a specific kind of ticket
detectives have a bunch of tickets to move around this graph, one move per turn (which means from a node to another node). The criminal can do the same set of moves (plus 3 exclusive paths) but with no limits on tickes
the criminal is usually hidden to detectives but it has to show up himself in 5 specific turns (and then hide again)
if detectives are able to catch him (one of them must occupy the same cell of the criminal) before 24 moves then they win, otherwise the criminal wins
the criminal has to show which ticket he uses each turn but he also has 1 black ticket per detective (let's assume 5) that can be used to vanify this thing
the criminal also has two 2x tickets that allow him to use two tickets (and so two movements) in the same turn
I can think effectively about an AI for the criminal that it would be just a minmax tree that tries to choose movements that maximize the number of moves needed by detectives to reach him (it seems to be a good metric) but I cannot think anything enough cool for detectives which should cooperate and try to guess where the criminal can be by looking at tickets it uses.
It's just for fun but do you now any cool ideas to work out something quite clever?
You've asked how to model this, not how to solve this efficiently:
It can be easily modeled as a partially observable markov decision process (wiki link). This works both for the detectives and the criminal. POMDPs are a very generic model.
I love this game, and I think for the detectives you want to model the probability that the criminal is at each location. Every once in a while you know the exact position of the criminal, and then you can take into account the following moves he makes to determine which spots he could possibly be at.
Once you have this, I'm not quite sure how to optimize the detectives moves. You can move the detectives to reduce the set of possibilities, effectively corraling the criminal. But I'm sure there is also some higher level strategy needed surrounding the tickets and not running out of them.
I'd imagine some kind of a monte carlo implementation would be an excellent candidate for this, ie. simulating thousands of combinations and choosing the one that ends with the best result most of the time. Since the criminal has to be visible for 5 turns, the branching factor should stay well under control, although MC has also been shown to be a very good technique in games of high branching factor, ie. Go.
In order to get teamwork going between the detectives you need to model them as a team rather than as individuals. Minimax is still a good way to go but (sadly) your branching factor is going to soar.
Instead of stepping through all the detectives making what appears to be the best for each instead for your team of detectives you work out each permutation of moves they could make. If teamwork helps in this game then the minimax will favour the permutations in which the detectives are working together.
I'm not sure if it will be practical, 5 detectives for 24 ply might be too much work but it'd be fun to try and that's the point right?
I would like to know this to understand why some games like Mario is still playing today and because no other. This is to implement in future game projects.
What are the factors most important to developing a game?
Gameplay or Graphics? Both?
EDIT:
It's Possible combine these two?
Gameplay, combined with the often-missed concept of ease of play. If I can't pick up a game and make progress in a couple minutes I probably won't go back to it after I've been away. It's just disheartening to have to relearn how to play a game. Mario tended to have simple interfaces, one or two commands only, which makes it easy to come back to. Comes back to this: http://xkcd.com/484/
Gameplay. So many modern games just seem to spend their entire budget on developing an incredible graphics engine and forget to include plot / interesting gameplay. One example is Doom 3. It's kind of interesting, and spooky to play, but it's SO REPETITIVE. Tunnel after dark, deserted tunnel... compare it to Doom 2 which had a plethora of different types of missions. Doom 2 had crap graphics, but there's a reason people keep playing it.
That being said, a big reason people play old games is from nostalgic value. The gameplay might not be particularly excellent, but it does bring back memories, so that automatically adds value to the game.
Graphics are, of course, also important... you can't get away with 16-color 2D sprites anymore (or at least, not as easily). Rather than spend the entire budget on graphics, though, look into an OK graphics engine, and spend some time making the game:
Fun to play.
Have replay value.
Easy to pick up.
The most important is that you ENTERTAIN your target users.
Some users want gameplay. Some users are wow-ed by just graphics.
The think the real importance is addictiveness, which, of course, is rather hard to program in. However, I think the key to that is a task which is very easy to "almost" achieve. It's the "I'm almost there; just one more try" effect that keep most people coming back.
This might be a bit old-school for most peoples liking, but I'd have to say gameplay.
Put it this way, I still find myself running old SNES games I loved on an emulator these days, but I can't see myself playing a game that had great graphics but rubbish gameplay after it has had its time.
Both are preferable, but it's gameplay that generates the classics of each era.
Game play is what gets you hooked, especially if there's a very low learning curve such as pacman or breakout. Graphics is what sucks you into downloading / buying a game. Sometimes nice graphics is a demo don't necessarily translate to a nice game. I've seen so many games that have beautiful front screens, background, etc. but the actual game graphics such as characters, objects, etc. suck. Generally it's a good idea to think about your game design to make it easy to understand and play initially, then it gets harder with later levels by adding bosses, threats, bonuses, increasing speed, etc. Then fine tune how the game looks with snazzy graphics.
I would say it depends. For indie games, gameplay is the most important because that's what will keep your players entertained. obviously for big budget games, you need both to be successful. But as long as your graphics are clean and neat, players shouldn't complaint too much.
Distinguish between designing the game and programming the game. For a programmer, a game is simply an application, no different from any other kind of software. Game design is a whole 'nother beast of a different color :) If you can program well, you can program a game well.
Good game designers are the same kind of rare creative as good storytellers--who aren't necessarily always good writers.
Gameplay in terms of being easy to get the basics but difficult to master would be one factor, for sure. For example look at Diablo II for something with some nice basic elements but also some elements to keep playing for a long long time, like horadic cube recipes for example.
Replayability is another factor. How much does the game change if I pick a different starting character, assuming a game with this style like an action RPG or FPS or beat-em-up(Street Fighter II)? Is the game enjoyable from different views? How good is the AI if I have computer opponents in a real-time strategy game and how many settings are there?
Graphics can be a nice complement but just because a game looks nice doesn't mean I'll spend hundreds of hours on it. Titan Quest would be a nice example of taking the Diablo II style and adding some eye candy that makes for a nice game.
Nostalgia is a big factor in why some old games are still played like the old Super Mario games. The memories of playing those old games and seeing how cool it was to get to the next level can be why some will go back again and again. It is the reason why I still play my SNES at times.