What's the best way to code an app in which objects must interact with each other in complicated ways? - oop

I am interested in a general approach, not a particular library or framework.
I am trying to avoid spaghetti-code-ish conditionals when possible. It may be that I'm thinking of these apps in totally the wrong way, but I can't seem to find anything online that's helpful.
The problems arise when there are multiple sorts of states that all affect each other. Here's an example:
Image a Person that has these abilities:
Walk.
Run.
Sit.
I make a command pattern with Walk.execute(), Run.execute() and Sit.execute(). These commands are triggered by user input or whatever. What's great about this, of course, is that if running needs to be debugged or amended, it's easy to know where to look in the code base.
Now I'm asked to add a dog. The dog can...
Walk.
Run.
Sleep.
If the person is walking and the dog is running, the dog (being on a leash) will run slower than he will if he's running on his own. And if the dog is sleeping, the person will sit for longer than he normally does. In other words, the dog and the person are affected by each other.
Then I'm asked to add a refrigerator with food in it. The fridge affects the dog and person, because the amount they eat affects their energy for running, etc.
I am continually asked to tweak this system. "Please make the dog run sleep more, but only if he and the person have been walking and the fridge is almost empty." And then, later: "Please change it so that the amount the person has run has walked has no affect on the dog's sleep."
I want to avoid packing DogSleep with tons of conditionals, and I also want to avoid DogSleepIfDogAndManHaveBeenWalkingAndFridgeIsAlmostEmpty. That's not scalable.
At any time, we might want to rip the fridge out of the system. Or we might want to change it in some fundamental or subtle ways.
A more real-life example is a media player that can be displayed as a compact player, an expanded player (say one that takes up half of your screen) and a full-screen player. So there are those three screen states.
Meanwhile, the player could be displaying an image, video or text.
If it's displaying a video, that video could be playing, paused, completed, etc.
The state of the video affects the way the different screen states render. The type of media also affects the rendering. And the screen state affects things the other objects (e.g. maybe, for whatever reason, you're supposed to be able to pause a video when the player is compact but not when it's expanded or in full screen).
What is the best way to make multiple state systems interact with each other when those interactions are complex and flow in both (or multiple) directions? How can one organize such code so that it's easiest to debug and scale?

The primary way to manage complexity in complex systems is to find analogies and concepts in the real world upon which you can base your design and implementation. So, when you talk about people, dogs and refrigerators interacting in some system you base methods of interaction on the way these entries interact in the real world - which is largely autonomously based on sensed inputs and internal interests/goals/needs. When you talk about media players and images and text then finding the analogies is more difficult but just as important.

Related

I need help choosing a game engine for a very specific task

I need a 3D engine for a very specific task in Artificial Intelligence, and I'd like some input.
The first part is the trivial one - basically, all I need is a FPS engine (3rd person would be good, too), such that it allows me to navigate a room and interact with objects (if you have Java and Windows, I'm looking for something similar to the Give Challenge, but a little more up-to-date). Physics would be nice, but is not a must.
Now, the non-trivial part would be: I need to impose a virtual grid over this room, such that at any moment I can say "the player is located at B5 - now he moved to B6", and so on. I need to redirect this information to another system (namely, one which will give the player instructions about what to do) and, at the same time, send messages to the player, so I must be able to have a single point through which the game logic passes through; also, I'd love not having to write my own collision detection and such.
So far, I've tried:
the Source SDK: it seems a little overkill (since I'm not really planning to shoot anyone, at least half the code base is useless to the task), and since I'm not really a Windows developer, I'm spending too much time with the "easy" stuff (such as getting VS up and running). Plus, cross-platform would be really nice.
Blender game engine: while this worked decently, the interaction model seems a little weird, and some easy stuff (such as making sure the camera stays inside the scene or showing the mouse on screen) gets too weird too soon.
Crystalspace 3D: I've tried their demos, but it looks a little old-fashioned, and since that was one of the problems of previous engines (it's easier to get volunteers when your game looks nice) I'd like to try something else.
Now, maybe I'm asking a little too much for a single software, but I'd love some input. Can anyone suggest me an alternative? Or should I give one of the previous ones a second chance?
Try the UDK. All of the things you request are present, and it's free for personal/noncommercial projects. Here are some highlights:
Modern looking. The UDK features an intuitive-ish visual material design system, post-processing effects, Scaleform Gfx UIs from Autodesk, and more.
A visual scripting interface called Kismet that can control gameplay elements, the camera, and more.
UnrealScript, a scripting language similar in syntax to C, C++, Java, that gives you the ability to extend existing functionality or create your own.
Comprehensive documentation available on UDN.
Lots of community support outside of Epic, in places such as Polycount, Eat3d, 3dbuzz, and more.
Basically, "and more".
If what you're looking for is a professional, free (as in beer) engine that will allow you to focus primarily or solely on your differentiating gameplay features, Epic has set the bar high.

How do cross-console games work, codewise?

When a company decides to make a new game cross-console, what happens in terms of the code for the game? I'm thinking of major games i.e. Bioshock, Call of Duty, etc. that run on xbox, ps3, wii and/or PC.
When a game is being designed, does it have to be designed with each platform's API (assuming they all have different APIs)? I just picture it in my head as game companies doing three times the work for three consoles, but I know that must not be right. How do they get essentially the same game on different consoles?
It's all about abstraction, never call the os/console's file api or gfx api directly, abstract it. If you do that you will only have to change your abstractions, and not find every trace of the other os/console in your program, and change it.

Hallway usability testing: How much of the UI do you actually make functional?

When doing hallway usability tests do most of you make your apps fully or near fully functional? Or do you just make sure the links or flow chain correctly? Or do you just draw on paper and go with that?
I'm would like to test early on a prototype and am trying to find a good balance. But at the same time am worried that some non functional parts might actually not give representative results.
Thanks.
Usability tests, hallway or otherwise, only need the functionality that you need to test. In most usability tests, you should go in with specific design questions to answer and develop your prototype to the point where it can answer those questions. For example, if you need to test if users understand your indication of the sort order for a table, all you need is a paper picture of the table showing the sort indication (with the table contents blurred) and ask them how the table is sorted. If you need to test the IA, all you need is a bunch of web pages, empty except for a title, that are linked through the navigation menus.
You only need the pages relevant for the tasks you give your users. If you’re just testing the IA, then you only need the pages on the normative path. If you are also testing error recovery, then you need the pages off the normative path along with the full navigation controls. If you are also testing error detection, then you need content on the pages as well.
You can also simulate functionality when that’s easier to do. For example, in testing if users can figure out how to get a desired sort order, when the user clicks on a non-functioning control for sorting the table, you can say, “Okay, doing that will get you this,” and you take the mouse and select a bookmark that shows the table in the new sort order.
In hallway testing, if users breach the fidelity envelope, you can simply say, “I haven’t made that part yet. Let’s go back to A, and continue from there.” Of course, you should note that the user made a wrong turn in the task you intended for them. I haven’t had any problems with users complaining about non-functional features when I tell them up front it’s an incomplete prototype and we’re only testing the UI for features x, y, and z at the moment.
For low fidelity prototypes, I often call them “mockups” or “drawings” to users rather than “prototypes” to indicate the low functionality. You can put obvious placeholders in for missing content (e.g., “Blah, blah, blah…”, “TODO: Picture of product about here.”). If a user comments on something outside the fidelity envelope (e.g., “This symbol should be red to stand out more”), simply note it, and say that topic is under development (e.g., “Thanks. We haven’t started work on the colors yet. We’re just trying to figure out how to organize the site right now.”).
Usability testing with limited-fidelity prototypes is really necessary for iterative design to be feasible for most projects. Otherwise, you waste too much work developing things that have to be redone.
A couple things to remember:
Test early and often.
The goal of usability testing is to find problems with the UI, not Q/A your code.
Therefore, if users can see the parts of your UI you are interested in testing and interact with them in a realistic way (e.g., click on buttons and links), you should be able to collect useful data. If some links are dead-ends, that's okay, as long as there's some way for users to recover and continue on. Basically, with prototypes, the "correct" path should work, but it's okay if incorrect paths don't (as long as there's a reasonably quick way to get back on the correct path). Even static storyboards (non-functioning drawings of a UI) can provide you with some information if you ask the right questions, e.g., "What would you do on this screen if you wanted to view your shopping cart?").
I would suggest a couple rounds of usability testing. First on paper, perhaps later on screen, generally throughout the application lifecycle (take an Agile approach to it).
There is a good argument to be made for paper prototypes. When users see a screen, even limited functionality, they may be hesitant to suggest changes since it looks "done."
Make no mistake, it's not trivial to get it all down on paper, but that's where I would start. Probably start with just a section or two of the application. And make sure somebody with good people skills and/or explaining skills is there to walk the user through it. Have a second person on-hand to take notes. Try to ask open-ended questions, etc.
For a hallway test, I would test with NONE of the functionality implemented.
Test against designs done on a whiteboard or on paper. You'll be surprised at how much you find out in these minimal mockups. And they are very inexpensive to make!
Functional prototypes are for later. If you give your usability subject a functional interface, they are much less likely to question whether you've implemented the right set of features in the first place.
I would make the UI functional, so that the user can really play with it, it will be much better than a static image. People can tell you whether they feel comfortable on the UI.
I would make sure everything in the UI works, or at least takes you to a clear, unambiguous message pointing out that the feature isn't implemented yet.
Showing prototypes to clients with a disclaimer up front about how feature X doesn't work yet will usually be ignored. They'll try out the prototype, click on featuree X and indignantly reply "Feature X doesn't work! This really needs to work in the final version! Why doesn't it work?". The client is confused and unhappy about the product, and it's frustrating for yourself because it overshadows the positive feedback. Besides, you told them it didn't work, why can't they use their imagination to envision how it would work in the final version?
Make it work, be it with a rough version, dummy data, or even a simple message saying "would show results sorted alphabetically now".

Preventing cheating in online chess games? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
In many online chess lobbies, I've seen instances of 'engining', where a cheater would open a chess program at the same time as the main game window. He would then set it up so that the opponent's moves are relayed to the computer, then which he would copy the computer's moves, until he (almost always) wins.
As a game developer and moderator, what is there to do about this situation?
I can't see that there is anyway to prevent someone to using a chess engine to assist them, unless you can observe the player.
You might have some luck protecting against fully automated bots, though.
Online poker sites use anti-bot measures similar to what you're describing. I recommend the series of articles How I Built a Working Poker Bot for a good overview of how these systems work, and how they are defeated.
I agree with the others who said that there's not much you can do to stop the most dedicated cheaters, but you might be able to prevent casual cheating. (The problem with that, of course, is that then the dedicated cheaters will rule your site.)
Many chess computers work to formulas and end game books, so they will often play the same move in a particular situation. You could run users game history through a variety of chess computers and see if the users chosen moves after the opening moves have correlation with how the various chess computers play. This could be used to highlight users that are using chess computers.
Sites like chesscube monitors you for some time if you comes under the radar of suspicion. They monitor how much time you are taking for hard moves and relative simple moves. If there isn't some serious difference, they may conclude you are cheating. Also I believe they implement some method to check the shifting between windows, however I'm not sure about what they use for it. But I personally know guys who had been banned. So their method is pretty good.
I second what JesperE say, You have to monitor the guy for sometime before arriving on an opinion.
As a holder of a similar site, I would suggest just to let them be. If you are not intended to monetize the bets, the cheaters will move to their level of Chess program that plays for them, and fall off.
Best practice is to keep several player rooms according to level, thus cheaters will even be welcomed, allowing strong players to reach out to higher level, and adding practice to rookies.
Technically, there's nothing I can think of you can do.
Socially, there's a lot. For example, all of the online board game servers I've seen make very public the user's win/loss record, and compute the user's rank from that. Doesn't that just encourage people to want to win? Instead, I'd record all games, but not present a win/loss record anywhere (does anybody at a real chess tournament know how many games they've won/lost ever?). Make rank a user-entered number, used for the purposes of finding an appropriate partner only, so simply showing rating of 5000 is meaningless. If you need to have some kind of 'user rating', then add a commentary system, to let users comment on moves of other people's games, and then let other users rate the comments. Commentary is one thing I haven't seen computers do intelligently yet, so it's something you can probably assume comes from a real person.
I would suggest having them have a webcam behind them but slightly to the left so you could see if they were pulling up another window such as a chess engine, as a chess master (rated 5th in Canada) I was baffled at how I was losing against players so frequently on the internet (the high timed games, ironically whenever I beat an engine user I was immediately accused of cheating) yet I would never lose to anyone except those top players in Canada's country tournaments where the best of the best were there. The difference? Those people couldn't use a chess engine while I was staring them down as they made their move. All you people that cheat, I fail to see the point, you aren't winning, you aren't furthering yourselves in the games, all you are doing is wasting your time mimicing a computer, you aren't even analyzing the board! I only play 5 minute games and blitz because these cheaters can't efficiantly use their engines in such a short time period but this is not how chess is supposed to be played you are supposed to think about you moves.
Nothing effective.
Depending on how much access you have to the computer the user is playing on, you can scan his process list for known chess programs and kick him if you see one... but there is no guarantee that he is actually using it in the manner you describe, and he can always use it on a separate computer if he has duel displays or a KVM.
Cheaters will find a way to cheat.
The good news in this case, is that the computer programs for chess are reasonably beatable unless they are running on some serious hardware.
Good luck.
You can theoretically prevent the automatic relaying of moves (but doing it manually is not much of an obstacle unless you're playing speed chess), perhaps even prevent any chess programs to be run on the same machine. But IMO that's a waste of effort, because you'll never be able to prevent people from running a chess program on a different machine sitting next to them.
Im not very familiar with this enviroment. But maybe CAPTCHA would help stop automated robots. You could also generate statistics for your users (games won/lost/average speed to move, etc). The first movements should be fast, but later on the movements should be slower as complexity increases. so you can highlight cheaters, monitor them and maybe ban their accounts as Wikipedia does with some editors. You could even make a point based system as stackoverflow does, to whitelist known good/clean players.
I cant see any way of stopping this from happening - pretty much whatever you do the cheater will still be able to manually "copy" the move that the other player has made (to another computer if necessary).
How about somehow using social mechanisms to discourage these sorts of players? Cheating in this way is obviously in itself fairly unrewarding in the long term for the cheater - if you can find and eliminate / safeguard any potential gain (for example ranked tournaments with prizes) that the cheater might be able to use this to explit against, then you should at least be able to keep the percentage of cheaters down allowing most other users to enjoy "genuine" chess games.
I don't know the specifics, but I'm sure you could get statistics about the behavior of players that cheat this way--in other words, find things that the cheaters have in common (length of turns, consistency, etc) and have your application automatically find those and put a "red flag" on players that look suspicious. Then you can personally review them (or have someone else do it) and see if indeed they look suspicious. If so, ban them.
Other than that, there is really not much you can do unfortunately. The above suggestion is a lot of work, so unless you're willing to put in the hours to create such a system, I wouldn't even bother with it. Whatever barriers you put up, determined cheaters will get around them.
I have two accounts on chess.com. The first one i use to cheat. I have rybka deep 3 which is the most beastly chess program i know. On this account i have played 70games and lost 8times. 6 of those times are to time running out. The other two was from playing two GMs. I would never enter a tournament with it because thats just crossing the line for me but regular rated game i cheat like crazy. I don't do it because i want to win. I do it because i want to see who can beat this program. The two GMs that beat it. It was one of the greatest chess games ive ever seen. They never won after that and i played them a lot after that. I have another account which is my legit account that balances out my conscience. Im more in between beginner and intermediate. Anyways great players can tell when someone is using a comp program. Ive been accused like a dozen times for cheating because some of the moves rybka pulls are just straight godly. I have gotten banned once before on chess.com for cheating. It sucked cuz I had some epic games saved on there but on my new account that i have for about 3months now has not been banned. Maybe because the people i play see it as a challenge than them getting duped. IDK but ill soon start losing on purpose to fall under the radar xD. So if you want to catch a cheater ill say look for people with ridiculous stats like 80games, 9losses, 3draws with ratings of 2200+(If youre using the regular chess rating system).
There isn't much you can do to prevent cheating other than using correlative methods and a banhammer. You can make it very difficult for them to get a new account once they are banned or better yet just match them up against other cheaters transparently. Eventually they'll get bored. While it does depend on how much access you have, I've seen some java applets that will effectively create a hash of hardware profiles similar to apples UDID, and then theres cookies. Matching banned account email hashes to strings in other login cookies wouldn't be too difficult either. Taking it to the next level, if you had an app running locally you could also peek at the process list. Looks like this might be a bit dated by now though.
The only solution is to show that cheating does not do anything beneficial for humanity and to show to cheaters that humanity is more important then some ego based reward they get from cheating. You cannot detect a computer vs human in all cases without putting them in a isolated room with no way to cheat. There are very good players, are they cheaters?
The reason there are cheaters is because society has allowed cheaters to exist and perpetuate and benefit.
Ask yourself, why does a person cheat? Self-worth? money?
When a society doesn't fulfill the needs that every human being needs the human beings find ways to do so.
e.g., if you are poor and can cheat at something(e.g., politics), become "wealthy", get a hot wife, famous, etc... then you are likely to do that.
In a perfect society everyone is equally wealthy and everyone works to help each other. There are no famous people because that creates an imbalance and everyone realizes that. There are no ugly or hot people because everyone is what they are. There are no fat people either because everyone works out to be healthy and not to be a drain on society(which makes them look better).
America and Christianity(and just about every other religion) have created a huge inversion of morality. By focusing on materialism, imaginary scenarios of life after death(Santa Clause and Tooth Fairy stuff just wrapped up in a guy named Jesus and a book instead of a Tooth).
The problems are fundamental and much more than chess and to solve the chess problem one must solve the fundamental problem. Society and humanity must change. Since this won't happen any time soon and is too complex a problem for 99.9% people to grasp(most are too busy reading their bible for answers that never work) the best thing to do for any individual that understands the consequences of cheating is to simply not cheat and life with the cheaters the best they can.
Don't go to the dark side and things will eventually get better. Cheaters cheat... they cheat each everyone, themselves, and life and there are consequences.
e.g., suppose you could divide the world up in to two groups. Cheaters and non-cheaters. You could isolate both. The cheaters would eventually die out because they don't do anything worth while. They are effectively parasites and need a host to life. Remove the host and they die(it doesn't happen in the real world because they can thrive and do quite well, because the non-cheaters are generally ignorant of the fact and unwilling to make hard choices. (e.g., if a husband is a cheater and the wife isn't, she usually stays with him rather than leaving him... or better yet, never marrying a cheater in the first place(which is hard but easier if Christianity didn't make it so hard).)
I'll give you an example: I used to play counter strike(a first person shooter) when it came out. There was obvious cheating going on and I knew it(it's impossible for humans to do certain things, just physics). I did research and found some bots and started cheating myself. When I suspected cheating I would use the bot. Guess what?!?! Sometimes I would lose! Bots are nearly perfect and instantaneous... yet I would lose! That means there are other cheaters! I would call them out and tell them I am cheating and that they are too. Most would say they weren't but I had a few admit they were.
What did I do? I quit playing the game when I realized it was more than 25% cheaters. I knew that I got nothing out of it. Cheaters don't get better at what they do. They cheat because they suck and can't handle the fact that there are better people in the world. Which goes back to society, because society creates these feels(sports, for example... just turn on TV and you'll see someone talking about how X is so great because he did Y... and it subconsciously makes you feel like you are not great, even though you are because your in the top 0.00000000001% of intelligence on this planet and probably galaxy).
Games are suppose to be about learning. When you cheat you don't learn. Society has forgot that and instead make fun of people that are not as good at something as someone else... but this is almost solely due to time. People good at X put in a ton of time in it. Cheaters don't get that. They first think the other person must be cheating because "How could I lose??!?! I am a genius! They must be cheating! I will cheat too! I'm saved, I will go to heaven! So it's ok!".
Think about it!
If people were completely honest and cared about everyone else(because it matters), we wouldn't have: Murders, cheaters, scammers, captchas, passwords, rich/poor, iOS(ok, joking ;), etc...
It can be done but only through enlightenment. When people learn the world isn't flat, that it takes two to tango, etc then we will get beyond all this mess. Until then, we can only work on trying to make it better:
Don't cheat or you become like them and go to the dark side... which is only fun temporarily cause that's how it gets its teeth in you.
If you play any type of game with others expect that they will be cheating. If they are not cheaters, then they won't get mad. When someone accuses me of cheating I take it as a compliment because it means I am better than they are(well, that's ego but it's ok because I don't take it personally ;)
Playing with cheaters only makes you better. Imagine 99% of people on chess.com cheating... and you don't. You will get better because you will learn strategy. They can't beat you in the real world then. The real deal is always better than the fake synthetic crap that America and Christianity pushes down our throats.
Ultimately it doesn't matter. You are going on die. There is only one purpose in life and that's to transcend. Know that if you are against cheating you are already further along than cheaters. But it's not a game, help them transcend and the world and after life will be better.
Or you can move to a large deserted island like me and just allow the bad world to cheat itself to death! I'd invite you to stay but only if you can prove to me that you aren't a cheater! ;)

What is the "Fountain Development Model"?

It is mentioned on the Systems Development Life Cycle page on Wikipedia:
To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.
I found a few things on Google, but I felt that they were vague and they just didn't click for me. Perhaps an explanation from someone here might be more clear.
Fountain: Stand in a circle and throw some patterns and key words in the air to see where they land. Pick up only the ones that land inside the circle. Repeat until cancelled.
Waterfall: Wrangle everyone into a boat, then yell "Geronimo!" while going over Niagra Falls. Pick up the shattered pieces then rinse and repeat. Make sure it's well documented what part of the boat each individual should be sitting in, what they should be holding on to, how loud to yell, and exactly where they should land. See form 3684-B for additional instructions.
Spiral: Pick one team member and have everyone else spin them around in circles until dizy.
Build and Fix: Just throw it against the wall to see what sticks. If something falls off add some duct tape. Used gum may also work. Any part that won't stay stuck, just throw away.
Rapid Prototyping: Do exactly what the client asked for. Repeat until they figure out what they want.
Incremental: Only build the parts you want to, and only when you want to do it. An alternate version is to only build the parts they scream loudest for, and only when they are actually standing at your desk waiting for it.
Synchronize and Stabilize: Like Spiral except only one person at a time spins the unlucky team member. When their turn is over, stop the spinning for a moment.
Waterfall is a model that enforces control and avoids parallelism; every requirement for a task has to be fulfilled before starting the task. Fountain says that a new task can be started before all requirements are met, because not all requirements are necessary at the start of the task.
Think of this: Super Mario Game,
Waterfall: first, design everything, then get hardware done (Hardware Team), then create some test sprites, then code the engine, then create artwork, then music and finish.
Fountain: while the hardware team is doing its job, artwork starts conceptual work, and coding starts some prototyping on preexisting hw. When artists and hw finishes, coders integrate these onto their code and continue 'til finishing the game...
As I understand it, they essentially contain the same steps but a fountain approach is much more iterative, with less focus on initial design and more on analysis.
You basically bodge your way through things. See what needs to happen, and improve it. See what needs to happen. Improve it.
It's more agile but at the cost of project stability. Waterfall is a lot better for large projects.