Monday, February 4, 2008
Rush for Invigorate is over, but the rush for GDC begins
We have received some good responses at the final demo session at MDA's office yesterday, especially from Donny Kristianto, who has been a great help to us,and he was surprised at the final result of our demo. So now, Invigorate Casual is officially over, but Donny Kristianto has been kind enough to decide to bring our demo over to GDC 2008 and show it to Playfirst to get their insights on our demo. So right now, the team will be busy putting together the trailer and relevant materials to pass to Donny by the 14th of Jan 2008. Not to mention, we will be polishing up our demo so that it will be much better than what we have shown yesterday.
Tuesday, January 29, 2008
towards the last milestone
moving towards the final milestone,
i think we've had quite a journey.
p.s. gib i think u can replace the video with a nicer one after we put in chapter 5 and get more graphics (buttons and better close up views)
bumpy and all,
i guess we made it through the ride..
i think we've had quite a journey.
p.s. gib i think u can replace the video with a nicer one after we put in chapter 5 and get more graphics (buttons and better close up views)
bumpy and all,
i guess we made it through the ride..
Sunday, January 27, 2008
Video capture of the latest version
Here is the latest version of our demo which I have uploaded onto YouTube.
You can download the demo from here too.
You can download the demo from here too.
Thursday, January 24, 2008
The last mile
Now that we have hired a full time artist, production speed has been ramped up tremendously since now, most of our time is spent on adjusting our code to add new art and tweaking there and there and some polishing. I am going to create a video capture of what we have by the end of this week, so watch this space.
Thursday, January 10, 2008
New year, new issues
Now with the deadline coming in less than 3 week, 1 unexpected problem cropped up which created a major roadblock in our production pipeline. As our game uses a lot of graphics, we had 2 freelance artists working on the graphics which would be good if everything turned out well. But Murphy's Law came into play. 1 of the artist who was supposed to churn out crucial art assets for the background has been quite slow in delivering. A 3 day task was completed in 3 weeks and in that 3 weeks, I had no update on the art so I was not able to plan or even know what was going on, on his side.
On the hindsight, I should have canned him after he was late for 1 week. Now this artist is on the verge of getting canned from this project, but as he showed us pretty decent art a few days ago, albeit quite late art, so he is still in the project.
Now with the bad news over, 1 good news is that our other artist who has impressed us so far with the speed and quality of her work will be working on this project full time from the 16th onwards. So we expect art assets production to be ramped up tremendously then.
On the hindsight, I should have canned him after he was late for 1 week. Now this artist is on the verge of getting canned from this project, but as he showed us pretty decent art a few days ago, albeit quite late art, so he is still in the project.
Now with the bad news over, 1 good news is that our other artist who has impressed us so far with the speed and quality of her work will be working on this project full time from the 16th onwards. So we expect art assets production to be ramped up tremendously then.
Tuesday, December 25, 2007
x'mas update!
finally it's done. spent more than an entire week (including x'mas eve and x'mas!!) scrapping the architecture after the mda open house,
adding some features and also stabilizing some others.
a quick summary of wat i've done:
1) chapter concept added, that controls all the scenes.
2) scenes can be locked and unlocked later, if an item opens a prop.
3) creating a new item or opening a prop attains objectives (and show them as ticked in the objectives screen)
4) paperdoll screen appears i) when a new player starts up for first time, ii) when the player clicks wardrobe.
(please delete prefs.dat before running the app...)
5)revamped gib's paperdoll screen to be more user-friendly i.e. all the stuff are laid out on a grid and u just click on what u want.
the new hierarchy is
first u load a chapter.
the chapter loads
i)all the characters that will ever appear (even across diff scenes),
ii)objectives of the chapter
iii)all the items that will ever appear in this chapter (even across diff scenes)
iv)all the different screens and separates them into locked or unlocked
then u load the scenes,
which within itself contains
i)the dialogues,
ii)the qna,
iii)the props
the dialogues and qna has a characterid to them, and they will cause the respective person in the characters array under the chapter to be rendered.
the last thing i have left to do is the 2nd image of the prop. e.g. the opened door.
p.s. gib, can u help me prepare an image for that?
pls add in the grid thing u were saying u did for the paperdoll inside the paperdoll.cpp. thanks.
merry x'mas! i'm need a break.
adding some features and also stabilizing some others.
a quick summary of wat i've done:
1) chapter concept added, that controls all the scenes.
2) scenes can be locked and unlocked later, if an item opens a prop.
3) creating a new item or opening a prop attains objectives (and show them as ticked in the objectives screen)
4) paperdoll screen appears i) when a new player starts up for first time, ii) when the player clicks wardrobe.
(please delete prefs.dat before running the app...)
5)revamped gib's paperdoll screen to be more user-friendly i.e. all the stuff are laid out on a grid and u just click on what u want.
the new hierarchy is
first u load a chapter.
the chapter loads
i)all the characters that will ever appear (even across diff scenes),
ii)objectives of the chapter
iii)all the items that will ever appear in this chapter (even across diff scenes)
iv)all the different screens and separates them into locked or unlocked
then u load the scenes,
which within itself contains
i)the dialogues,
ii)the qna,
iii)the props
the dialogues and qna has a characterid to them, and they will cause the respective person in the characters array under the chapter to be rendered.
the last thing i have left to do is the 2nd image of the prop. e.g. the opened door.
p.s. gib, can u help me prepare an image for that?
pls add in the grid thing u were saying u did for the paperdoll inside the paperdoll.cpp. thanks.
merry x'mas! i'm need a break.
Wednesday, December 19, 2007
New stuff

It has been a while since the last update. The MDA Open House was extremely useful in helping us to gauge player response and the survey forms handed out turned in some pretty surprising feedback. We have implemented 1 additional feature as that feature turned out to be a surprise hit with the female audience and I have set up Mantis Bugtracker to track bugs and feature enhancements for me and XP.
We now have another artist on board and that makes 2 freelance artists. 1 will take care of concept and characters and the other will take care of the background. We have retooled out storyline to be something short and simple and with our Mantis database getting full of items. It is going to be a very busy Christmas for all of us.
Merry Christmas, everyone :)
Thursday, December 6, 2007
3rd milestone today
ok today is the 3rd milestone.
so what have i done?
it might seem that our build this time round is not much different from the last milestone on the surface, but that's not the case. i did a major overhaul on the codes structure, taking apart gib's and then restructuring them.
the thing about both of us is, gib is good at figuring out new stuff, he's able to start quickly on a new platform and show u something on the screen. while i will do the garbage cleaning and give u a pretty structure. i probably won't have new things on the screen for u in the first few weeks.
anyway,
what happens is previously, everything was defined per location.
so we had location1_screwdriver, location1_newspaper something like that.. which meant that this screwdriver and newspaper, were just used in location1. and because that's the variable name of that item now, if i need a newspaper in chapter 5 say location x, i have to declare a new one. because the codes have to somehow be able to create a new string with the current location id to refer to this variable.
so xp changed that (because we also got the reminder that we prob need another script-writer which might not be a programmer). now the items are just id-ed with a unique number, and its name in the string table which the script will get thru the id. Then i have a script called Scene, which holds the id of everything i need, location, character, dialogues etc, and the codes will composite them. in this way, a non programmer can refer to our list of items, and just write new scripts for new scenes easily. better still, i can reuse my parts like lego bricks. ;)
so what have i done?
it might seem that our build this time round is not much different from the last milestone on the surface, but that's not the case. i did a major overhaul on the codes structure, taking apart gib's and then restructuring them.
the thing about both of us is, gib is good at figuring out new stuff, he's able to start quickly on a new platform and show u something on the screen. while i will do the garbage cleaning and give u a pretty structure. i probably won't have new things on the screen for u in the first few weeks.
anyway,
what happens is previously, everything was defined per location.
so we had location1_screwdriver, location1_newspaper something like that.. which meant that this screwdriver and newspaper, were just used in location1. and because that's the variable name of that item now, if i need a newspaper in chapter 5 say location x, i have to declare a new one. because the codes have to somehow be able to create a new string with the current location id to refer to this variable.
so xp changed that (because we also got the reminder that we prob need another script-writer which might not be a programmer). now the items are just id-ed with a unique number, and its name in the string table which the script will get thru the id. Then i have a script called Scene, which holds the id of everything i need, location, character, dialogues etc, and the codes will composite them. in this way, a non programmer can refer to our list of items, and just write new scripts for new scenes easily. better still, i can reuse my parts like lego bricks. ;)
3rd try at the girls

ok this is another new set of characters from our artist. they are all very nice, but not what i'm looking for. she's trying again now, this time i've asked her to try exaggerated features and another art style..
though the first character that one might see for the current build is the father character,
the artist and i both feel that it's easier to settle on the main character first, and then fit the rest of her world in. we need time to come up with a good design that strikes an impression on ppl, it's not uncommon to scrap 50 characters, and i think so far we've scrapped 30.
Sunday, December 2, 2007
Music, please
I have managed to add the music and sound code to the demo. It was pretty easy using Playground's engine and I added some classical music and royalty free sound effects to the game. This has enhanced the mood of the game dramatically. I have also created a LUA file that stores the name and paths of the sound files so that a non-programmer can change the sound and music without affecting the code.
As Playground supports only OGG, I had to use Audacity to convert my WAV and MP3 files to OGG for use in the Playground engine.
As Playground supports only OGG, I had to use Audacity to convert my WAV and MP3 files to OGG for use in the Playground engine.
Wednesday, November 28, 2007
and from the art dept
luciola has updates!
oh yay,
luciola has code updates!
some of the 'highlights':
1) everything for a location is stored in assets/loc# where # is the location number.
2) the location bg is always called bg and it's stored inside assets/loc#/images. i tot that made sense cos i can't think of reasons y it shud have many different bgs.
3) the names are all stored in the strings.xml , what happens is if i have to switch location, based on the id, i combine to form a string,
"loc"+id+"name", and store it in my accLocs (accessible Locations) vector. then i create buttons using the same old method.
so now things are more automated now. u press a button u want to go, and i boot up the location with its bg image, and the places that it can go to.
note now that,
1) only the top most button is working. cos i'm sleepy and is KO soon. will add in tmr morn.
2) u see a blank bg first, click once on the screen to make the buttons pop up. will add in the move menu button to do this later.
however, it's not all rosy.
i've got a big problem. detected memory leaks.
luciola has code updates!
some of the 'highlights':
1) everything for a location is stored in assets/loc# where # is the location number.
2) the location bg is always called bg and it's stored inside assets/loc#/images. i tot that made sense cos i can't think of reasons y it shud have many different bgs.
3) the names are all stored in the strings.xml , what happens is if i have to switch location, based on the id, i combine to form a string,
"loc"+id+"name", and store it in my accLocs (accessible Locations) vector. then i create buttons using the same old method.
so now things are more automated now. u press a button u want to go, and i boot up the location with its bg image, and the places that it can go to.
note now that,
1) only the top most button is working. cos i'm sleepy and is KO soon. will add in tmr morn.
2) u see a blank bg first, click once on the screen to make the buttons pop up. will add in the move menu button to do this later.
however, it's not all rosy.
i've got a big problem. detected memory leaks.
Saturday, November 24, 2007
luciola speaks~
ok, so we've sorta got a first puzzle working,
and i must admit that things look a hell load better with pro graphics,
compared to placeholders we got from the net.
even if it's 'ceteris paribus'.
even though something seems to be working,
we've got a lot to do..
settling the story, creating the entire look-and-feel.
and i think the most impt,
the codes structure have to be settled,
cos i really don't know how and what to code sometimes.
well,
things will work out i guess.
and i must admit that things look a hell load better with pro graphics,
compared to placeholders we got from the net.
even if it's 'ceteris paribus'.
even though something seems to be working,
we've got a lot to do..
settling the story, creating the entire look-and-feel.
and i think the most impt,
the codes structure have to be settled,
cos i really don't know how and what to code sometimes.
well,
things will work out i guess.
Friday, November 23, 2007
A mixed bag
I let 2 of my friends tried out the first puzzle today and here are their comments and my observations. (Negative comments have a - and positive comments have a + in front of them)
- Comment was that it looks boring
+ Puzzle is quite fun
- Irrelevant dialog should be cut and only dialog related to the puzzle or other puzzles should be used
- Player was lost with regards on where to click and where to do a mouse over
- Player did not read the dialog and clicked on it rapidly to get to the gameplay aspect
- Something must be done to let the player read the dialog
+ Puzzle gameplay was intuitive and player actually read the information after doing a mouse over on the items and succeeded in combining the items correctly on the first try
+ Player solved the puzzle on the first try and that is due to reading the item description on what was needed to solve the puzzle
- There should be an introduction to the background story for the game
- Keywords in the dialog should be colored red and set to bold
- There should be some animation for the background and the character as it looks too static now
Seems like we are on the right track with the puzzle, but these comments and observations also tell us that we have a long way to go in polishing this game.
Profile of my 2 friends
- 1 is a sales and marketing executive. Age 28 and married. Not technically inclined, but is a game player. Plays games on her PDA on a very regular basis, but never actively seeks out games to play. Only plays whatever games that she can find. Westernized outlook.
- 2 is a TV serial producer. Single, aged 29. Not technically inclined, but plays casual games on a regular basis. Favorite games include Puzzle Bobble, Tetris, Bejewelled and Time Crisis (All share a similarity in that the gameplay is of the pick-up-and-play variety). Westernized outlook and actively seeks out new games on the internet to play. Avoids hardcore games such as RTS, FPS, RPGs etc and those with excessive violence, sex and gore. So no UT or Quake for her.
- Comment was that it looks boring
+ Puzzle is quite fun
- Irrelevant dialog should be cut and only dialog related to the puzzle or other puzzles should be used
- Player was lost with regards on where to click and where to do a mouse over
- Player did not read the dialog and clicked on it rapidly to get to the gameplay aspect
- Something must be done to let the player read the dialog
+ Puzzle gameplay was intuitive and player actually read the information after doing a mouse over on the items and succeeded in combining the items correctly on the first try
+ Player solved the puzzle on the first try and that is due to reading the item description on what was needed to solve the puzzle
- There should be an introduction to the background story for the game
- Keywords in the dialog should be colored red and set to bold
- There should be some animation for the background and the character as it looks too static now
Seems like we are on the right track with the puzzle, but these comments and observations also tell us that we have a long way to go in polishing this game.
Profile of my 2 friends
- 1 is a sales and marketing executive. Age 28 and married. Not technically inclined, but is a game player. Plays games on her PDA on a very regular basis, but never actively seeks out games to play. Only plays whatever games that she can find. Westernized outlook.
- 2 is a TV serial producer. Single, aged 29. Not technically inclined, but plays casual games on a regular basis. Favorite games include Puzzle Bobble, Tetris, Bejewelled and Time Crisis (All share a similarity in that the gameplay is of the pick-up-and-play variety). Westernized outlook and actively seeks out new games on the internet to play. Avoids hardcore games such as RTS, FPS, RPGs etc and those with excessive violence, sex and gore. So no UT or Quake for her.
Tuesday, November 20, 2007
luciola mumbles!
here's the latest i got from our artist yest. i liked the girls on the far right,but gib thought they are all still too young. oh well, let's see what our artist can churn out.
am taking apart all the codes and trying to understand the workflow, and it's my first time doing LUA. and of course first time with playground's engine. the learning curve is not half as steep as some other platforms, but still. grr. i hope gib doesn't haunt me soon. ><
Monday, November 19, 2007
Sunday, November 18, 2007
Different Time Zones
Having finally located our 2 artists, I discovered that working with people in different time zones has its pros and cons and is not a bed of roses as others might say.
1 of our artist is located in North America and there is a time difference of almost 12 hours. With this huge time difference, there is an advantage in that when the artist is working, I will be offline and when I am online again, I can see the results of the artwork in my email 1st thing in the morning. But that is also where the problem comes in, when I see the artwork and need some minor changes and tweaks to it, I cannot get the artist to tweak and change it immediately as the artist would be offline then. So the next best alternative would be to email the artist and seeing the changes in the next cycle.
With game art production being a process where there will be countless iterations before the final product is approved. Small delays in between each iteration of change can add up to quite a large sum towards the end. This is definitely not a good thing to have especially when the schedule is tight.
Right now, my solution is to give the artist as much detail as possible before the game art production begins. This is so that the artist will have all the information and details needed to produce the game art and hopefully, this will cut down on the number of iteration needed before a piece of game art is finally approved.
1 of our artist is located in North America and there is a time difference of almost 12 hours. With this huge time difference, there is an advantage in that when the artist is working, I will be offline and when I am online again, I can see the results of the artwork in my email 1st thing in the morning. But that is also where the problem comes in, when I see the artwork and need some minor changes and tweaks to it, I cannot get the artist to tweak and change it immediately as the artist would be offline then. So the next best alternative would be to email the artist and seeing the changes in the next cycle.
With game art production being a process where there will be countless iterations before the final product is approved. Small delays in between each iteration of change can add up to quite a large sum towards the end. This is definitely not a good thing to have especially when the schedule is tight.
Right now, my solution is to give the artist as much detail as possible before the game art production begins. This is so that the artist will have all the information and details needed to produce the game art and hopefully, this will cut down on the number of iteration needed before a piece of game art is finally approved.
Thursday, November 15, 2007
Development schedule
We have fixed our development schedule and XP and me are in agreeance that this is the schedule that we have to adhere to.
| Week of | Programming | Art |
| 12 nov | Connect with MDA and the artists on the agreed game design process | |
| 19 nov | Standardize and develop features for the game platform | Develop the Concept Art of main character |
| 26 nov | Optimize the features for the game platform | Develop the Concept Background Images |
| 3 dec | Focus on the Generation of game content | Develop the Game Interface |
| 10 dec | Focus on the Generation of game content | Develop the Character in game images |
| 17 dec | Integrate and optimize the game platform | Develop the other game images |
| 24 dec | Integrate and optimize the game platform | Develop the other game images |
| 31 dec | Optimize the game content | Touching up and Optimize the artwork. |
Wednesday, November 14, 2007
Subscribe to:
Posts (Atom)

