Game designer of Mega Man
Interview: http://shmuplations.com/megaman/
Kitamura: Going through all those games taught me something important, though. I started to think that if I focused on more detailed, intricate enemy behavior and placement, then I could probably achieve a better difficulty balance than what action games had offered so far.
Ariga: I think that attitude become one of the key elements of the Mega Man series.
Kitamura: Also, two of my personal goals for Mega Man were to create a game where all the stages could be cleared in an hour, and to make something that players would want to come back to again and again. To that end, I actually calculated the total number of stages by measuring Mega Man's walking speed and seeing how long it would take to get through each stage. I then split that up so that the first half of the game would be the robot master stages, and the second would be the Wily stages.
Ariga: Whoa! You really did that?
Kitamura: I also created some rules for myself about enemy placement and design.
#1: Single, weak little enemies would appear in "waves" of 3 or 4 individuals (and to the extent possible, I'd avoid mixing up multiple enemies);
#2: they would all use the same attacks;
#3: I would use differences in terrain and enemy placement to adjust the difficulty of a given section;
#4: The difficulty of each enemy in the wave would gradually rise, but the last enemy to appear would be easier.
...
Kitamura: Making the last enemy encounter in the wave easier was a key idea. It leaves the player with a softer impression of the game's difficulty. I think the reason that people don't replay games---even good ones---is that when they remember playing the game, their minds go back to the extremely difficult parts and enemies, and then replaying the game starts to seem like tedious work. I wanted the player to feel like he was improving at the game too, and that was another reason to make that last enemy easier, I think.
These weren't my only "tricks" for how to get more replayability, but they were some of the big ones.
Players like little secrets
- Diagnose your learning needs
- Specify your learning objectives (why you are learning them)
- Specify learning resources and strategies
- Specify evidence of accomplishment
- Specify how the evidence will be validated
- Review contract
- Carry out contract
- Evaluate your learning
- Description
- Feelings
- Evaluation
- Analysis
- Conclusions
- Action plan
Both knowledge and wisdom extend man's reach. Knowledge led to computers, wisdom to chopsticks. Unfortunately our association [ACM] is overinvolved with the former. The latter will have to wait for a more sublime day.
https://www.quora.com/profile/Alan-Kay-11
- Visions not goals
- Fund people not projects --- the scientists find the problems not the funders. So, for many reasons, you have to have the best researchers.
- Problem Finding --- not just Problem Solving
- Milestones not deadlines
- It's "baseball" not "golf" --- batting .350 is very good in a high aspiration high risk area. Not getting a hit is not failure but the overhead for getting hits. (As in baseball, an "error" is failing to pull off something that is technically feasible.)
- It's about shaping "computer stuff" to human ends per the vision. Much of the time this required the researchers to design and build pretty much everything, including much of the hardware --- including a variety of mainframes --- and virtually all of the software needed (including OSs and programming languages, etc.). Many of the ARPA researchers were quite fluent in both HW and SW (though usually better at one than the other). This made for a pretty homogeneous computing culture and great synergy in most projects.
- The above goes against the commonsense idea that “computer people should not try to make their own tools (because of the infinite Turing Tarpit that results)". The ARPA idea was a second order notion:"if you can make your own tools, HW and SW, then you must!". The idea was that if you are going to take on big important and new problems then you just have to develop the chops to pull off all needed tools, partly because of what"new” really means, and partly because trying to do workarounds of vendor stuff that is in the wrong paradigm will kill the research thinking.
- An important part of the research results are researchers. This extends the "baseball" idea to human development. The grad schools, especially, generally admitted people who "seemed interesting" and judgements weren't made until a few years down the road. Many of the researchers who ultimately solved most of the many problems of personal computing and networking were created by the ARPA community.
Every invention has to be usable by at least 100 people.
Arrogance in computing is measured in nano-Dijkstras'
- Utilization
- Saturation
- Errors
http://www.brendangregg.com/usemethod.html
The Humane Representation of Thought Flat, symbolic representation of ideas (ie printed on paper) is only one facet of expressing thought. We lose our ability to think some thoughts if we express only through this mechanism
- https://cr.yp.to/
- http://loup-vaillant.fr/tutorials/poly1305-design
- http://loup-vaillant.fr/tutorials/chacha20-design
- http://linuxmafia.com/humour/dan-versus-theo
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
When faced with two or more alternatives that deliver roughly the same value, take the path that makes future changes easier
No rules are universal (except this one)
- tribe (opinion)
- cave (intellect coloured by experience)
- marketplace (semantics)
- theater (sophistry)
-
Just ask.
-
Don't wait for perfection.
-
Become a master.
-
Vision is everything.
-
Never disqualify yourself.
-
Challenge your limitations.
-
Have a vision. Write it down.
-
Speak every chance you can.
-
Don't go it alone.
-
Be flexible.
-
Aim high.
-
Be PASSIONATE.
-
Beware of bright shiny objects.
-
Choose tech or management.
-
Do something bigger than yourself.
-
Recipe for life:
- vision
- plan
- take risk
- stay focused (TTL)
- determination
-
Don't save your best for last.
-
Be generous now.
-
Enjoy life!
- Don't call a problem with a program a 'bug'; it is intellectually dishonest. Call problems with software 'errors'. (EWD 1036)
- Don't use anthropomorphic metaphors, as they are a waste of mental effort (EWD 1036)
Level 0: I overcame obliviousness:
I now realize there is something here to learn.
Level 1: I overcame intimidation:
I feel I can learn this subject or skill. I know enough about it so that I am not intimidated by people who know more than me.
Level 2: I overcame incoherence:
I no longer feel that I'm pretending or hand-waving. I feel reasonably competent to discuss or practice. What I say sounds like what I think I know.
Level 3: I overcame competence:
Now I feel productively self-critical, rather than complacently good enough. I want to take risks, invent, teach, and push myself. I want to be with other enthusiastic students.
Why Scaling Agile Doesn't Work
HPPO Method - Highest-Paid Person's Opinion
Cost of delay needs to be taken into account when comparing projects. Focus on value, not cost.
Users don't know what they want, but they know what they don't want when you've put it in front of them.
"Software features that can't be demonstrated by automated tests simply don't exist."
- Code even you cannot understand a week after you wrote it - no comments
- Code with no specifications
- Code that is shipped as soon as it runs and before it is beautiful
- Code with added features
- Code that is very very fast very very very obscure and incorrect
- Code that is not beautiful
- Code that you wrote without understanding the problem
Is High-Quality Software Worth the Cost?
Co-creator of /proc https://thenewstack.io/remembering-roger-faulkner/
"What Seymour threw out the window, Les [Davis] would catch."
- Start fresh with every new project
- Design simply using proven technologies
- Use old, solid, well-tested methods for design
- Work in small groups with a single decision maker
- Space matters, but do it right
- It's not about having a fast CPU, but a fast system
- Make things simple, but know where to stop.
I guess I have faith. That's a little different than confidence. I've been well taken care of in my lifetime. God looks after me so to speak and so if you have faith that you're doing what you're supposed to be doing, you're doing the best you can, then as I view it, you can leave the responsibilities for all of the peripheral aspects of life to someone else. So far that's worked for me.
"Old algorithms don't suck, unless perhaps you count Bubble Sort. Generally, the more tried-and-true an algorithm or data structure is (DFS, BFS, quicksort, binary search, hashing, etc.), the more confidence you have in it. Ideas are fundamental and timeless, but technologies are always replaced."
- https://plus.google.com/110981030061712822816
- http://steve-yegge.blogspot.ca/
- https://sites.google.com/site/steveyegge2/blog-rants
- https://medium.com/@steve.yegge
Inventor of Xanadu
- Don't mistake packaging (Windows, iPhones) for technology (TCP/IP, bit blitting)
- Technology is not determinate, inevitable - it was made up by people
- deconstruction,
- selection,
- sequencing and
- stakes.
- compression,
- frequency and
- encoding
-
Create constancy of purpose toward improvement of product and service, with the aim to become competitive and stay in business, and to provide jobs.
-
Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
-
Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
-
End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
-
Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
-
Institute training on the job.
-
Institute leadership (see Point 12 and Ch. 8 of "Out of the Crisis"). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
-
Drive out fear, so that everyone may work effectively for the company. (See Ch. 3 of "Out of the Crisis")
-
Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
-
Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
- Eliminate work standards (quotas) on the factory floor. Substitute leadership.
- Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
- Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
- Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia,” abolishment of the annual or merit rating and of management by objective (See Ch. 3 of "Out of the Crisis").
-
Institute a vigorous program of education and self-improvement.
-
Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.
- Lack of constancy of purpose
- Emphasis on short-term profits
- Evaluation by performance, merit rating, or annual review of performance
- Mobility of management
- Running a company on visible figures alone
- Excessive medical costs
- Excessive costs of warranty, fueled by lawyers who work for contingency fees
- Neglecting long-range planning
- Relying on technology to solve problems
- Seeking examples to follow rather than developing solutions
- Excuses, such as "Our problems are different"
Inventory of Ruby language
...computers don't mind if I must make effort to communicate with them or if it is easy to communicate with them. They don't care if I put the numbers of instruction byte sequences in a file and feed it to them to run, or if a very high level language generated the instructions. The computers don't care. We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines.
The day job to pay the bills, and the fun/beautiful work after hours
"Run upstairs"
When you're small and nimble, try to get as much technical ground between you and the competition. They're bigger, so it will take longer for them to reach feature parity. Natural barrier to entry.
"Start by picking a hard problem, and then at every decision point, take the harder choice."