One pet peeve I have with a lot of older rock music records from the 60's and 70's
is they sometimes are slightly of of tune with the standard a440 reference pitch, so playing along on my guitar sounds bad. Right now I manually adjust the pitch of the track by ear in Audacity, but this often takes some time. I was hoping there was something out there that could detect the frequency of the first few notes of a music file, analyze that and see how far it is from any standard A440 note, and then you could use that number to determine how much you needed to make the track sharp or flat to match A440 tuning.
Is it possible to create an app that automatically retunes slightly out-of-tune music to be A440 with Javascript?
Yes. Check out this pitch detection demo by Chris Wilson.
There are some big caveats though, and they don't really have anything to do with JavaScript.
Voice Selection
What instruments do you care about? Obviously wideband stuff like percussion is atonal... but it's still going to turn up in your audio, and will have a pitch. How about the difference between a voice and wind instruments? A lot of vocalists will go off pitch intentionally. You will need to use bandpass fliters to get the range you care about, at a minimum.
Original Intonation
What about the instruments being in tune in the first place? "Another one bites the dust" comes to mind as a rock record from the 70s that starts off terribly out of tune... and maybe intentionally.
Pyscoacoustics and Harmonics
Sometimes we hear things that aren't really there. If I play a trombone down a scale, to the very bottom of its range, it will actually stop producing a fundamental... yet because I was playing a familiar scale downward, us humans will still perceive one. This might not throw off your detection by a lot, but it will somewhat, particularly on those atonal-but-not-really percussion instruments.
In summary, this is possible but it's going to be a lot of work. Please come back and post a link once you've done this!
Related
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 can see how this might not be a good enough question but I have just embarked on a journey to build the first decent Game Engine for HTML5 canvas that is cross browser and most of all fast. The only problem is I am very new to game design and don't know many tricks of the trade that will help me.
The game I am currently implementing for which the engine will be taken out of is a tile based 2D platformer with MANY tiles (around 3500). I'll start with some tips that I've thus far learnt.
Redraw Regions - only redraw areas that change
Avoid unnecessary function calls (Firefox does not like too many of them)
Use the DOM if you can
Chunk tiles together for quicker access
Other things I am looking for are things like Terrain Generation, Lighting in 2D, Maps, quick server communication. If this is too vague, I will try and close it. Just want to know game design better.
Links/resources would be good. Especially for physics or important maths.
Only draw stuff that's visible, that means only draw the tiles etc. that are currently on the screen. For tiles that's fairly easy, if you got lots of entities you may either want to use a sliding window to keep a list of screen local objects or use such a thing like a quadtree.
Since there's no easy/fast way to copy one canvas to another, redrawing regions is really complicated, since you can't keep a buffered state of (for example) the background if it hasn't changed. So keeping a list of "dirty rectangles" will be a computational overhead for sure.
The whole topic is very broad, even handling the FPS rate can be quite difficult, this question contains some good links and answers on that topic:
https://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step
You've also mentioned server communication, if you want to do some multiplayer you'll have to care about even more stuff, you can't trust the client, need to worry about bandwidth, synchronization issues, interpolation on the client etc.
I've done some rather simple 2D games in the past, most of them are not in JavaScript but they should give you some hints:
http://github.com/BonsaiDen/Norum
(Platformer engine demo in C, camera zones, moving platforms)
http://github.com/BonsaiDen/Tuff
(2D Platformer in Java, got never finished, powerups and some cool stuff)
http://github.com/BonsaiDen/NodeGame-Shooter
(2D multiplayer space shooter written in JS, using Node.js for the server and WebSockets for communication)
For some final words I'd say that you should start small, like for example just do a scrolling tile map first, then add a player, then rewrite the whole thing. You want write the perfect engine just from scratch it will take many iterations until you find out all the quirks and tricks.
If you want more precise answers you should open questions on the single components you run into troubles with.
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.
Does anyone have any good references for equations which can be implemented relatively easily for how to compute the transfer of angular momentum between two rigid bodies?
I've been searching for this sort of thing for a while, and I haven't found any particularly comprehensible explanations of the problem.
To be precise, the question comes about as this; two rigid bodies are moving on a frictionless (well, nearly) surface; think of it as air hockey. The two rigid bodies come into contact, and then move away. Now, without considering angular momentum, the equations are relatively simple; the problem becomes, what happens with the transfer of angular momentum between the bodies?
As an example, assume the two bodies have no angular momentum whatsoever; they're not rotating. When they interact at an oblique angle (vector of travel does not align with the line of their centers of mass), obviously a certain amount of their momentum gets transferred into angular momentum (i.e. they each get a certain amount of spin), but how much and what are the equations for such?
This can probably be solved by using a many-body rigid system to calculate, but I want to get a much more optimized calculation going, so I can calculate this stuff in real-time. Does anyone have any ideas on the equations, or pointers to open-source implementations of these calculations for inclusion in a project? To be precise, I need this to be a rather well-optimized calculation, because of the number of interactions that need to be simulated within a single "tick" of the simulation.
Edit: Okay, it looks like there's not a lot of precise information about this topic out there. And I find the "Physics for Programmers" type of books to be a bit too... dumbed down to really get; I don't want code implementation of an algorithm; I want to figure out (or at least have sketched out for me) the algorithm. Only in that way can I properly optimize it for my needs. Does anyone have any mathematic references on this sort of topic?
If you're interested in rotating non-spherical bodies then http://www.myphysicslab.com/collision.html shows how to do it. The asymmetry of the bodies means that the normal contact force during the collision can create a torque about their respective CGs, and thus cause the bodies to start spinning.
In the case of a billiard ball or air hockey puck, things are a bit more subtle. Since the body is spherical/circular, the normal force is always right through the CG, so there's no torque. However, the normal force is not the only force. There's also a friction force that is tangential to the contact normal which will create a torque about the CG. The magnitude of the friction force is proportional to the normal force and the coefficient of friction, and opposite the direction of relative motion. Its direction is opposing the relative motion of the objects at their contact point.
Well, my favorite physics book is Halliday and Resnick. I never ever feel like that book is dumbing down anything for me (the dumb is inside the skull, not on the page...).
If you set up a thought problem, you can start to get a feeling for how this would play out.
Imagine that your two rigid air hockey pucks are frictionless on the bottom but have a maximal coefficient of friction around the edges. Clearly, if the two pucks head towards each other with identical kinetic energy, they will collide perfectly elastically and head back in opposite directions.
However, if their centers are offset by 2*radius - epsilon, they'll just barely touch at one point on the perimeter. If they had an incredibly high coefficient of friction around the edge, you can imagine that all of their energy would be transferred into rotation. There would have to be a separation after the impact, of course, or they'd immediately stop their own rotations as they stuck together.
So, if you're just looking for something plausible and interesting looking (ala game physics), I'd say that you could normalize the coefficient of friction to account for the tiny contact area between the two bodies (pick something that looks interesting) and use the sin of the angle between the path of the bodies and the impact point. Straight on, you'd get a bounce, 45 degrees would give you bounce and spin, 90 degrees offset would give you maximal spin and least bounce.
Obviously, none of the above is an accurate simulation. It should be a simple enough framework to cause interesting behaviors to happen, though.
EDIT: Okay, I came up with another interesting example that is perhaps more telling.
Imagine a single disk (as above) moving towards a motionless, rigid, near one-dimensional pin tip that provides the previous high friction but low stickiness. If the disk passes at a distance that it just kisses the edge, you can imagine that a fraction of its linear energy will be converted to rotational energy.
However, one thing you know for certain is that there is a maximum rotational energy after this touch: the disk cannot end up spinning at such a speed that it's outer edge is moving at a speed higher than the original linear speed. So, if the disk was moving at one meter per second, it can't end up in a situation where its outer edge is moving at more than one meter per second.
So, now that we have a long essay, there are a few straightforward concepts that should aid intuition:
The sine of the angle of the impact will affect the resulting rotation.
The linear energy will determine the maximum possible rotational energy.
A single parameter can simulate the relevant coefficients of friction to the point of being interesting to look at in simulation.
You should have a look at Physics for Game Developers - it's hard to go wrong with an O'Reilly book.
Unless you have an excellent reason for reinventing the wheel,
I'd suggest taking a good look at the source code of some open source physics engines, like Open Dynamics Engine or Bullet. Efficient algorithms in this area are an artform, and the best implementations no doubt are found in the wild, in throroughly peer-reviewed projects like these.
Please have a look at this references!
If you want to go really into Mecanics, this is the way to go, and its the correct and mathematically proper way!
Glocker Ch., Set-Valued Force Laws: Dynamics of Non-Smooth Systems. Lecture Notes in Applied Mechanics 1, Springer Verlag, Berlin, Heidelberg 2001, 222 pages. PDF (Contents, 149 kB)
Pfeiffer F., Glocker Ch., Multibody Dynamics with Unilateral Contacts. JohnWiley & Sons, New York 1996, 317 pages. PDF (Contents, 398 kB)
Glocker Ch., Dynamik von Starrkörpersystemen mit Reibung und Stößen. VDI-Fortschrittberichte Mechanik/Bruchmechanik, Reihe 18, Nr. 182, VDI-Verlag, Düsseldorf, 1995, 220 pages. PDF (4094 kB)