first of all wow thanks for the help i cant imagine how long it took you to write all that.

creating widgets seems simple enough however textField seems like it could be a bit complicated. For instance scrolling? in the chat i would like each new message to be on a new line and obviously when the text reaches the bottom of the screen or widget it should be scrollable. how do you implement that?

keep separate components for separate things - do one thing and do it well / separation of concerns.Your console thing probably doesn't require input etc. There are a couple of different approaches that work and there isn't really a consensus about what's best. Have a look at GoF and not just the MVC cause that can be implemented a zillion ways. But the idea of how complex components are just a collection of simple components.

as for transfering the userlist i already have each player objected created with a userName to identify it and yes thats all i need to transfer not the actual object. I believe i will go with when a user connects the server sends the current user list and later on sends an update with a leave/join.

getting into protocol is kinda where things get confusing because the server and client have to send so many different types of messages. im having trouble making the client understand what to do with the data it recieves. it seems like an easy way to do this (tell me if this is even possible) would be to say:

update: userNameremove: userNamemessage: "message"etc.

preface the type of message like above or even shorten it to just one letter and a colon to represent the type of message. however after that is there a way to remove a portion of a string? for instance with message: "message" i would have to remove "message:" and display the rest to the user.

sorry if thats a little confusing...

I think I get where your going, being 'smart' doesn't necessary work well and will spin the complexity out of the control.

update:userNameremove:userName

u:username might look like a good idea but there are pretty much only 26 options for identifiers going from update to u throws human readability out the window so why stick to 'u' at all then? you might as well use numbers (IRC is based on this if I remember correctly.) but note that it is performance optimization (which might well be premature) and is an implementation detail that shouldn't spread in your code.(which is a code smell,to use a hip word)

all that makes sense but i still dont understand how the client will interpret the data....

say it recieves:

'1 me''1 you''1 hi'

1 being add user like in your example. how does the client get rid of the 1 in front of everything? you wouldn't want a 1 to appear in front of every username. the only way i can think of would be to send multiple messages, the first one being a 1 then followed by a username but that seems uneccasary and not optimized.

just to make sure we are on the same page i have only been sending and recieving strings like this...

edit: nevermind i answered my own question. However, would it not be easier to do it something like this:

1*W A C K O

and split it at the "*" instead of spaces

As you can probably tell there are a couple of approaches to arrange the data in the protocol:

You can use a predefined fixed length fixed format.You can encode the lengths in the message.EndOfXXX / separator 'bit'(can be a character or a certain series of bytes).

Depending on the data your sending any of the above might work well. (There are a couple of other variants but those don't really make sense considering games)

It's probably wise to use an EndOfXXX / separator 'bit' that doesn't occur often (never presume that you never send it, in a different context) When you do send the 'bit' make sure you escape it. (Google for escape characters)

That is based on writing custom components for SWT since SWT is based on native implementation it's probably not going to work with applets. Also it will draw in to much complexity and thus will kill the advantage as to why you where going to write your own.

But you might want to code against an interface.Also translate(x,y) helps to allow you to move your widgets around. To be able to transelate you need to know the widgets position hence the method getPosition() on the interface.SetClipping helps to improve performance and 'sandboxes' components. to be able to use it you need to know the height and width.

You probably want to add some methods so you can pass input to the components.

thanks for the example i understand now. however i am wondering what the advantage of doing all this is? essentially i am just drawing everything anyways so why not put it all in the same class? only reason i can think of is to be able to reuse my widgets but thats not really an issue. seems simplest to me to just create the user interface as one image and then based on events act accordingly.

thanks for the example i understand now. however i am wondering what the advantage of doing all this is? essentially i am just drawing everything anyways so why not put it all in the same class? only reason i can think of is to be able to reuse my widgets but thats not really an issue. seems simplest to me to just create the user interface as one image and then based on events act accordingly.

Separation of concerns(entangleness, complexity, change leads to more change) - single point of definition(or DRY) - reuse(compound components). Well that's slinging hyped and not so hyped words at ya - but there is no easy way to explain why, there isn't really a need for iether as that is something that comes with experience. So tbh going for the monster class approach might not be a bad idea in your case. You need to rewire your brain a bit anyway else either way is not going to be faster.

hmm almost forgot an old favourite spaghetti code - that does look tasty ey?

You need to rewire your brain a bit anyway else either way is not going to be faster.

^^^ haha are you calling me stupid? im jk but seriously thanks so much for helping me out these past few weeks i really appreciate it. im gonna try to stay off of here and stop bugging you for a while. plus i cant think of anything else i could possibly need help with

^^^ haha are you calling me stupid? im jk but seriously thanks so much for helping me out these past few weeks i really appreciate it. im gonna try to stay off of here and stop bugging you for a while. plus i cant think of anything else i could possibly need help with

No, I'm not calling you stupid. It's like going from java to a dynamic language or back.

after working on things a bit i can definately see why it is advantagous to write each widget as a separate class. in the monster class approach something as simple as making a button loook different when clicked becomes difficult because not only do you have to redraw the button but also the entire interface. so going back to the separate class approach im a little confused on where the actionlisteners go. are they all in the main applet class and based on the user input you have methods in the widgets to handle input? or does each widget have its own actionlisteners that are passed as parameters maybe

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org