Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Boolean flags vs. multi-threading?  (Read 2651 times)
0 Members and 1 Guest are viewing this topic.
Offline TLE

Senior Newbie





« Posted 2007-01-16 15:17:27 »

I'm programming basically a login screen for the launch of a game.  Is it better to set it up so everything uses boolean flags, like isLoggedIn, and just set up the graphics based on those, or is it more effecient to use multiple threads?
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #1 - Posted 2007-01-16 15:54:24 »

I'm programming basically a login screen for the launch of a game.  Is it better to set it up so everything uses boolean flags, like isLoggedIn, and just set up the graphics based on those, or is it more effecient to use multiple threads?

Yes. Don't use threads unless you know exactly why you're doing it. Code complexity goes up exponentially when you need to support multiple threads.

Play Minecraft!
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #2 - Posted 2007-01-16 21:27:51 »

code complexity only goes up when you don't know what your doing.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #3 - Posted 2007-01-16 22:33:13 »

http://en.wikipedia.org/wiki/Complexity

More lines of code (or more control flow statements or more possible states) increase the complexity.

I'm really sorry, but that's a fact. Smiley

弾幕 ☆ @mahonnaiseblog
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #4 - Posted 2007-01-16 23:17:55 »

@Everyone besides TLE: What's wrong with you guys  Huh 

Quote
http://en.wikipedia.org/wiki/Complexity
More lines of code (or more control flow statements or more possible states) increase the complexity.
I'm really sorry, but that's a fact.
That has nothing to do with the question! Also, the Wikipedia link does not state anything you mentioned.

Quote
code complexity only goes up when you don't know what your doing.
That's very helpful to know.

Quote
Yes. Don't use threads unless you know exactly why you're doing it. Code complexity goes up exponentially when you need to support multiple threads.
I agree with the first part. Although there are situations where multiple threads allow to make things easier to understand ...


@TLE: I am not so clear on your question, but I believe what you are looking for is a state pattern.
http://www.informit.com/articles/article.asp?p=28677&rl=1

You would build your game so you have a base State class. Then you implement:
LoginState extends State  -> allows to login and eventually proceed to the GameExecutionState
GameExecutionState extends State -> your actual game rendering loop is in this state.

Your game will be in one state at a given time, where it can proceed to other states. E.g. when the game starts, you could go through the following states:
TitleState -> "mouse click" -> LoginState -> "correct login" -> GameSelectionState -> "game selected" -> GameExecutionState ...
                                                                          -> "wrong login" -> LoginState ...

That way, you only need a single Thread ...

Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #5 - Posted 2007-01-17 00:14:38 »

Quote
code complexity only goes up when you don't know what your doing.
That's very helpful to know.
thanks i gues  Wink

actually my motivation in posting that is all in your reply.
Quote
@TLE: I am not so clear on your question
so I decided to poke anound as perhaps it was just me, in any case I disagree the motivation of the
answer given. Yes most of the time the option is dismissed for good reasons.
Quote
Don't use threads unless you know exactly why you're doing it.
actually I'd go  with 'Don't use any unless you know exactly why you're doing it.' being a good practice.

to cut this offtopic stuff sort,
don't avoid multi threading because it's.. scary. this just obscures the engineering process.

Wenn using complexity to be more complex you need a point of reference.. Reguarding software metrics,
I can give examples of cases where cyclomatic complexity is equal or less that of the non-threaded variant.
Classifying something as 'complex', or rather to complex is subjective even more so wenn mixing in the
fact that transformation likely shifts the points of complexity around having various effects on the perspective.

ok thats not really cutting it short,

Quote
Although there are situations where multiple threads allow to make things easier to understand ...

although by the sound of it the state pattern suggestion is a good choice it only replaces the flagging bit with something more OO and has little influence on the multithreaded case the state switching or the boolean assigning.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #6 - Posted 2007-01-17 00:29:13 »

>That has nothing to do with the question!

Amazing! (The question was already answered.)

>Also, the Wikipedia link does not state anything you mentioned.

"Complexity is the opposite of simplicity." (at the very beginning)

弾幕 ☆ @mahonnaiseblog
Offline TLE

Senior Newbie





« Reply #7 - Posted 2007-01-17 00:55:03 »

Thanks for all the replies guys, lots of good info in there for me!

I like the state change ideas, I hadn't thought of that before but I saw it in another post.  I've written quite a bit just using loads of booleans, but the single class is getting a little big and harder to edit.  Plus, it seems like the overhead of checking booleans over and over that only need to be checked during log in for instance will get to be a problem -- eventually.  So I'll definitely be re-writing a lot of it into multiple states.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #8 - Posted 2007-01-17 09:41:18 »

code complexity only goes up when you don't know what your doing.

This is simply not true.

Play Minecraft!
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #9 - Posted 2007-01-17 11:55:21 »

indulge me then, keep in mind I was replying to your reply.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TLE

Senior Newbie





« Reply #10 - Posted 2007-01-17 13:43:52 »

He just meant that when you use multiple threads, the complexity goes up because there's more stuff going on, so it's more complex.  He didn't say it's hard to understand, just that it's more complex.  And it is, the more complicated you write something, the more complex it is.  And you've got the right idea too, Light, if you don't know what you're doing (*cough*me*cough*), the complexity makes it loads harder. 
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #11 - Posted 2007-01-17 14:11:14 »

indulge me then, keep in mind I was replying to your reply.

Show me an example of a multi-threaded solution of something that doesn't need to be, where the multithreaded solution is less or equally as complex as the singlethreaded one, and I will either point out a bug, or take a back my comment. =)

Play Minecraft!
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #12 - Posted 2007-01-17 21:26:55 »

whould someone who knows what there doing apply stuff where it doesn't need to be applied?

need is awefully ambious
without a formal description of complexy, it's subjective.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #13 - Posted 2007-01-17 23:14:34 »

Perhaps we can all agree that bugs arising from threading are far, far harder to replicate?

This alone is enough to keep me away from multithreading except in the cases of blocking I/O and GUIs.
I'm with Markus here, avoid multithreading unless your know exactly what you're doing and are absolutely sure of the benefits.
Offline TLE

Senior Newbie





« Reply #14 - Posted 2007-01-17 23:39:32 »

I can't believe you guys are arguing about the defintion of "complexity".

Here's dictionary.com's definition of complexity:
com·plex·i·ty     /kəmˈplɛksɪti/ – the state or quality of being complex;

And that's a real smartass definition, here's complex:
com·plex     /adj., v. kəmˈplɛks, ˈkɒmplɛks; n. ˈkɒmplɛks/  – composed of many interconnected parts; compound; composite: a complex highway system. 
Offline Kova

Senior Member





« Reply #15 - Posted 2007-01-17 23:49:25 »

lol this is a funny thread Smiley
But I strongly agree, in general multithreading is way more complex then other solutions. I also would like to know if there is an example where multithreading is better then singlethreaded solution (except NIO), as there aren't many or none at all.
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #16 - Posted 2007-01-18 04:26:07 »

e.g. a chat panel which communicates with a server. the chat panel would have a seperate thread so IO operations do not interfer/block the rest of the game.

Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #17 - Posted 2007-01-18 11:46:23 »

Perhaps we can all agree that bugs arising from threading are far, far harder to replicate?

This alone is enough to keep me away from multithreading except in the cases of blocking I/O and GUIs.
I'm with Markus here, avoid multithreading unless your know exactly what you're doing and are absolutely sure of the benefits.

could that be because there's no adequate tooling for it?

is this a self-sustaining thing?
Is it getting complex because we have poor understanding of it making the whole multi threaded area and thereby creating some kind of blackbox.

as soon as your directly or indirectly concerning yourself with time slicing (mechanisms), are where the cases are found. At other times it's not because of the increase of complexity but the side effect it brings, such as poor scaling.

we're not that far apart as to when to apply, it's much more the mindset round them that I disagree with I don't think ppl learning how to program should stay away from threads having an understanding about them allows they to make better decisions on when to avoid them.

I toss the example thing in a whole differend direction, say your system is composed out of 2 components component 1 is relatively small compared to component 2 component 1 claims 80% of the resources the other 20% there is a performance component 1 can be optimised by threads.. with some increasing in ~complexity a little for that component. or one could decorate component 2 with (sticking to single threaded) performance tricks increasing the ~complexity by a lot.

horray overall ~complexity was decreesed by going with the multithreaded approach.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline biggeruniverse

Senior Newbie




That's just peanuts to space.


« Reply #18 - Posted 2007-01-18 12:29:53 »

This entire forum thread is multiple sub-threads within the main thread, which I think is undue given the definition of the problem.

Anyway, never use a simple dictionary, always get the etymology of a word: http://www.etymonline.com/index.php?term=complex

I like the 1715 version.
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #19 - Posted 2007-01-18 12:36:47 »

could that be because there's no adequate tooling for it?

It's because thread scheduling is pretty much non-deterministic - it depends on OS, processor, system load, CPU temperature, user actions, phase of the moon, inside leg measurement, etc, etc. Being able to replicate a non-trivial bug is the only way to fix it, so deterministic behaviour is mighty useful.

By all means people should learn about multithreading -it's a useful technique and completely necessary for blocking I/O, responsive GUIs and parallelisable tasks on multi-core CPUs -  but if this learning process doesn't leave them with a deep-seated terror of debugging a multithreaded application then they haven't learnt enough. IMO anyway.

I'm probably misreading your example of why multithreading can make things simpler and/or more performant, but what you seem to be saying is "A system that can be optimised with multithreading can be optimised with multithreading". That's obviously true, but I can't think of a concrete example outside of <brokenrecord>blocking I/O, responsive GUIs, parallelisable tasks on multi-core CPUs</brokenrecord>.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (45 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (33 views)
2014-09-21 01:30:30

moogie (41 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!