ManWithComputer
The Internet, IP
Male, 37
I've worked at multiple Internet startups of different shapes, sizes and ambitions. Now I'm the CTO (Chief Technical Officer) of another small company with big dreams. I look nothing like the picture above.
If you copy and paste your homework question in here, I will answer with something that will, at best, get you an F on your project, and at worst, will get you kicked out of school. You have been warned.
More RAM will never hurt performance but it may or may not help. Some tasks are "CPU-bound" and some are "memory-bound," meaning some will top out your CPU first and others will run through all your memory first. The only way to find out is to measure your particular usage and see.
When I'm buying a computer I tend to buy as much RAM as I can afford: you save money in the long run that way because the computer will have a longer useful life.
Get millions of dollars, hire a game development studio. A commercial-quality game is the creation of hundreds of people working together.
Not a clue, have never touched GameMaker.
Do your own homework.
Antiques Dealer
Border Patrol Agent
Professional Gamer
Generally you don't, but your question gives me an opportunity to explain a few interesting aspects of software engineering, so here we go anyway.
Engineers (software and otherwise) talk about the concept of "coupling." This means, roughly, "If I change Part A of this thing, how much if any do I have to change Parts B, C, D, et cetera?"
Good design usually calls for "loose coupling," which means that you can change one part mostly or totally independently of all other parts. In other words, Part A is a "black box" to Part B: Part B knows that it can get Part A to do something, but it doesn't have to know or care how Part A does that thing exactly, so you can replace Part A with something completely different, and as long as it continues to do the same task that Part A did, everyone's still happy with it.
When you see the opposite, "tight coupling," that means parts work together more closely, and it's a bigger pain to change one, because you have to change many others. Once in a while this is done for performance reasons, but usually it means that the design or implementation is bad.
So as programmers we like to make chunks of code that don't overlap, that only do one thing, and that offer certain services to other chunks of code ("expose an API") without actually committing ourselves to doing those services in a particular way. These high-level chunks of code are generically called "modules" although there are plenty of other terms too, for different contexts.
In particular, if you have an application with a complex UI, you would have one or more modules that did nothing but the UI: a module to put things in windows onscreen, to know what to do if someone clicks here or types there, and so on. But there would be more modules that handle things behind the scenes. Imagine for instance a mapping app where you could either type in an address, or say the address into the mic. These would be two separate modules, as piece of text in a window is a very different thing than a pattern of sounds, but the meaning of the address "123 Elm Street" is the same in both cases, so both of these UI modules would talk to one common module in the "backend," which means basically all the code that does something that the user doesn't see directly.
And this brings us, finally, to an answer of sorts to your question: if you can get your hands on the source code to the original application (which if the application is proprietary good luck with that), and if the UI is loosely coupled to the backend, and if you know how to program in whatever language the application is written in, then you replace the UI modules with modules appropriate to a phone or tablet.
The rest is just details. Thousands and thousands of details.
I can't. The last time I drew a flowchart was...possibly never. They're not much used anymore.
No.
-OR-
(max 20 characters - letters, numbers, and underscores only. Note that your username is private, and you have the option to choose an alias when asking questions or hosting a Q&A.)
(A valid e-mail address is required. Your e-mail will not be shared with anyone.)
(min 5 characters)
By checking this box, you acknowledge that you have read and agree to Jobstr.com’s Terms and Privacy Policy.
-OR-
(Don't worry: you'll be able to choose an alias when asking questions or hosting a Q&A.)