the programmer seems to think there should be a more efficient way to detect matches.
Most likely, this is true.
Most likely, this does not matter at all.
Unless there are cases which the code does not handle correctly, or if the code's efficiency is a real (measurable) problem, notions like "it can be done better" should be filed away for the sequel. Your goal is to finish and ship the game, not to rewrite pieces of code until the end of time.
As is often the case, perfect is the enemy of good [enough].
EDIT: If there are real problems (measurable or use cases where it fails), posting details on those specific areas would be required for further feedback.
EDIT 2: Ninja skills are definitely improving today.
You say you've already got a demo up and running. I would assume this includes some sort of code for checking matches.
Is the code you have already not good enough? If not, why not?
If you don't have any code for checking matches yet, what have you tried?
It's somewhat tricky to give specifics without more details (especially if you have something working but it's not good enough for you, for some reason), but more advice should be possible, especially given the answers to those questions.
OpenGL is still not a game engine (as I mentioned the last time you referred to it as such). It is still a cross-language, multi-platform rendering API (specification).
"Game engine" in the context of the original post is a term used mainly for more complete packages, usually something like Unity3D, Unreal Engine, etc. It can also refer to the parts of a studio's code base that are reused for multiple games.
If the best thing about Delphi is "you can create the same games as when using other languages, but it might be a lot harder and take a lot more time", then I would find it foolish to choose it over other, more pragmatic solutions. The exception would be if one wanted to do so for learning purposes or because one found it fun/interesting or similar.
If I had a project in mind*, I would want to choose a language/framework/engine that I thought best suited the project/goal. As someone who has never used Delphi, I don't see any particular reasons why I would want to change that, aside from the catch-all notion that being knowing multiple languages is usually a boon.
If I were a Delphi expert, I would probably be more inclined to choose Delphi, assuming no other languages/frameworks/engines were better suited, given my other knowledge in this hypothetical scenario. That said, I personally see no reason for choosing learning Delphi as opposed to e.g. C# or Python.
That's not to say Delphi users can't or don't create awesome things. I'm sure they can and do, but for me personally to be interested, there would have to be a clear benefit to it, which isn't something that you've conveyed so far in any of the posts/threads I've seen you make.
*And I do. I don't see a reason why I should use Delphi for it, so I won't.
Posted by Lactose!
on 19 September 2014 - 03:07 PM
If you enter 100, you will get to how_much = int(choice).
That means how_much is equal to 100.
In the next if statement, we check if how_much is less than 50. 100 is NOT less than 50, so we do not enter the if part of the if statment.
Instead, we enter the else part of the if statement.
Inside the "else" part the dead("You greedy bastard!") code run.
The dead code will print the text you see.
Like I've done before, I would suggest you slow down. You seem to be going too fast. You might be going through the exercises quickly, but if you don't understand them, you won't learn much.
The questions you're asking indicate you're missing some fundamental knowledge. I would urge you to back to earlier lessons, and not progress until you feel you understand basically every line in the lessons you're working on. If parts are unclear, I'm sure people will help you. That said, I would recommend you ask more specific questions.
Instead of "help what does this do" and post all the code for a lesson.