jump to navigation

Struktur Game Engine Februari 9, 2008

Posted by kunilkuda in Konsep Game.
add a comment

Berikut adalah struktur tentang game engine yang gw tangkap dari diskusi: MVC di gamedevid.org.

Tetris Engine-Class diagram

Decorator Pattern for Protocol-based Data Januari 16, 2008

Posted by kunilkuda in java.
add a comment

I will have SCJA (Sun-Certificated Java Associate) certification soon, so I learn again about Java, UML, OODA analysist and design pattern. I found out this old design pattern that suits our protocol-based development (both for gateway and MCU side).

Our current protocol is something like this :
struct WP_Protocol {
uint8_t appId,
uint16_t originAddr,
uint16_t destAddr,
uint32_t timestamp,
uint16_t sensor1,
uint16_t sensor2,
uint16_t sensor3
}

In our previous code, we pack the data inside single function :
void pack(destAddress,sensor1Data, sensor2Data, sensor3Data) {
struct WP_Protocol packedData;

packedData.appId = AGROMONITORING_APP_ID;
packedData.originAddr = getLocalAddr();
packedData.destAddr = destAddress;
packedData.timestamp = time();
packedData.sensor1 = sensor1Data;
packedData.sensor2 = sensor2Data;
packedData.sensor3 = sensor3Data;

// Send to radio

}

It’s good and works well. But suppose we want to change the protocol, we will have to modify the structure and the pack(), and test it again (for big-endian / little-endian sequence, etc). So, the pack() will not be re-usable, because each protocol will have their own pack().

I found better idea. Rather than messing around with pack(), with this method (called decorator design pattern), we can have re-usable codes, multiple-protocols, and minimum testing.

Here’s how :
1) Define the layers
struct sensors {
uint16_t sensor1,
uint16_t sensor2,
uint16_t sensor3
}

struct timestampLayer {
uint32_t timestamp,
void * data
}

struct appIDLayer {
uint8_t appId,
void * data
}

struct addressesLayer {
uint16_t originAddr,
uint16_t destAddr,
void * data
}

2) Define the methods to handle the layers
struct sensor packSensor(sensor1Data, sensor2Data, sensor3Data)
{
struct sensors retVal;

retVal.sensor1 = sensor1Data;
retVal.sensor2 = sensor2Data;
retVal.sensor3 = sensor3Data;

return retVal;
}

struct timestampLayer packTimeStamp(void * data)
{
struct timestampLayer retVal;

retVal.timestamp = time();
retVal.data = data;
return retVal;
}

struct appIDLayer packAppId(void * data)
{
struct appIDLayer retVal;
retVal.appId = AGROMONITORING_APP_ID;
retVal.data = data;
return retVal;
}

struct addressesLayer packAddresses(uint16_t destAddr, void * data)
{
struct addressesLayer retVal;

retVal.originAddr = getLocalId();
retVal.destAddr = destAddr;
retVal.data = data;
return retVal;
}

3) To create old structure, just chain the whole functions :
sendToRadio(
packAppId(
packAddresses(0,
packTimeStamp(
packSensor(sensor1Data, sensor2Data, sensor3Data)))));

To create new protocol, where address layer come first before appId (for example) :
sendToRadio(
packAddresses(0,
packAppId(
packTimeStamp(
packSensor(sensor1Data, sensor2Data, sensor3Data)))));

To create new protocol, where new layer added between timestamp and sensors (for example) :
sendToRadio(
packAddresses(0,
packAppId(
packTimeStamp(
newLayer(
packSensor(sensor1Data, sensor2Data, sensor3Data))))));

Anything that you want to change, just change the chain of calling. Because every layer’s function has been tested before, changing sequence won’t need new testing. The only thing that we need to test is new layer that will be inserted.

In summary, decorator pattern will save testing time, faster to deploy, and minimalize bug.

Fire and Motion Desember 28, 2007

Posted by kunilkuda in Curhat.
add a comment

Ever felt very tired of coding ? Cannot do more codes than 3-hours a day –out of 8-hours daily working time ? Wondering on how some people could survive in this kind of industry ?

Joel’s “Fire and Motion” is a good explanation of not feeling guilty =)

Where’s the comment ?? Oktober 3, 2007

Posted by kunilkuda in Curhat.
Tags:
3 comments

O yeah..That’s what’s people always ask me about.

Get realistic kid. You’re programmer, and your job is : <gosh!!> reading the source codes !!

Most of us never really really write codes (not from the scratch, I mean). We’re just read someone else’s source code, and fix it when necessary. That’s how the world run, unless you’re God and have remote control to stop the world..

Hey, no kidding here. You’ve only have 24 hours a day. You’ll need at least 5 hours to sleep, 11 hours for yourself, your family, and your social life, and the rest 8 hours for debugging (hmm…where should I put extra 1 hour for coding ??)..

So, instead of adding comments inside your source code, why not coding your codes into self-comment codes..Something like this :

public void updateSprite(long elapsedTime)
{
   float spritePositionX = spriteSpeedX * elapsedTime;
   float spritePositionY = spriteSpeedY * elapsedTime;
   drawSprite(spriteImage, spritePositionX, spritePositionY);
}

There..no need special comments to understand my code right ??