Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Glass_Knife

Member Since 08 Aug 2001
Offline Last Active Today, 10:11 AM

Posts I've Made

In Topic: Programming

Yesterday, 08:52 PM


Ha +1 for this.  Spiro is a dude.

 

Why didn't anyone ever tell me?  Just let me go around thinking he's a she.  


In Topic: Component Based Architecture

30 January 2015 - 12:14 PM


Very novice programmer here, so please bare with me

 

What?  You haven't mastered programming yet?  Me either.

 

What articles have you read?  Using a component base system is preferred by some.  Instead of a system built around types of object: BaseClass, ChildClass, ChildChildClass, objects can be constructed as a bunch of components.  

 

As you've already discovered, you might need to structure your program in a different way.  For example:

 

Drawable - is rendered to the screen.  

Movable - moves.  

Colladiable - registers collisions

 

The Dx render engine will render all the "Drawable" components.  The Physics engine will move the "Movable" stuff.  The collision detection system will check for collisions with "Collidable" objects.

 

Now lets think about all the different things we can do with just these three components.

 

Camera - movable

Player - movable, drawable, collidable

Door - movable, drawable, collidable

Wall - drawable, collidable

Ghost - movable, drawable

Sky - drawable

Trigger Area - collaidable

 

With just a few types of components, you can create a bunch of things.  And it's easy to create new versions, add components, remove components, or even have debugging components only added for testing.  Imagine the possibilities.

 

This can become a huge task to create all these objects.  Usually, you will end up with some kind of data-driven object creation.  For example:

"ghost" : {
   "movable" : {
      "velocity" : 12
   },
   "drawable" : {
      "mesh" : "path/to/mesh",
      "mat" : "path/to/materials",
   },
}

You get the idea.

 

The other part you need to think about it notifying objects or game states when something happens to an object.  In the above example, the Player can collide with a wall.  So have to figure out if you want to send messages to objects, register event listeners, mark some state, or something.

 

Together, all these things can get quite complicated.  So give it a try...


In Topic: Programming

29 January 2015 - 10:51 AM


Drop your project for your own sake and for the sake of the others working with you. It is not fair to them that their hard work go to waste just because their programmer (you) has no clue how to program but just decided to jump into the deep end foolishly thinking he could learn to fly before learning to walk.

 


But the advice on how to learn programming remains constant.  You still need to start with small projects and work your way up.

 

Listen to her.  She knows what she's talking about.


In Topic: New article up

28 January 2015 - 11:13 AM


So once again, fantastic article it was a great read. You should publish it in the GD.net articles. Not sure if it would be music/sound or business but it belongs somewhere for sure.

 

+1.  As a musician/programmer I think we need a lot more music stuff around here.


In Topic: java timeout thread for connection to wrong server

27 January 2015 - 02:12 PM

In other words:

 

1. Main thread handles UI and other interactive stuff.  When they connect it launches the secondary thread.

 

2. Secondary thread in the background will connect and wait for the connection, sending events back through a listener about if the connection succeeds or fails or whatever else.

 

 

The rule when writing code that talks to a server is to always imagine that it will take a long time.  10 seconds at least.  You have to write your code to respond to that behavior.  You want to disconnect?  Connect?  Refresh the connection?  It will take a long time.  In reality, most of the time it will be so fast you don't even see the waiting.  But you have to design for all the slow times.


PARTNERS