I took a break from coding my game for about 6 months and recently got back into it. Since then, a new version of texture packer was released. Everything seemed the same, but then I noticed that no matter what I did with anything made with the new version, my app would just crash with a SIGABRT error. No good. The code would work fine with the older spritesheets that was made in the past, but nothing new.

After posting on the cocos2d forums, one of the developers for Texture Packer actually helped me out. It turns out using Autosize will make your textures/spritesheets not be the power of 2, which they all have to be. With this, it will just throw the error and you have no clue why.

Look out for that little error! In Texture Packer, you may be enticed to use it since it cuts down on the size. However, it may throw you into a tailspin. After emailing the developer, I asked why would you have this option and this was his response:

You can enable NPOT (non power of two) for newer devices in the cocos2d settings.
Should work on iPads and iPhone4. I think it’s new in cocos2d 1.x

I guess you can use it, but you just have to be careful in what scenarios you use it in. Also, if you are looking for a tool to help with managing your sprite sheets, I definitely recommend purchasing Texture Packer. There is also an evaluation version you can use to make sure it will do everything you need.

Hope that helps if anyone runs into this problem!

One, I do not like the developer tools. A lot of it has a rushed feeling to it and just does not give a solid feeling. If you want to make apps, use the unstable eclipse plug in…. or Ares… why not. If you want to make games using the PDK, use visual studio in windows or xcode on a mac. On top of that, there is a whole other SDK coming out to replace mojo. All of this makes it difficult to 1. easily develop apps or 2. Have a mature development community. It’s pretty annoying to run into a problem and not have anyone run into the same problem and no one really there to help out.

This being said, I have decided too make the jump to doing iPhone games. I know the market is already flooded with games for the iPhone, but with the matured community and tons of existing and proven frameworks, it is something I have enjoyed thus far. It has been a bit of a learning curve for me considering I havent done any objective C programming, but I am slowly learning.

Anyways, I want to try to keep up a daily blog of my learnings, goals for my game, etc.

Looking forward to more posts!

From the product description

Word Jumble is a great and addictive game that will keep you coming back for more! Unscramble the jumbled words to reveal the secret keyword at the bottom. Over 5200+ possible words! Play against the clock or at your leisure. Think its too easy? You have 3 different times to test yourself against. Not sure what a word is? Use the hint feature to give you a hand. High scores for both Timed and Normal games!

Please feel free to leave some feedback, good or bad.

Thanks!

Well that didnt take too long. I would like to do a few more updates (difficulty level settings, global high scores, etc) so hopefully that wont take too long to get those updates out the door. If you experience any problems with it, please email me at marcel@codeofdoom.com

Thanks!

I would like to add difficulty levels to the game in the future, as well as a ‘continue’ feature.

I will keep you posted once the app is approved or not.

Cya then!

The reason I haven’t is that I decided to get my mind off of it by making another Pre game. This one is much more recognizable, which is Simon. Yep, that game that you played with you were like 8, with the 4 buttons and you have to repeat the pattern. Anyways, it is in version 0.5.04 at the moment. I still have some things to work on it though. The pre does not seem to handle audio very well though. Almost as if it is a delicate flower.

Anyways, if you want to check out the updated game and simon, here you go!
Simon v0.5.04
Five or More v.0.7.25

Also, I do plan on doing some WebOs tutorials in a bit, so stay turned!

I also fixed an ‘undo exploit’ where you could keep undoing and waiting for the right piece to drop in the right spot.

Anyways, feel free get the updated version

http://predev.wikidot.com/installing-apps-on-a-stock-pre-post-1-04-update

And here is the game:
http://www.codeofdoom.com/fiveormore/com.codeofdoom.app.fiveormore_0.5.0_all.ipk

Some screen shots:
Screenshot 1
Screenshot 2
Screenshot 3
Screenshot 4
Screenshot 5

Things on the todo list:

• fix bug that doesnt let you move a piece to a certain spot
• Sound (sound from moving. maybe ambient music while playing?
• Add a background
• Add “special pieces”
• Add achievements
• Change the scoring around a little bit

Of course, if anyone wants to give any feed back on the gameplay, let me know. I also already want to rewrite this app. This definitely started with something where I was learning javascript, but definitely not applying best practices. Soon I will be picking up a few books to help out with that. I do have a few other ideas for games to create, so keep an eye out .

ps
Although I am sure many of you have heard, Palm made the SDK publicly available. So feel free to check it out.

]]> http://codeofdoom.com/wordpress/2009/07/17/palm-pre-game-5-or-more-v-050/feed/ 1 http://codeofdoom.com/wordpress/2009/07/17/palm-pre-game-5-or-more-v-050/ http://feedproxy.google.com/~r/CodeOfDoom/~3/bLHlz_YiJHA/ http://codeofdoom.com/wordpress/2009/07/09/so-where-have-i-been/#comments Thu, 09 Jul 2009 19:46:52 +0000 Marcel http://codeofdoom.com/wordpress/?p=520 Any regular readers of this blog probably took not that I went from posting one of two things here a week to posting nothing for about two months. Maybe I cursed myself by writing the article Why do our time estimates suck, because I am finally wrapping up a project where the estimations just went down the crapper. I did learn another lesson though about why estimations suck, and that is being on a project that its entire life cycle (IE, planning, development, testing, regression testing, etc) is a massive discovery phase.

This basically boiled down to those who were in charge of pulling the data down were not aware that what the client was asking was either a)something different or b) next to impossible given the dataset. No one knew it at the time, so everyone just found out as the project progressed. Luckily the blame of that was not on our plate, but it did affect our ability to get the job done in a sane manner. However, the project is “done”, so hopefully my schedule will go back to something more reasonable and I will be able to contribute more.

In the mean time, I did end up picking up a palm pre and actually got invited into their pre SDK development program. I have been messing with that and I have started working on a game called 5 or more. The gray pieces are “open spots” where you can move the colored pieces to. You have to have a clear path of open pieces when you move a piece from one place to another. Each time you move a piece, 3 more pieces will drop. Once you line up 5 or more of the same color, they will change into open (gray) pieces. Here are some pics of it so far:

5 or more picture 1
5 or more picture 2

Its pretty close to being completed. Once it is completed, I will be submitting it to the app catalog, so hopefully I will be able to be part of the initial wave of new apps .

In the future, I would like to start posting articles about developing for the pre, but I would like to get some more experience with it first.

]]> http://codeofdoom.com/wordpress/2009/07/09/so-where-have-i-been/feed/ 0 http://codeofdoom.com/wordpress/2009/07/09/so-where-have-i-been/ http://feedproxy.google.com/~r/CodeOfDoom/~3/4gMFxOaTruY/ http://codeofdoom.com/wordpress/2009/05/18/know-your-flex-interfaces/#comments Tue, 19 May 2009 02:49:37 +0000 Marcel http://codeofdoom.com/wordpress/?p=501 One of the things I love about Flex is how extensible it can be. You are able to make composite components to do almost anything you want using out of the box components. However, if you really want to take advantage of its power, it helps to have a good or in depth knowing of the interfaces that come with it. The reason to proclaim the importance is that using these interfaces, you will be able to create extremely light weight components, but you will be able to make them do whatever you want (in a programming sense of the phrase).

There are, of course, quite a few different interfaces. I have looked through them and picked out five interfaces that I consider to be the more important ones. For each, I will give a brief explanation of why they are important and where you would normally use them.

IListItemRenderer
Usually when creating composite components or item renderers, I try to stick with UIComponent rather than something like an HBox or Canvas. If you are going to use it item renderer for something like a list though, you are going to have to implement IListItemRenderer to your UIComponent. Keep in mind, if you dont use an UIComponent, there are a lot of other interfaces you will have to implement. If you want to keep it simple, use UIComponent.

When you implement IListItemRenderer, you are given access to the listData, which has one extremely useful property on it. Using the listData property, you will be able to tell in your item renderer which field of your dataprovider you are currently using. This property is know as the labelField. This is useful when you need to handle special cases for different properties. Since you have a access to this, you can setup something like a property map to handle each case.

When implementing the IListItemRenderer, when setting your getter/setter for your listData, keep in mind that the data coming in will be of type BaseListData. Be sure that your classes implementing this will have that property on it.

IDropInListItemRenderer
As you might have noticed, I did say to use the IListItemRenderer for lists. Well what about grids? With a IDropInListItemRenderer, you are able to reuse the renderer to assign it to multiple properties, for say, columns in a datagrid. Keep in mind that when using the IDropInListItemRenderer, you must also implement IDataRenderer(which I will discuss shortly). This is in order to have access to the data property. The listData is then used to initialize the data property. Normally when your components need to apply new listData, it takes place in the commitProperties (or in invalidateProperties is flagged. However you feel like describing it). When you implement your getter for listData, make sure you bind a dataChange event in your component like this:

 [Bindable("dataChange")]
public function get listData():BaseListData{
      return _listData;
}

This will ensure that your getters/setters are called properly. This also applies to IListItemRenderer. You will also notice that the BaseListData object is also used whenever you are using IDropInListItemRenderer. This is because the type that is actually used is dependant on the component that it is being used with. If it is a grid, it will use DataGridListData, Lists will use ListData and a Tree control will use TreeListData.

IDataRenderer
The IDataRenderer is another popular one amongst item renderers. This is what gives you access to the data property. Along with needing to work with the listDataRenderers, it is also used whenever a chart needs a renderer. It could also be used with datagrids as well, but for this, the data property would be the data for the entire row, not specifically for the item. Just like in our IDropInListItemRenderer, we need to make sure that our component has a binding for the dataChange event. The other important fact for this is that when you are setting your data, to fully complete the binding, an event dataChange event must be fired.

public function set data(value:Object):void {
  _data = value;    
  dispatchEvent(new FlexEvent(FlexEvent.DATA_CHANGE));
}

IEventDispatcher
This is one of the more interesting interfaces. Not so much because its cool or does anything special, but it is the only interface where it is recommended to either:

a) extend EventDispatcher
or
b) if that’s not an option, have an IEventDispatcher property on your component.

Personally, I pick option B. If you have a property for it, it does give you the ability to assign a different implementation class to it, making it more versatile. You could leave it as a normal EventDispatcher, but you could also assign a CairngormEventDispatcher to it. Once you do this, you will be able to create your own hooks in order to dispatch your events.

IResponder
I feel this gets overlooked but it is definitely important in the world of data services. The reason it gets overlooked is that we just often copy/paste code like this and take it for granted that there will always be a result function for our service calls. However, this is the interface that gives us access to our result and fault functions that our asynchronous service calls make. Most of the time, we use existing frameworks such as cairngorm or puremvc for this, but it is good to have an idea of what is going on the background.

Usually our fault function looks like this:

public function fault(info:Object):void);

Normally a FaultEvent is what is returned, but according to the Flex documents, this is not always the face, hence it being returned as an object.

public function result(data:Object):void);

Once again, this normally comes back as a ResultEvent, but this is not always the case.

These are just a few of the major interfaces that I have used more often than not. There are quite a bit more. While knowing all of them by heart is not something I would consider necessary, but when you start creating custom components, knowing these interfaces and how to use them are extremely important. It allows you to create more flexible, clean and light weight components.

Think I left something out? Any other important ones? Wrong about something? Feel free to comment!

]]> http://codeofdoom.com/wordpress/2009/05/18/know-your-flex-interfaces/feed/ 2 http://codeofdoom.com/wordpress/2009/05/18/know-your-flex-interfaces/