Blog for Pisal Setthawong at GarageGames.com

Paddlepop the Pyrata - a Postmortem

Pisal Setthawong — 2008-08-08T07:22:12+00:00

In this blog post I want to take the opportunity to write a little postmortem on the last project I've involved in called Paddlepop the Pyrata.

Paddlepop the Pyrata is the second in the series of promotional games, created by Cyberplanet Interactive, that is done for the icecream product called Paddlepop from Walls and was recently launched in August 2008 as a freedownload (or you could exchange icecream sticks for a CD copy). I was drafted to join Cyberplanet-Interactive as a Technical Lead in the Paddlepop the Pyrata project.

I want to give a litle introduction to the project, some screenshots, before I end it up with the postmortem.

Introduction

Paddlepop the Pyrata is basically a 3D adventure game, in which you control one of the two characters, Paddlepop or Liona to collect 3 special icecreams through 4 unique game worlds so that they can drive back the hordes of the ShadowMaster back. The game is aimed towards younger game players, so it contains a number of irrelevant puzzles that serves just the purpose to break the gameplay and allow the players to practice basic problem solving skills. You can learn more about the game by visiting www.paddlepopadventure.com.

You can download the game directly through the websites at www.paddlepopadventure.com/pyrata/download/game_pyrata.exe (Windows only!).

Sample Screenshots

You can find more randomly hastily acquired screenshots at this url: www.pigcanfly.com/PaddlePop/

Development notes
One of the first issues the team faced was the problem with the short deadline. Our team was given a 2 month deadline to come up with the product by the specification for the CD factory. For a 3D game, that is a very short deadline, so we had to pick tools that we know well and manage the risk. In this project I chose TGE as it answers many of the questions, and I had experience with a similar project (a few of my old blog post talks about it) earlier.

In the production side, there was a number of people. I was the technical lead making the necessary engine modifications and scripting. I had two assistant scripters, one of them worked mainly on effects and dev manager(Phot) and the other on AI(Kong) and have worked on TGE before. Interestingly, we had only 1 artist (Zun), who worked on the gui, models, animation, and cutscene cinematics (6 short scenes) who never worked on in-game art assets. We had a level-designer (Nhum) join later to implement the level design.

In addition to that, we had a soundtrack composer(Mark) and another composer that composed the cinematic tracks. A game design team (Can and etc.) and management team (Orr.) was involved in the general direction of the project and contacted the customer. At the last month we had a very dedicated QA team that helped bugs that were overlooked.

For this project we were asked to make the game run on the most varied computers as possible by not using shader technology. Due to that TGE was quite a good fit, but I could not use the latest branch of my hacked TGE with lots of graphical modification on that. We ended up starting with a vanilla 1.5.2 mod with arcane.fx add on.

Issues of concern
Based on the schedule, we were worried about the art production that might hold up the rest of the production. Based on previous experience, our initial estimate of the art asset would require at least 3 months to finish. To help alleviate the situation, we have informed our artist that it might be a good idea to procure some art contents for level decoration to help lower the art requirements. In addition to that, we had a priority system to list which assets are needed so that as much work could be done in parallel without having to wait for each other. We started on a level by level basis, the game AI objects are done first stage by stage so that the scripters could script the behavior of the object, and the game decorations are sent later so that the level designer could lay down the level next, when the dev clean up the behaviors.

What went right?
- Version Control System - as many people in our team are contract workers, we had to merge content from places to allow work to progress quickly. A webbased SVN server helped us in this aspect tremendously. For example, our artist was happy that he did not have to get out of home when changes are required.

- AssetList and Priority - spending time on the asset list and their priority helped keep the schedule on target as assets are delivered close on plan.

- Our artist is a superman - how did he get it done in time?

- Melee System - we ended up using a customized melee system. As our melee system is loaded in animation, we found that we can fake accurate melee resolution (e.g. like MMORPG games). Instead of the ray-trace or the box to box collision, we just simply modified the explosion resolution algorithm (yes that one in the starter.fps). Simple and effective :P

- Level Design - having a dedicated level designer helps! Luckily for us, our level designer had TGE experience (used to study with me :P), and had great artistic sense. To be exact, he managed to make the game look much better than we anticipated. p.s. great art is more important than techincal excellence in making a game look good :P

- Parallel Development - we tried to parallized the dev process as much as possible so that no one had to wait for each other. This help reduce overhead.

- InGame Tools - We embedded a number of utilities such as spawning and level controls in the game. This allows us to quickly unit test certain AI or game functionality.

- Debug/GameMode Flags - game debugging and mode selection could be easily switched by scripting. This allows easy conversion from a game with debuging tools turned on into a release build quickly.

- Localization process was planned early - we had a rough localization system planned, though we ended up using only pictures for all text resources so that we don't have to worry about consistency. Changing language was easy by using batch files.

- Extensive testing and QA - the QA team found many obscure bugs for us.

What went wrong?
- Time - in 2 months we were able to release a working game based on the features listed in the requirement, but there were a number of bugs that were not discovered. During the QA testing that was done in the 3rd month for the English version, we managed to weed out most of the crazy bugs in the game. However due to the schedule, the local CD version was lauched without a few of those bug fixes though the online download contains most of the fixes.

- QA started too late in dev cycle - We intially wanted the QA to start during the development phase to the end, but it was not granted as it was expensive, and we ended up having the QA process on the deadline.

- Exporting problems - Our team faced problems in exporting certain models for the game. Our artist had a difficult time exporting the models, and one the scripters was assigned to assist and help export some of the tricker models. We had snags with a few models, but luckily we had a few friends at Chiang Mai that helped us, so we lucky :P

- Random Crashing from huge time delta in Foilage System - in the foilage system, it seems that a huge time delta could potentially crash TGE 1.5.2. We had a time test to see how long the game can go without crashing, and it ended up that heavily foilaged levels crashes quite frequently (1-4 hours of pause). Luckily the debugger was there so I was able to make quick patches to that to limit the maximum time delta allowed to fix the random crash problem.

- Minigames are a hassle - we had to work on 4 minigames. They ended up taking more time than on what we spend on the main game play after debugging and all. I would have prefered to spend that time on the minigame to further improve and refine the game play

- OpenGL Issues - I written a short article about my frustrations with OpenGL when deploying in an external website: forums.thaigamedevx.com/index.php?topic=1763.0 . Not sure if you could see it without registration, but could duplicate that here someday. Thought I was getting too chatty.

- Changing requirements - We had a number of major requirement changes including adding an additional playable character, changing fighting system, an online highscore system, and a number of changed minigames late in the development cycle. These changing requirements on a tight deadline is bad for morale and quality. We ended up having to compromise certain features to make things work.

- Bad Documentation - all the scripters had a nightmare working on other people's code. Due to tight deadlines, code documentation was sparse and lacking.

- Resistance to Version Control Adaptation - some people will refuse to utilize version control and practices vary from user to user. Maintaining good usage policies is difficult.

- Compromises - more features + less time = less refinement We ended up having to cut a few corners on refining the game. Some features had to be done before the external infrastructure is ready. As most are very specific, I'll not write about them here.

- No Vista Support - had no time to check it works on Vista extensively.

- Freetime - You must be kidding me LOL

Conclusion
We are happy with the Paddlepop the Pyrata project. Our team managed to conjure a 3D game up in a very short time and it looks pretty good and plays pretty well at the end. My regret is that we did not have more time to polish things up. However as being better versed with the business world, I learnt that is just a fact of life. To be exact as working as a contractor for a while, ego is one to throw out the window as long as you aren't endangering the life of people :P

Regarding the game details, as it was launched yesterday, I haven't got much info of it eiter. Maybe later I'll update this if anyone is interested, though I suspect it'll lack any information people would be interested in :P

Until the next time, ciao!

Thai Computer Game Museum calls for Developers from Thailand

Pisal Setthawong — 2007-08-23T07:42:14+00:00

I just wanted take the opportunity in this blog to PR about a new site that is just recently launched. I and a group of volunteers from the www.thaigamedevx.com community has started worked on a website called the Thai Computer Game Museum (museum.thaigamedevx.com) in which we are trying to archive the games that are created in Thailand or by Thai developers, the game development organizations based here, and the developers involved in each of the project or organization.

We have created an initial listing that is quite broad, but that is no means complete. We are looking for teams, organizations, games that we might not be aware of, and would like to take this opportunity to make a general call for information in this Community. I am aware we have a number of Thai developers using the Torque Platform, which I could name a number of developers like Aun, CMD, PPPstudio, Lumai Prod, and Big Bug Studio. I was wondering if there are more teams that might slipped through? If you know of any, it would be great if I could be given an introduction to so that I could update the site accordingly.

Thanks!

To Script or Not To Script

Pisal Setthawong — 2007-03-15T16:41:16+00:00

Another long ramble LOL

During the last few weeks, I've been in the process of gradually of phasing out my heavily modified TGE v1.4 after my last project has been completed. The project has gone out well, though I have to say due to IP and ownership issues, at times it is bewildering. Anyway since the that project is completed, and things are quite stable and done with, I thought it would be a good time to start upgrading the tools in the arsenal with the latest codebase of TGE v1.5 along with integrating the ArcaneFX toolkit which I find a very interesting addition to TGE.

As my old TGE v1.4 was heavily modified with numerous patches that are done by the community, and along with many of my own hacks, the process to port the existing code into the current code base has quite been a hassle. Let me explain - it has to do with the main question - To Script or Not To Script. In many of the discussions in the forums, there are usually huge discussions on this topic. In many cases, though scripting engine solutions exist, some developers has adviced on implementing some of those modification inside the game engine core to speed up the process. In many senses that is a rather valid argument as what is inside the core is typically magnitudes of time faster than what is a scripting approach. In complex scripts, it certainly makes good sense to implement it in the engine.

Anyway, talking about those modifications, in my old v1.4, I had done a myraid of core changes from jumping, camera, Cg implementations, etc. In addition to that I had a lot of interesting scripting solutions, that includes appending the StaticShape class with many of the behaviors in the AIPlayer class by using scripts. It isn't that elegant, pretty slow, but it does server a number of purpopses the AIPlayer class couldn't do. Well I could go on and on about the different changes, but let me just go to the conclusion.

Regarding the comments on trying to script the least as possible, and try to implement equivalent methods/functions in the core, though it increases in speed, one of the biggest issues that I've faced and I think should be worth a mention would be from the part that it is quite difficult to recall what and where you have changed the core engine. Coupled that with possible changes in the core, getting your new mods into the new engine is quite tedious. Its easy to forget small snips of code that doesn't cause anything diabolic, but could cause irritating bugs in the long run. To give a clue, it was a problem about not commenting the code changes properly, and when the merge happened, some code were missing.

Talking about the issue before, I do think that is quite a good issue to note that do make code changes with care. Keep track of them. At the moment, I have a book noting all the changes done and lines in which the changes are done. In addition, frequent update into a version control system with additional notice is a good thing to do. One last thing that I figured out was that submitting your own resource does help in the long run. Though its easy to think its pretty much a tiresome and thankless task to submit resources, one of the useful things I found is that its a good place to recall what you have done. I did get some pointers from an old resource I did (which I found numerous mistakes later LOL), and it did help alot. So in conclusion, its good to submit resources. I want to just ramble again and comment all the great authors out there.

Regarding the scripts that were used in the previous project, it has been a hell of an easier task to integrate with the new version. As the scripts did not change between the different TGE versions, most of them work directly except those that requires certain core features that were added seperately, or globals that were missing or not used. If there was a good plan in seperating scripts into files, or basically having a good physical file hierachy, things simply are much better :)

Hmm... after a somewhat long rambling, what is my conclusion? As usual, I like to say if you have to pick between black and white, pick grey. Why? Its better to be flexible and appreciate all the good things each extreme of the solution brings :)

Oh well, after a long blog, how are things going along? More of the same. I'll just list out a few things:

1) I've finished upgrading my TGE to the newest with the feature list that I need for the next game. I'll probably post the screenshot sometime when the first few mock scenes of a few new planned game. Nothing earth shattering, but anyway, I'll keep the community updated about strange new quirky things I'll be up to. As noted, I'm a peculiar person, and I guess it can't be hidden :P

2) written a small graphic engine that I plan to use when teaching Computer Graphics next semester. Its made out of SDL, OpenGL and I'm planning to add shader support, though I'm still divided between supporting Cg or GLSL on it. Nothing big, but I just wanted to repackage the code to make it easier to explore the different algorithms and steer away from GLUT. Looking back at the few days of muddled programming, it was exhilarating, but I still wonder is it really worth doing it LOL

3) Finally received some funding for extending my lab. Finally! I'm pretty irked by using old outdated computers.

4) Finalized plans to study for my PhD, though still planning between accepting the scholarship (and being tied up to the university) or either fund myself just incase a future opportunity knocks on the door. I don't know why I should bolt the comforts of the academic world, but... who knows :P

Hope things on your side of the world are doing well. Keep updated!

A Game Down and Another Year to Go

Pisal Setthawong — 2007-01-11T18:01:13+00:00

This blog is a long, rambling, and useless blog detailing what I'm planning next year. I don't think it is much of use, but if you are going to read it, I have to caution all readers before. I have a habit to go on and on and on, so bring a long a pillow and enjoy a comfortable sleep through the blog!

How are your New Year?

During the last New Year, I was busy at home finalizing, debugging, and adding the finishing touches to my game. As you noticed, I don't have a life. On a curious note, if you have a day job, and you have game development as a side-job, I wonder how much life would that person have. I guess most people on that area would agree with me :P

you can find more details about the game in my previous blog.

Based on the new changes that are done that are significant is that we completely overhauled the whole interface system to use the real interface instead of dummies, finished up a few new levels that were missing during the last blogs, added more NPC scripting, finalized the sound effects/music/cutscenes, and redesigned the levels by adding more gameplay elements to help new game players. All that is left now is to wait for the final approval from the committees (which are rather pleased during the last meeting), and we would be able to finally end the project when we install the game to the computers for the kids to play.

It is quite difficult at times to look back when the game is done. Though making a game has its up and mostly down points, when all is done, it feels much like when a daughter or son leaves the home - not that I have any kids, but just the analogy. The many sleepless nights and days. The many arguments and critique with animators and artists. The many anticipation in the hands of the approval committee. Strangely it seems so surreal... Can't figure how to say it to words when a project that has been part of the life for the better part of the year is suddenly over.

So what does the future hold? For all I can say is that at the moment, one game down and the future is there to behold. What to do next year? Though I'm still planning, I got a few ideas up my head.

The first thing that pops into my head is that I'm thinking about writing a localized book on TGE with another local partner. I do think this would be an interesting idea considering that I've managed to accumulate quite a knowledge of this system based on the last game, and coupled with the increasing number of people interested in TGE in my country, it sounds like a good combination. As most readers have language barriers, especially many newer and less experienced developers, it sounds rather feasible and probably would help add to the community. At the moment, it seems there is like me and Aun from my country posting here from time to time. Could have a few more people you see :P At the moment, I've drafted a rough outline of things that I think would be of interest, and did some preliminary background work.

Secondly, I've did some talking with a number of different places regarding the future game development project. As I can't afford to hire a full team to work over an extended period, at the moment, I should continue to save up money until the opportunity arises again. So at this moment, I'm interesting in partnering with other teams as a free-lance contract developer again to add a few more games to the belt and in the same time have fun from making another game(if you notice, I'm trying to pick some project that is not mundane and repetitive). From a number of talk with contacts and people, it seems highly probable that I would be working on another TGE game as a partner/developer in another company. The project is quite interesting, and I can't wait to start it. At the moment waiting for the requirements and advanced stages of negotiation over details over the project. Once things are done, I'll update more here along with new and exciting progress of the project (I hope).

One other area that I do want to do this year to work on a few more research papers. During the last year, I had been working rather hard on side-jobs/volunteer work that I didn't publish any paper. The bad part about doing research is that it is expensive, and in my area of the world, research work is not adequately renumerated. To be exact, you lose money for doing research, and that isn't an ideal situation I suppose. Since I've been smirking here for a while I'm feeling guilty. However with some money saved up, I think it would be a good time to resume this activity. Though doing research is mostly a money losing enterprise, at least I should take the opportunity to use traveling to these conferences like a holiday since I hardly go on one X'D On a short note, researching is pretty fun also :P Anyway, not sure if you are interested, but the next stop I'll probably be going is at the GRAMM2007 (The 3rd International Conference on Computer Graphics, Animation and Multimedia (GRAMM2007)), and it would be held in Khon Kaeng, Thailand during May 2-4. For more details visit the temporary website here: zeus.cp.eng.chula.ac.th/~pizzanu/GRAMM2007/

One other thing that I plan to do is to find a place to finally start my PhD. Its been a while working and getting to preoccupied with my work that I differed my study plan for years. Maybe its time to finally take a look considering I don't think I would be moving from the academia area. Hmm... needs to take some time to look around and decide on this. Money is an issue though. I'm a poor boy :P The only scholarship that I can get my hands on are those with slavelike conditions after graduation... Hmm... Or should I just defer it again? LOL

Other than that, I hope to be able continue to work on my secret new game. Nothing of much interest. Its been brewing and differed for too long. I do think game developer might have their own pet project hidden somewhere just waiting for the right aspects to fall in place before starting work. I have that predomination for a while. Maybe I should finally take the time after all of this to finally continue work on it and dust it out of the closet :P

A few new skills that I want to learn is to understand meditation and yoga techniques better. During the work of the last game which was religious, cultural, and traditional by essence, I had come into contact with more and more religious texts especially on Meditative and Yoga areas. Though I'm rather cynical by nature, I have huge respect for the ancient mediative and yoga techniques that defy modern scientific thinking. Sounds silly, but hey, I'm interested in that :P

So after all the year's plan, there is one thing left. I forgot to ask Santa for a present during Christmas. I think I'm a good boy. TSE/TGEA v1.0 please :D

p.s. Just Joking. A Belated but hopefully not too late Merry Christmas and Happy New Year!

HeavenHell Project - Updates and MoreScreenShots and Random Rants

Pisal Setthawong — 2006-12-01T16:22:09+00:00

I just wanted to update a about the progress of my game after disappearing for a few months after my last update on it. Been extremely busy during the last few months due to work related issues that I nearly thought that I had to visit a mental institute for insanity reasons. I tried this Executive Stress Pills, and it works well - though I have a qualm that it might be a placebo. Anyway since I'm here alive and able to blog this thing, at least I know that I'm holding up alright.

Talking about another side issue that is really trivial, I actually completed a multipaged-blog before this one yesterday, but somehow the blog never appeared! I'm starting to suspect that there was a session timeout and it caused my entry to disappear from the server, but I wasn't warned about that :( I just have this hunch if I'm going to stick on the submit resource page typing out the entry, I shouldn't take too long, or finish the entry somewhere else. Having a long rambling resource submission or blog post gone really is irritating. I don't blame anyone, I should have know better to backup the post before I submit it.

Anyway, back to the topic. Just to summarize for any readers (who unfortunately stumbled in this blog), my current project is working on a game that deplicts the Thai Traditional version of the Three Realms which consist of the Human world, Heaven, and Hell. The game covers only the two realms of Heaven and Hell. The game is basically a 3D Single Player Platform game. At the present the game is mostly finished, just waiting for finishing touches, finalizing the interface, finishing up the Video Cg for the game, and the QA process. This should take up to near Christmas when it should be ready for release.

For this game, I had 2 major unique engine modifications that I've done. In a few of my earlier blogs I've mentioned about the overhauled jump system to make it more like a console like platform game and my NVidia Cg enabled TGE in which I used it to create Image Filters for my game - though I was talking mainly the Glow/Bloom filter that was used most to get a more surreal feel for the game. In the post mortem in the next blog I'll post, I'll talk more about all the modifications in details including some of the other modifications recommended, additions, and fixes and recommendations. Don't know if it would be useful, but anyway, its at least my first start.

I'll attach some random screenshots here:

Other than that, I've just saw the CutScene and I am pretty much surprised that it turned out extremely well! This started out as a economy budget game, turned out to be much better better than I ever imagined. That is the joy of having a animation house behind the team :D When you have an animation team that wants to outdo the programming team, and visa versa, it becomes a great incentive to really do much more than you planned ;)

Since I haven't finished capturing and converting the video, I'll update that on the next blog.

Another short plug. Tommorrow, I'll be hosting the 3rd Game Developer Exchange Conference 2006 (http://www.gdxcon.org). If you happen to drop by the area(Developers in the Bangkok), please do drop by. Its a event that would be fun for developers. Its not that often that introverts get the chance to meet each other :P

One Last random thought. I've just ordered a EWI (http://www.akaipro.com/prodEWI4000S.php). Can't wait to get my hands on it :)

Hmm... this is a complete messed up blog LOL

Asian Game Developer Summit @ Singapore from December 9-10, 2006 and Etc.

Pisal Setthawong — 2006-10-30T09:35:07+00:00

During the last few weeks/months, I've been very busy with a number of different things, mainly teaching, working on a contract job writing video games, and arranging a few seminars related on the same topic.

Anyway, I just thought about taking a short break from the crazy work schedule, and just take the opportunity to PR about an event called the AGDS (Asian Game Developers Summit) which will be hosted soon. This event would be of interest to game developers in the Asia (especially SE Asia), and is highly recommended for developers in this region. If anyone happens to go there, do drop me a email, and we'll see each other there. I'll be visiting the event also :)

Quote:

Asian Game Developer's Summit 2006
Singapore December 9-10, 2006
www.agdsummit.com

The Asian Game Developers Summit is the Asian region's premier meeting place for computer
games industry professionals from around the world.
AGDS goals are to:
- Showcase and promote Asia's talent and game titles
- Assist professional development through hand's-on Master-classes from some of the
world's leading developers
- Assist industry development by helping local developers build successful titles and
businesses
- Assist market development by putting developers and producers into direct contact with
publishers and distributors

We have a very simple motto: "By Game Developers for Game Developers". Our grassroots
involvement in the regional industry gives us the ability to pinpoint specific tracks and discussions
of relevance to game developers here and worldwide.

AGDS 2006 features keynotes from some of the world's and region's most influential and creative
developers. It will contain: a strong Game Development Track; a Serious Games Track; and a
host of other important Creative and Business threads.

There is also a strong emphasis on the social and networking opportunities to enable developers
from the region, and potential business partners from all over the world, to meet and explore
opportunities together.

With serious growth in the Asian Games Industry, AGDS 2006 is the one place you can make
yourself part of the action

Confirmed Speakers and Tracks:
www.agdsummit.com/speakers.html
www.agdsummit.com/tracks.html

Price and ordering:
Location: Orchard Hotel [Ballroom 3, Lavender and Nutmeg rooms, for a total of 3 parallel tracks]. 9th - 10th December
Pricing: www.agdsummit.com/price.html
Ordering: www.agdsummit.com/reg.php
Hotel: www.agdsummit.com/venue.html

Sponsors:
Government Partner: MDA
Presenting Partners: EA, HP

What's outstanding?
- Driving registration.
Early registration - ends on 1st December 2006
* Early-Bird @ SGD150 per person
* Student Rates @ SGD130 per person via discount code
* IGDA Rates @ SGD130 per person via discount code
* Previous Year Attendee @ SGD130 per person via discount code
* Group Rate @ SGD100 per person (10 Pax & Above), Please pay by check for bulk discounts.
Make sure all payments are received prior to the discount period or you will be charged full price.
Registration on event days
* Regular Rate @ SGD200 per person
* Group Rate @ SGD150 per person (10 Pax & Above), Please pay by check for bulk discounts.

Another event that I would like to PR about is our own game development seminar called the GDXCON (Game Developer Conference Exchange, on its third year), and will be held in Bangkok on December 2, 2006 at the Hall of Fame - Assumption University (Final Details and an updated website (www.gdxcon.org)will be posted up soon). Topics this year will focus on PC Game Development, and our track topics include a discussion of different game engines by a number local developers, an overview console game development, and a topic on Game Art. Details of speakers and topics would probably be confirmed in tentatively by next week, though if you are interested to contribute, please feel free to email me (pisalST ( a t ) gmail.com) as we are currently looking for tentatively one more developer to join the panel on the discussion on different game engines and a speaker for the Game Art part. Since this is a local event, most of the sessions would be conducted in our local language Thai. It is a low budget no frills type of event, but a great place to meet, talk, and discuss issues with fellow game developers in our locale. Attedance is free :D So if you are developer located in Bangkok or close by, feel free to pop by :)

The last topic that I would like to ramble is that the game that you saw in my earlier post, is quite close to finished. I'll be posting more details included updated screenshots from the game soon in my next blog post. Hopefully it won't be many more months, but until then, ciao!

My Cg Update and Random Musings

Pisal Setthawong — 2006-08-07T06:47:25+00:00

During the last few weeks/months (lost track of time since the last blog), I was kind of busy in a myriad of projects that is practically taking up all 7 days of the week. Working that hard isn't a good thing, but considering I'm putting my hands on practically too many projects, there isn't much to complain about. When all of it ends, and I there is a lot to look forward to.

Anyway other than that I just wanted to update a few things that I've been up through between all this time First of all my Cg musing with TGE is going along well. I initially started out due to a customer musing about the look of the game, so they wanted a visual upgrade, in which I implemented Cg to do some postimage processing which I started out with Glow. During that time I had the chance to talk with Paul Jan another developer who has started his own Cg project approximately on the same time, and on a sidenote he has a resource on CG Dynamic Gamma & WaterUpgrade at www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=1083.... I think many peeps would be interested on that project.

Anyway on my side, I went on to work more on creating a small framework for making image filters in Cg for TGE. I planned to make it to have dynamic loading and unloading of cgprograms that will create a filter effect on the postprocessing side, much similar to the photoshop filter idea.

When meeting with my customer the last time, there was a discussion with the Hell Expert who wanted Hell to look extremely dark, which I and my art director didn't agree. I do agree Hell should be dark, but as the game was marketed for younger players, I didn't agree with that. As not to waste too much time asking the artist to rework with all the texture arts in the game again, I decided to quickly write up a new cg program that basically darkens certain shades of color. The results are below :

As noted it turned out the Hell Expert hated it, and we managed to stick with our own interpretations :P

Anyway during this time, as the game is getting closer to the beta stage, I decided to stop for a moment and focus on bug fixes and slight optimizations in code which is taking most of my time at the present. On a short note, I remember I tried to submit the resource of Cg postprocessing filter, but somehow it disappeared. I have a hunch I must have submitted it improperly O_o

In other related ramblings, there are a few things which I've wondered upon on a long while:

1) Why not six degrees of free in the Free Camera mode of the World Editor?

I was talking with an friend who was an architecture/3D artist who asked me when he saw the World Editor why was it so difficult to use. I know that the side, front, top view is better suited for people with background in this field, somehow after a series of discussions, one of the things that slipped out was, why didn't the camera in the free camera mode was offered 6 degrees of freedom? In 3D systems in the preview mode, the camera was supposed to move left/right forward/back and up/down. Strangely enough, there was no up and down, it couldn't move in relative to the height (z axis in TGE or y axis in the typical coordinate system). Hmm... No answers, so I just simply editted the creator/editor/editor.bind.cs and added the following:

//Add binding for moving in 6 degrees of freedom in editing mode
EditorMap.bindCmd(keyboard, "q", "moveup(1);","moveup(0);");
EditorMap.bindCmd(keyboard, "z", "movedown(1);","movedown(0);");
WorldEditorMap.bind(keyboard, "q", "moveup(1);","moveup(0);");
WorldEditorMap.bind(keyboard, "z", "movedown(1);","movedown(0);");
TerrainEditorMap.bind(keyboard, "q", "moveup(1);","moveup(0);");
TerrainEditorMap.bind(keyboard, "z", "movedown(1);","movedown(0);");
AIEditorMap.bind(keyboard, "q", "moveup(1);","moveup(0);");
AIEditorMap.bind(keyboard, "z", "movedown(1);","movedown(0);");

Since a normal character can't move up or down in my game, there is no need to check if the view mode was the free camera mode. Hmm... Now that is easier to use the World Editor. I wondered why I never thought of that before?

2) Scripting Languages that doesn't require the programmer to declare variables can potentially cause Bugs that are Hard to Detect

During my programming, I was quite alarmed to see that there was a huge lag at certain parts of the game which was happening on periodic occurrence. After trying to optimize many parts of the game, the lag was managable, but it spiked again after adding a few features. So after some miss and near hits for a long period, I later found out after debugging and going through the trace of the program that it was caused due to a stupid mistake, which was like this:

function doSomething(%this)
{
cancel( %tihs.lSchedule );
}

If you noticed, the cancel function is used on %tihs instead of %this which in turn doesn't cancel the scheduled event and continues to operate as there is another function that repeats the schedule over and over again. After a while, it turns out to cause numerous lags in the game even though supposedly the logic is correct. As noted, a good lesson learnt on having to make sure that I double check if I use existing variables with the correct identifier or not. If not, it can potentially cause huge problems in the longer run.

3) Unicode works fabulously, but is there more documentation on I18 ?

I've been testing TGE with unicode extensively during the last few weeks regarding tools and utilities. At the end of the day, I found TGE has good Unicode support and can work seamlessly with Thai characters. I've tested also changing the fonts by editing the font image dumps to create altered fonts which works perfectly! I have to say, its really nifty :)

Anyway on a side note, I haven't found much info on using I18 on the scripting side. There was a number of references there on using that as the language tables, but I ended up working making my own workaround with my own language table - which is like reinventing the wheel. On a slight note, I was wondering if there was more examples on I18? Hard to find incentive when there is a solution on place, but I am tempted to explore it sometime in the future when there is more free time starting on exploring the core engine scripting interface on that part.

Oh well, that is just a little that crossed through my head the last few weeks.

Working on Implementing Glow Effect (Cg) on TGE

Pisal Setthawong — 2006-06-14T18:20:39+00:00

During the last few weeks, I've been working with proping up my TGE so that I could use Cg to prop up the graphical engine. I'm completely aware that TSE would potentially be a better choice if I wanted to use Shaders, but as the project I'm working on is rather crucial, I need to be sure the game could be delivered as promised. That is why I stuck with TGE and tried to do the best with what tools I had at disposal.

Let me show you the original game screenshots that I've used TGE in:

I do find the results to be pretty decent. Though not state of the art graphics, it wasn't shabby, and looked good to my early trial with a number of casual game players (relatives, friends popping by my home :P).

After presenting that to my customers, I've found the major comment is that they wanted the scene to look more surreal. After talking through it, they wanted some sort of glow effect to make the scene look unreal or like in the game scenes from heaven or hell. Though I attached lights to my player character, that light wasn't enough glow.

I had a few workarounds that I thought about doing. The major problem is that I can't implement things that require too many CPU cycles considering the huge demand at the present. The first I thought to do was to was to add particle effects to the player. That was kind of taking the focus off the point I didn't implement the glow-effect. The other is to double render the player and use different blending options to get the player glow. This method requires more rendering passes, and since the current game is extremely taxing on the CPU/memory, I've decided not to do this. I remember I used to use the DRL resource, and I liked it extremely. However as my game is already using too much CPU, I didn't think I should use it with this project. The last idea that came to mind is to use Cg to implement the glow effect. This is an ideal solution as it places less stress on the CPU as the extra processing is sent to the GPU.

On a side note, I could always simply ignore the request, but since I had time (was a few weeks ahead of schedule) I decided to try to experiment by adding Cg support to TGE.

The first part of was easy. Integrating Cg to any program is easy. There are many resources that point to that in the Internet. I myself also did write a few DirectX + Cg programs before. The next point is to write some vertex/pixel shader programs to create the glow. In this part I used to work with my own Glow effect in RenderMonkey before so that was a huge help. On a sidenote, there are also many useful resources that is useful on this topic and the one that I liked was from the following url: (collective.valve-erc.com/index.php?go=tron1). As I had some parts of this done already, the rest was for me to figure a way to merge it with TGE which seem quite a difficult task at the beginning.

During the first few days of implementing, I had a torrid time getting things right. At times, everything crashed, at times I get things opposite of what I wanted. As noted, the following picture shows alittle about some of the things gone wrong:

After a little more probing, I managed to fix a few more things, though unfortuantely I had the whole picture oversaturated instead of making it look like glowing. Also there were many rendering problems like when the scene became too saturated, the characters all disappeared! Now that is what I call bad programming on my part :P

However after a period of debugging, and going through the rendering engine TGE, things were dawning. The TGE rendering engine is rather decentralized so it takes some time to go through the different parts of the engine to find what I wanted. Anyway, after another sleepless night, programming along with watching the WorldCup, somehow I managed to get things alittle like what I wanted.

From the last pic, there is a slight glow effect with the whole scene which is basically the effect I wanted. Though the effect was created, I don't think it is adequate yet. I believe I need to tweak things comprehensively to make it look better. However, I was more preoccupied of getting things done than actually making it look good since the start, so I guess within the short period of time, that was good enough :P

Anyway, for the future plan, I think about making the Cg support tool I use a little more customizable as I would have to create 2 major themes for the game (heaven scene and hell scene) and it won't be the best of idea to hardcode everything when I need to change parameters and shader programs for every stage.

Thinking about it, I haven't been putting much thought in that... and my code is a freaking mess, much like a huge bandage wrapper attached with chewing gum to the Torque engine. Hmm... that isn't good is it?

I got to think more about it soon, but considering the Germany vs Poland match is starting soon, I guess I'll postpone that to sometime in the future :P

My Viewpoint on GarageGame Products

Pisal Setthawong — 2006-06-07T04:16:39+00:00

During the last few months, I've been a regular visitor of the GarageGame website, coming on a daily basis and mostly going through the forums and code base. To mention a little about myself, I first bought the TGE back in 2002 because I thought it was promising 3D engine with a number of AAA titles. One of the evaluation criteria with me in using Engine is to pick some Engine with proven credentials instead of looking only at demos - in which I have to say was partly due to being somewhat duped in another game engine that I bought earlier.

In my first trials with the TGE, I thought that TGE was only suited to make FPS games based on the demo that came with the earlier versions of TGE. Since what I planned then was a completely different game than a FPS, I stopped using TGE a few days after I bought it and went to other engines. I thought that TGE was mainly used to make FPS and wasn't that flexible (as you know it, I was completely wrong then), and the documentation, oh well was rather in pieces there. After that, I was dabbling with C++ alot and much later I enjoyed using the Ogre3D engine.

However back in April of this year, one of my customers was asking me to develop a game for them. It was a simple 3D platform game about the virtues of heaven and hell. However their artist only knew Lightwave, and I was in a fix as Ogre3D has a load of problem with the Lightwave exporter. After going through the details of Ogre3D, I've found that the Lightwave exporters are either broken or doesn't have complete features that will allow us to get the Lightwave models into a format the engine can use. There were a number of solutions. The first one was to fix one of the exporters to make it work. Another was to write a new exporter. The problem is that I don't know anything about Lightwave at all, and doing that would be a mammoth expedition considering my own limited knowledge. Since I had only a few months to get the game done (including most of my artist team members provided by the company were all new to game development art), I had to quickly change to another engine. After consulting with a few colleagues, one of them pointed out to TGE, which incidently I had, was Lightwave friendly.

One of the pleasant suprises was that I found my account was still around even after nearly 4 years of inactivity, and I could download the TGE like I did before without any hassles. After going through an early prototyping stage and documentation, I was geniuely surprised to see that there were vast improvements on the documentation, forums, and etc. One of things that I've always liked more than computer based documentation is hard books that are good for the sore eyes. As I needed to quickly get started on an unfamiliar engine, I quickly bought all the books about Torque.

I got 3 books, the first was Kenneth Lay's Beginning 3D Game Programming All-in-One (Torque) which I found a little too sparse for a programmer. As myself have some experience in the game development pipeline, I think some of the chapters regarding making art are not really needed as we have artists, but thinking about the intent of the author, which wanted to paint a complete picture so that a one man studio can emerge. Unfortunately the first book was dated that many things had to be changed to make the examples works. Regarding the second book in the series, the advanced book, its a great supplement to the first book on a number of sparse topics. The last book I got was Game Programmer's Guide to Torque by Edward F. Maurina III which I liked alot. As being on the scripting programming side, that book was an invaluable help in finding more information about the quirks and naunces of TorqueScript and TGE in general. The only complaint is that the index is unfortunatey sparse. This makes it hard to make quick references to the book. I ended up posting postIt notes no various pages on different topics to make lookup easier.

The web references are unfortuantely disjoint, but at the end of the day, after getting used to the google search function, I've managed to find alot of material that I needed. That was a welcome addition to the site since last gone. The Torque Developer Network (TDN) at the moment might seem a little sparse, but looking through it, I do believe it could organize information better than the earlier forum/resource system.

On my dabblings for the last 2 months, and finishing most of the early groundwork for the game, I have to come to appreciate TGE. As I'm a huge believer of the scripting approach, I found TorqueScripts to be very intuitive, useful, and a powerful tool. Adding new console commands are also easy in TGE, and with that I've managed to add a few useful console instructions to my own TGE. That is the great part about getting the source code of the engine - it allows flexibility to add custom things to the engine. The hindsight is too much customization can cause problems, and that is rather true considering I did a few dodgy changes with the engine causing numerous new bugs LOL Another issue is that some documentation on lesser used features such as Unicode and Joystick support is not mentioned enough, and finding information on those is rather difficult. Though I liked TGE alot, there are a number of issues that I felt is a drawback. I'll list a number of them down:
1) Multiple KeyBinds isn't allowed though at times I think it might be useful
2) Debugging is difficult at times with Torque Script as TGE ignores errors in the scripts and runs with the last compile version. One useful thing that could be added would be if it was possible to provide summary of errors/warnings at certain parts of the runtime to a place. One of my early mistakes was that I didn't know I made a syntax error elsewhere in my script, and cause changes in other parts of the file not to reflect on the game as using the older version.
3) The graphical engine is unfortunately rather outdated. In this case, it is expected, but using the Synapse Lighting Kit or the DRL resouce here could help prolong the use of TGE. In an early demo of my game against a direct competitor that used Shaders, the customer liked my version more, and all it has to do with graphical direction. On a hindsight, I bought the TSE because I thought I needed more graphic capability, though I decided not to utilize it for this project. (I'll talk about it later).
4) The particle system and adding new objects causes delays in the system that might be significant. Heard there was a memory leak in the particle system based on one of the forums, and plan to patch that up soon.
5) It takes time to understand the TGE architecture that is based on Client and Server model. Due to that system, many people find it excessively hard to understand the system - especially newer programmers who want simple single player games. However on a hindsight, I get to appreciate the system as it does force programmers to think differently in making the game. I mean who knows when you want multiplayer support and at the end you got to change the whole architecture of the game? In TGE the worry is less as I'm forced to rather do that :P

I'll be working on my game project for the next 2 months. After that, its time for planning something new. Got new classes to teach then, but I do fancy working on another game. I haven't really thought of something up at this moment, though I've been looking at TGB (Torque 2D) and TSE for my next project. Based on my short dabbling on both, I've noticed both of them are still in the Beta stages, and by my own experience with beta software (Thank you Micro$oft for all the blue screen betas :P) I learn not to use Beta software for projects that need to be deployed due to the huge possibility of failure due to errors that are beyond our reach.

For TSE, I've bought the early adopter release because I got it because I have trust in GG. If they could keep my TGE account for 4 years even though I haven't visited them, I have to admit I do think that they could do the same with TSE :P Anyway, back to the serious part. On my own usage of TSE, I remembered that I was highly hooked on the Goblin(or what do we call that dude) sample and its detail so I just bought it. However after buying it, I just noticed there were no shadows in TSE, how could I overlook that detail? Anyway since TSE is lacking a few key features (like the example of shadows earlier), somewhat less documented than TGE, I didn't use TSE for my earlier project and decided to play safe. What would TSE be? I don't know. By the looks of it, it did seem delayed for a while, but as usual, which software project was not delayed? I'm a patient person, so I won't mind going off doing something else and later coming back to use TSE some years in the future when I have a project that requires TSE :P

The other product that I've bought and used was TGB, which I just got a few days ago. Since I was used with the Torque architecture, TGB was extremely easy to use. It was easy to make 2D games, like the GameMaker software, though in this case, I felt more comfortable. Since I didn't use TGB that much I don't have too much comment on it. The main concern is when I'm using my notebook instead of my desktop. Since my notebook is rather aged (Centrio 1.4 GHz, with 768 MB RAM), one of the first problem of TGB appears. TGB is a memory hog. Using the simple Fish Demo requires ~160MB of the system RAM causing the slowdown of the whole system to an unacceptable level. On a hindsight, my game created with TGE which is a memory hog due to the artistic director's demand for excessive amounts of objects in the scene takes less memory! Having a too memory requirement for a simple 2D game is not acceptable considering that most 2D games end up being casual games. In the private forums there was talk about the memory requirement, and it seems this issue is still being worked on. Anyway since TGB is in the early stages, I don't have too much complaints. I don't complain about beta software because I expect them to be broken. I use beta software because I want to evaluate the software and so that when it is finally released, I can get a headstart.

All in all, that sums up my long and rambling post about my own experience with the Torque Experience. Its personal, its long, its rambling, but hopefully it could be useful other a simple rant. For older more established developers, I apologize if you read it :P For newer developers, best of luck! Torque isn't hard as you think if you try. Took me a month from nothing to learn TGE and strip down the FPS example into a 3D platform game. There are also books on the topic, a google search form, and the rest is just dedication and just simply pure hard work. Talking about it, I just seem to like preaching what I like to say in the classroom :)