Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Jul 2008
Offline Last Active Jul 01 2013 07:57 AM

Posts I've Made

In Topic: [Future-Proof]Should we try to follow the new technologies? Or going back to...

18 May 2013 - 04:20 PM

Technologies and languages come and go, it is only algorithms and data structures that you can rely on.

When it comes to languages, it doesn't matter if you are programming in C, C++, Java, Perl, Python, Ruby, Eiffel, Erlang, shell script, or something else entirely. They come and go. Use whatever gets the job done.

The same with technologies. If you can get an app written in MFC, or WPF, or Mono, or Qt, or something else, then use whatever gets the job done at present.

Let's imagine it in other disciplines:

There will be better musical instruments than mine, so I'm not going to play.
There will be better paints, brushes, and canvases than mine, so I'm not going to paint.
There will be better hammers, nails, and building materials than mine, so I'm not going to build.
There will be better landscaping materials than mine, so I'm not going to landscape.

You say you have the basics down. That is enough. Go from there. If you find a tool or technology is useful then employ it, but otherwise just keep going and do your best with what you have got.

If you spend your days just trying to"sit back and wait for the future", you will find the present will have passed you by while you were playing. You may suddenly discover you are left with nothing but "could have" and "should have" to keep you company.

I'm a little confused by your points though. Because on one hand, use whatever gets the job done seems to drift towards the strengthening the basics part.

I expect everybody agrees in theory about using whatever technology that gets things done. But when it comes to employment, it simply doesn't seem to be the case


Note I didn't say just sit back and do nothing. I'm saying sit back and let it unfold while strenghthening the basics and occasionally peek into technologies that sound interesting.


Also, I don't agree with the other disciplines analogy, as far as I know, there is very few disciplines that change as fast as the electronics industry.

And people don't judge you/hire/endorse you because of the instruments you use as long as you can get the job done. If you are a painter, they just care if you know how to paint, if you are a musician, people just want you to create great music,  tools are irrelevant.


But from what I've been reading about the IT industry, that simply does not look like the case. Interviewers will ask you about design patterns, they'll expect you to be an expert in the latest and coolest technology even though by the time they decide to upgrade, another cooler and better technology might totally makes it obsolete.


One example is NHibernate, we use NHibernate in the product at work, and I figured it was probably important to learn since it's gained a lot of popularity. But then we had a meeting where basically everybody said NHibernate is not very good for large scale enterprise solutions, many DBAs hate it, and we decided to use code generation instead.


So what's the point to try to learn these technologies when you probably are not going to need it? By the time you become the expert at it, you'll probably needing to learn something completely new again. In that regard, isn't it more important to get the foundations? Because it'll help understand the new technology and makes the learning curve much more acceptable when the time comes.

In Topic: How commercial games do the packing?

21 July 2012 - 08:10 AM

By using libs like (for example PhysicsFS) you can search and load the assets in the package as if they were in the filesystem, combine it with functions like
CreateTextureFromMemory and you can just pass a pointer to a chunk of uncompressed memory for the texture that has been loaded from the package.

There is many other similar working libs but i guess the inner workings is the same but some might use a more secure format other than ZIP.

I see, that makes it a lot more understandable. Especially with the actual file path in the pack file

In Topic: PlayFirst SDK

20 March 2010 - 12:39 PM

Haha, thanks Fedrick.

I actually don't know what to think o.O
or what I was thinking when I started this thread o.O

Originally I was thinking of asking for opinions, but later on, I noticed I didn't want to do anything other than expressing my frustration,lol.

You are right, no matter how slow my project is going (Due to school and work and everything else), I have grown attached to it.

Every progress I make gives me a sense of achievement, which is something PlayFirst is not able to provide.

In Topic: NPC management tutorial?[Solved]

31 December 2009 - 09:16 AM

Original post by Rycross
Original post by polarboy
I thought of state machines, but I'm not sure how you would implement one.
Like I was thinking states such as "moving", "fighting", "idling", but I had difficulties with it...can't remember what o.O
I'll give it some more thought, maybe it does work, haha

I actually decided to re-write part of my post while you were responding, because I didn't really feel that it was clear. Let me re-quote that:

Original post by Rycross
For example, if you NPC is moving to point X, you'd probably mark that the NPC is moving towards that point, and then each update you'd check whether it has arrived, and if not then move Y units towards X. Once you reach that point, you'd clear that state, or start with a new action.

Does that give you an idea? Of course, your NPC may be moving towards X while shooting a gun, so you may have to be able to mark your NPC as "moving to X" and "fighting," but its not too hard to just mark your NPC as doing both.

Yeah, I think I got it, it makes sense. I'm just gonna sit there for a while and plan everything out

In Topic: NPC management tutorial?[Solved]

31 December 2009 - 09:08 AM

Original post by Rycross
What kind of "calculations" are you trying to do? Making a thread for each NPC is certainly the wrong approach. The approach usually taken is to loop through your NPCs/entities every timestep and run some sort of update method.

I'm not exactly sure what you meant by your script, but it sounds like you meant that your script would execute one line, then yield execution back, and then the next time you run your script it would pick up where you left off. You can do that sort of thing with co-routines, but typically what is done is to build some sort of simple state machine and then make your NPC behavior event driven.

Wow, I wasn't expecting a reply so quickly, thanks for the quick reply.

My calculations are things like, the new position over certain amount of time and stuff like that.

Yes, I was thinking about execute one line and come back to it. I can go look up co-routines now, haha, didn't even know there was such a thing.


Thanks a lot