The reason why I often introduce AiGameDev.com's articles is that those articles are very interesting, written in easy English and brings discovery to you, even if you don't relate to AI.
"Screw Up Your Career Change to Game AI Programming in 7 Easy Steps" is written by Ironic. In other words, "what you should avoid is what you should do in fact".
I think this is very interesting approach. If you have some wishes, it's good idea that you try writing articles like those. Those ironic articles might be useful for self-check. Let's say that you want to change your career to AI programmers. You may not come true your dream as far as you complete most of 7 steps.
It's difficult to define what we should do, for our goals. But, it's easy to define escape routes from the goals.
Showing posts with label Trigger. Show all posts
Showing posts with label Trigger. Show all posts
Friday, November 2, 2007
Friday, October 26, 2007
Interesting Team Protocol
AIGameDev.com has many interesting articles about GameAI in easy English. And sometimes the site publishes special articles that describe about common problem not GameAI. This series explains about "The Core" that is a way of working as team --- as "Team Protocol". That's interesting very much and you may accept it to your office.
Scary Ideas is easy to accept. Maybe a number of game development teams do it in practice, in Japan at least. Anyway I laughed by this example Scary Idea. When you use Scary Idea, don't refrain from delivering your idea. So this example "Build a AI engine that’s scalable..." is perhaps very good. That said, it's really Scary!
Decider Protocol is embarrassed method and might be difficult to accept it to your office. Of course, me too. Even if I want to accept it and propose that my office's meeting uses this method, co-workers will deny it. But, a such vote system is often used to decision of projects, whether it uses fist. It's important that a staff who agree have to get involved about the agreement task. It means that the staff has accountability of its decision.
It's interesting role of decision-making to prepare a "Perfector". Note that any opinions are never rejected. The perfector sets only [1, 10] priority. That's gentle and good idea. And, this way is based on academic game theory model. I think this way is useful for our private life, because we often can't decide our mind ourselves.
BTW, talking of GameAI, the Bungie's podcast made mention of Halo3 Game AI. But I can not hear their voices. ・・・Because they are a native English speaker, I am NOT able to hear English. Umm...
Anybody translates that long long interview to documents! :D
Scary Ideas is easy to accept. Maybe a number of game development teams do it in practice, in Japan at least. Anyway I laughed by this example Scary Idea. When you use Scary Idea, don't refrain from delivering your idea. So this example "Build a AI engine that’s scalable..." is perhaps very good. That said, it's really Scary!
Decider Protocol is embarrassed method and might be difficult to accept it to your office. Of course, me too. Even if I want to accept it and propose that my office's meeting uses this method, co-workers will deny it. But, a such vote system is often used to decision of projects, whether it uses fist. It's important that a staff who agree have to get involved about the agreement task. It means that the staff has accountability of its decision.
It's interesting role of decision-making to prepare a "Perfector". Note that any opinions are never rejected. The perfector sets only [1, 10] priority. That's gentle and good idea. And, this way is based on academic game theory model. I think this way is useful for our private life, because we often can't decide our mind ourselves.
BTW, talking of GameAI, the Bungie's podcast made mention of Halo3 Game AI. But I can not hear their voices. ・・・Because they are a native English speaker, I am NOT able to hear English. Umm...
Anybody translates that long long interview to documents! :D
Tuesday, October 16, 2007
Is a main programer bottleneck?
What electric title! This is a title of the session in CEDEC 2007.
This session gave interesting hints. The thing OSS should do is not keeping authority (self-presevation), but developing software. To a such purpose, the session presented the important conclusion. OSS may refer the conclusion very much.
Like eating endless meals
The session said; A main programer has certainly higher skills and higher speed than those of company workers. So a main programer has to concentrate on writing programs, not do others. PolygonMagic which spoke in the session bans main programers from the following tasks:
Here is an interesting allegorical story. "Wankosoba" is a kind of Soba. Waiters keep bringing Soba until we give up. That's endless meals. A main programer should only keep eating Wankosoba, not prepare Wankosoba and Japanese teas.
Wankosoba:
Discussion: "This" is in XOOPS Cube
That's simple strategy known as "Agile software development", but is difficult way. If someone takes a lead as the main worker, he has to treat many many things. Since XOOPS Cube was forked, I was shocked to have to receive amazing various tasks. Unluckily, most members who were listed on "Core Team" didn't share tasks and didn't have good team play, because they were in each circumstances --- but I don't know a detail of them. Anyway it means that "Team System" is unhappy concept for everybody.
But, now, we're in new freedom concept without bloody team system. Contributors can do anything to the project. By that, program contributors may be able to concentrate into programing. When we consider about this agenda "Is a main programer bottleneck?", we'll get the powerful development. The XOOPS Cube community has many powerful programers!
Now what?
That said, the OSS project can't put in practice. Because we aren't employees of the project, programers have to do some odd jobs. Non-tech contributors can not steal all of odd jobs from programers.
But, this agenda is worth for us. We'll discuss it in the XOOPS Cube Developer Meeting.
This session gave interesting hints. The thing OSS should do is not keeping authority (self-presevation), but developing software. To a such purpose, the session presented the important conclusion. OSS may refer the conclusion very much.
Like eating endless meals
The session said; A main programer has certainly higher skills and higher speed than those of company workers. So a main programer has to concentrate on writing programs, not do others. PolygonMagic which spoke in the session bans main programers from the following tasks:
- The "eternal" teller to data.
- Manage the build.
- Director to release.
- Update library, driver and hardware.
- Update In-House Tools.
- And more.
Here is an interesting allegorical story. "Wankosoba" is a kind of Soba. Waiters keep bringing Soba until we give up. That's endless meals. A main programer should only keep eating Wankosoba, not prepare Wankosoba and Japanese teas.
Wankosoba:
Discussion: "This" is in XOOPS Cube
That's simple strategy known as "Agile software development", but is difficult way. If someone takes a lead as the main worker, he has to treat many many things. Since XOOPS Cube was forked, I was shocked to have to receive amazing various tasks. Unluckily, most members who were listed on "Core Team" didn't share tasks and didn't have good team play, because they were in each circumstances --- but I don't know a detail of them. Anyway it means that "Team System" is unhappy concept for everybody.
But, now, we're in new freedom concept without bloody team system. Contributors can do anything to the project. By that, program contributors may be able to concentrate into programing. When we consider about this agenda "Is a main programer bottleneck?", we'll get the powerful development. The XOOPS Cube community has many powerful programers!
Now what?
That said, the OSS project can't put in practice. Because we aren't employees of the project, programers have to do some odd jobs. Non-tech contributors can not steal all of odd jobs from programers.
But, this agenda is worth for us. We'll discuss it in the XOOPS Cube Developer Meeting.
Subscribe to:
Posts (Atom)