I'll just add my voice to this that "Algorithm" to some people might mean the idea (shorn of any specific programming language) of the process you're attempting[1]. Others will use "Algorithm" as exactly the same as a function, procedure or even a one-line operation just contained within the code, and thus actual lines of that code.
So "The ability to create algorithms" might mean as little as "know what it is you want the programme to do, which must then be followed up by the ability to make the programming environment within which you're working bend to your will and do that task.
Insofar as it is insufficient to say "I want this programme to pin-point a human face in an image", because unless there's a "getHumanFaceLocation(image:imageType):selectionType" sort of function, that's not really good enough. But if you start with some more of an idea[2], and perhaps drill down into that idea to work out that you will require a more narrowly defined algorithm[3], then you're likely to be able to combine that with your 'raw programming knowledge' to create a procedure or function using the commands you have available to accomplish the desired algorithm.
On the other hand, the author of the phrase might be talking about how to group the commands into "write-once, use on demand" code structures (procedures, functions or just blocks of code within a loop or decision tree). i.e. getting that 'raw programming language' in the first place.
I err towards the former, I suppose, because I would say that the path towards being a good programmer cannot be 100% knowledge of the commands but 0% understanding of the task and thus no possibility of working out how to put them together to accomplish your purpose. Whereas it may be possible (if still vastly ill-advised) to start off with a perfect understanding of what needs accomplishing, and by what method, and then start bashing through the reference books, etc, in order to work out what code has to be jammed together in what format in order to get the whole concept implemented.
In reality, of course, knowing that something is possible in code vastly helps when it comes to putting the idea together. The fact that you can perhaps generate an arbitrary number of registers capable of keeping count of the number of occurrences of arbitrary words, in a certain programming language, simplifies the job of finding the most common word (or words) in a given sample of text. Without that apparent ability, you may resort to something more inefficient[4][5] than you need have.
(I suppose a much glibber answer could have been "Be the code!", and perhaps it might be less potentially contentious than what I just wrote, but I'm sure it wouldn't have been any more helpful...)
To reference your ninjaed query about the lack of "problems in a video game", there are always problems. Everything from how to (frexample) represent a picture of your hero, his various foes and the environment in which they are battling upon the screen, through to how to ensure that if the hero/foes land on certain parts of the environment they will die and also about how to work out what happens to each if the hero and a foe interact with each other. Does the hero fire bullets? How do you understand that the player wants to fire bullets (grab keyboard/mouse/other input, and check to see if there are bullets to fire, and whether or not it's too soon to fire a bullet so soon after a previous one)? How do you understand that the foe wants to fire grenades (check foe-character's profile to see whether they throw grenades regardless, or do they throw when they work out (by some manner or other) that the hero is within range, plus check that they've not run out of grenades or it's (again) not too soon since the last grenade throw)? When a bullet hits a foe, what should happen? When a grenade hits the hero, what should happen? What about if a bullet/grenade somehow manages to hit the hero/a foe (however unlikely the former is, or the latter if there's not multiple foes)? What about a bullet hitting a grenade, or a grenade blast overtaking a bullet? How do these circumstances get detected, and how might that affect the way the entities work (die, be injured, slow down, or have a more "beaten up" image be used instead of the original one, which you must now make sure is used to represent the entity concerned until something else changes this (healing, more damage, death/evaporation/running-off-screen/whatever), and might this make the entity change tactics)?
Stuff... The above describes a very simple scenario that might resonate as describing any one of a number of games that have been written. I could as easily have described a racing game where the problem was how to generate (or retrieve from some pre-generated storage or other) the twists and turns of the track, and display all aspects of the track environment, but again work out what the user wants the car to do, and if it can do that at this time, plus if the car is in a valid bit of track, in the rough and thus slow, has hit a barrier, is over a power-up... never mind the question of any opponents (how are they programmed to behave... do they have Artificial Stupidity to cause them to make mistakes, or are they 'perfect', just handicapped in speed so that a decent human driver can beat them?), etc, etc...
But as to whether each and (deconstructed) every point I've made should be considered equivalent to "An algorithm" is another question. You may find you need to implement each question using a combination of 'simpler' algorithms, or that the algorithm to check to see if the player's character/car is in a valid position on the screen can also be used to check whether the foes/competitive-cars are in a valid position on the screen. Whether the method to detriment the health/speed/whatever of the out-of-bounds entity is part of the same algorithm, a common second algorithm or one of various party-specific additional algorithms is also easy to argue about. It's all probably a lot of simple algorithms which are in turn called by a few less simple algorithms that have a choice within them of which of the simpler algorithms are called, which in turn are grouped by small subset of higher algorithms, which will even boil down to one "master control" algorithm. At least that's how it will work procedurally (although in an object orientated environment, the "master control" one is as likely the programming language's own core controlling code which manages the real-time switching and prioritising between the various 'objects' you've designed to work on a semi-independent basis... that's an argument and a half... but you get the idea). And, as I said, some people would equate algorithms to procedures. And others might go so far as to accept that 'algorithm' is to 'theory' as 'procedure' is to 'practice'.
Double-ninjaed response about elegance. Perhaps one solution would be to have a number of 'floating' spawning points which get randomly placed prior to the wall-emplacement, but as walls get computed they check against the limited number of spawning points and if there's a collision the SP gets moved to one side of the wall. Unless the wall gets expanded, or T-junctioned with another new bit of wall, the SP won't need to move again. (Or could move, randomly, in-between the ticks when everything else moved, but only into adjacent non-wall spaces. Would produce a more random spawning, and could be tuned to ensure that the points don't get close enough to your 'hero' so as to land on top of them, or lets you ensure a more 'realistic' distribution of newly spawning 'enemy' units.
But I don't know enough about your design to know if this would be so necessary to do, or if the problem of spawning wouldn't be so trivial as to need such advance insight. Get random point, check to see if too close to something (or on top of wall) and if so, generate another random point. Or screen-slice to prevent "too close" incidents and then allow any wall-incidents to try the spots on the screen adjacent to the wall in each cardinal direction (randomly) until one without a wall is found. Or "drunkard's walk" it around until it 'falls off' a wall and into an acceptable space. Or. Or. Or... Loads of ways. As I said, don't know enough (anything!) about your game, but you should have an idea what would work best.
At last, not further ninjaed. Sorry, this is probably now a TL;DR; but hopefully (we shall see) it shall at least post.
[1] e.g. "Start a count at zero. Look at the first item in a list. If that item is a badger, then stop looking and inform the user of the current count. But, otherwise, if that item is the name of a fruit increase the count by one and look at the next item, before going back to the badger-test point again", for a completely spurious example that has several in-built problems.
[2] Like "Look for localised maxima and minima in the image array. For all maxima/minima, create associations with neighbouring maxima/minima to narrow down to one's with <some relationship or other indicative of eyes>. Repeat with all possible pairings to assess association with further relationship with further features with <some mouth-like indication>, rejecting all sets without that relationship. Repeat with all remaining sets to identify some feature with <nose-like indication> within the bounds of the points defining the existing set of features. <etc>", as a completely and utterly bastardised and abbreviated concept of one possible facial-recognition algorithm that couldn't detect faces in profile anyway, but you get the idea.
[3] Something along the lines of getMaximaOrMinima, at the very least, in the above example, and how you do the mouth and nose might or might not be a mere extension of the same, but probably not.
[4] "Set a maximum-count register to zero. Set a frequentest-word register to blank. Go to first word. Make note of word. Set counter to one. Check every word following this and if that word is the noted one, increment the counter. At end, check if counter is greater than maximum-count. If it is, set maximum-count register to the value in the counter, and at the same time set frequentest-word register to the noted word. Go to word after the one just looked at and return to 'Make not of word' part, unless there is no next word, in which case report the maximum-count value and the frequentest-word word." (Which could be slightly optimised by if the noted word is equal to the maximum-count word, then go the next word and forget counting, you'll only be counting one less than last time.)
[5] Compare that to the possible "For each word, if there is no counter relating to that word, set the counter to one, otherwise set the existing counter to one more than it is now. When having no more words, sort the list of words that have been counted by [ascending/descending] final count and report the [last/first] counter's word. If the [next|previous] listed counter has the same value, report that word also, and repeat this line again until it isn't." as another slightly abbreviated solution, but one which (assuming the possibility of arbitrary counters and a monolithic sort function that can work on such counters) would be a far better algorithm. Even if you have to use Levi's sorting algorithms as well (or, simpler, do a single-pass "go through counters, recording any increasingly large counter values and the counter", which you could modify to similarly keep score of tied 'frequentest' values), it is still a quicker single-pass process. And even if the language doesn't have a core ability to keep so many counters, there may be ways to implement that, if you know what 'the code' is capable.
Author
Topic: Programming Algorithms (Read 2052 times)