Little Big Planet gives many hints to XOOPS Cube

Little Big Planet will be on sale tommorow in also Japan. This game will give many hints to XOOPS Cube project. If you have PS3 and XC users, it's useful to research this game for you.



Little Big Planet is a platform to share each works. Anybody can download levels that other users created and play the levels with your friends. You can share interesting levels to your friends and tag.

Little Big Planet is a creation tool. Anybody can create a new level and release it freely. It's impossible to prevent any creations.

Little Big Plannet is a community to have fun. It's important that creation is very interesting. Anybody is a creator before tools.

Lastly, Little Big Planet is a different world from your daily world. You will get freedom to create something there.

An ideal software design (2)

In large scale systems/applications, a specification is prepared before. Basically it is trusty. So a software architect can design program for program and programers. But, large scale systems/applications orient rather program, not programers. Because such systems/applications are used for a long time. So these systems/applications should be flexible to respond a little change and have extendability. To implement these features, a software architect designs software on program ground, not programer ground. It devides software in rational modules.

That's very excellent. But, does it hold good in all cases?

Large scale systems/applications are just a kind of software. All of projects is not large scale. And, there are period, goal, scale, software life-time, runtime style (realtime or not?) and specialized programers. An ideal software design is optimal solution for those factors that is written during design period.

If someone see the design from another situation, he may feel that the design is not good.

Some architects quest for beautiful design. They think that is justice. But software design is not art that an architect dedicates his life. And software design is not game that an architect has fun. However, it's sure that there are not good guidances with the exception of large scale systems/applications. Some architects feel cool from those guidances and try to apply it to their project...

Tight situations may detach your design from an ideal software design that you think. On the other hand, tight situations sometimes bring you to optimal solution.

An ideal software design (1)

Normally, we try to decide software design before a team begin writing program. That may be simple block wiring diagram or UML. Many programmers gather to your team for rapid development. The thing that you must do is software design. For that, you divide software in modules. That is a good design for program.

But your mission is that each programmer becomes able to bear part of programming. Can your design realize it?

A logical design for program and a logical design for programers have difference. If you design software and write its program yourself, you perhaps don't notice this truth.

An ideal design that have many modules for program often blocks specialized programers. That makes it impossible to start productive development.

There are many specialized factors of program --- makefile, memory management, resource management, peripheral, hardware control, content-pipeline, parallel processing, shader, effects, particle, animations, graphics, audio, cinema sound, AI, physics, geometry, procedural technology, script, network, debug system,third-party middleware and so on.

Can you design software by combining these specialized factors systematically? Perhaps, you can do it. But, an ideal software design that you've designed for program is bad news for programers who gather to a project. A game system requests a composite of their knowledges and their code from thebeginning. So a project becomes tangled.

Is an Object-Oriented Game Engine necessary? (2)

Now, what is an ideal game object design in an object-oriented language? I think that a good game object design has been completed at former time. So a video game programing has been implementing a factor of object-oriented design since that time.

It's important that video game programers of the time did not want to realize object-oriented programing. They had been questing for productivity development and exciting video game. There is something that we should learn.

We can use full spec object-oriented programing language. I wrote that it is the cause that disorder our game object design at the previous entry. But video game programers of the time could not use C++ (and C!), so they used machine languages. A project that I have joined first was written in assembly. Under such a condition, programers can not quest for object-oriented design, so its design gets a good balance for game naturally.

Check it. The technique that we have used is Task System. Of course, video game programers are using this technique now with C++. But, programers of the time wrote the Task System in assembly, so current way and old way have difference.

Task System is one of popular video game development methods. That is a primitive memory block that consists data and jump addresses. Rewrite jum addresses to change a behavior. Call backed code can access member data by offset access. Polymorphism already came true. There is no "type", but it is similar to the compiled result of C/C++. We write this in C++ now. C++ has the vtable concept, so C++ can realize polymorphism better.

On the other hands, our project forbad that a task block accesses a jump address of other task blocks. In other words, we forbad the message communication between game objects.

It is not safety that a task block accesses a jump address of other task blocks, because there is no 'type'. C++ can handle it more better, because we can write safety down cast comparatively in C++. But, it's also difficult to debug. Another reason why we forbad it is that we could not find a merit from such a way.

Child tasks control own. But if these tasks need to work with other tasks, the parent task which is a manager role for children does the work. I don't know whether this way is optimum solution for us. But, it was easy to debug, tune and tweak, and was flexible for change.

Because there was not term "Object-Oriented" around us in those days, we didn't quest for it. Complacency of programers did not disorder game object design.

Is an Object-Oriented Game Engine necessary? (1)

What is the validity of the class-hierarchy that makes GameObject class and specialize those for downward classes? In this case that each object passes a message to each other, the only task of the object list is telling a signal. Specialization like down-cast is done within each object. Nor there may be more strange code to do specialization.

(snip)

A rule of game (game-design) defines the situation that each object send a message to each other, from the top-view. Loosely-coupled like plug-in is not good solution for game. It requires a perfect description. If a new kind of game objects is added to code, all existing game object classes have to define response to the new class. In this jigsaw puzzle, a kind of piece has to define "joints" to all of other piece.

[The validity of managing Game Object without generalization - Worklog]

I understand his struggle, because I have ever tried to handle game-engine and graphics systematically with researching middle-ware, engine and scene-graph for several years now. But, in my project at my office, I can not live up to it. A video game programing that is real-time application requests performance always and many programers are assigned to a project, so a systematic architecture that makes a sacrifice of both performance and the early stage of projects is not useful.

High-level languages like C++ tempt us to change our programing style. Amazon and book stores display books that teach how to write object-oriented programming. We read these books and begin to plan to handle game object classes with object-oriented programming. It's sure that there are enough discussions about object-oriented architecture of large scale systems design. But, there are not enough discussions for video game application design, especially in Japan.

In America and Europe, developers discuss game object design. But, most of them develops FPS and RTS. These genres are a good match to object-oriented design. But all of games is not FPS and RTS. So many Japanese developers don't discuss game object class design. In other genre, it's necessary that a game core controls game totally. And, the most important thing of video game development is tuning and tweaking. In our world, an ideal architecture collects entertainment control panels to one place for easy to tune and tweak. Video game developers have to put entertainment feeling before the fixed spec documentation.

If we write source code with books that teach large scale system design, the game application feed programers' vanity. But the application is bad as video game program. Our ideal program design might be different from the large scale system. And, a video game object-oriented design might be different from a large scale system object-oriented design. So the books don't teach all thing to us. We have to find an answer ourselves. Japanese, American and European don't find the answer, yet.

PowerPC Personal Computer

All major game consoles take PowerPC class. There are many special technics to write high-performance code on PowerPC. In holidays, we were able to try it with ApplePC, but that's old story. Because ApplePC changed from PowerPC to Intel, there are not reasonable PCs to practice in PowerPC programing at home now. How can I try PowerPC and multi-core programing in home?

There are old mac mini, latest iMac and PLAYSTATION3 in my home.

My old mac-mini is not multi core, but that's valuable for me, because the mac-mini is small, light and good to enjoy PowerPC programing.

The current my PC, iMac is dual core and good to practice in multi-core programing. However, intel core duo is not taken by major game consoles. Therefore, I can practice in pure multi-core programing, but that's not useful directly for my job.

PLAYSTATION3 may be useful. It's possible to install Linux and practice in heterogeneous muliti-core programing. Of course, heavy linux environment is inconvenient to program, than PS3 SDK, but there is no chose, because standard PCs don't have heterogeneous multi-core. Fortunately, we can get all of tool-chain of PS3 except specialized libraries like SPURS.

PowerPC multi-core PCs like Power Mac G5 are valuable very much in retrospect.

Working hours are not enough to research multi-core programing. I should have researched more in R&D status. Now, our team had completed R&D and began developing a product. That's good. But, I want time for more trial and error. My PCs are valuable a little for that.

Many expert developers got ways in multi-core parallel processing in games. I don't arrive at such stages, yet.

Is little endian or big endian?

I saw interesting code to check endian.

bool isLittle()
{
 unsigned int val = 1;
 return *((unsigned char *)&val);
}

If a machine is little-endian, 'val' is reversed and stored to a memory. That may be implementation-dependent way. But I think that it isn't problem for specific products, if the library having the check code supports specific type of applications.

Of course, if this value is not cached, we should use const.