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?

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?

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 GameExecutionStateGameExecutionState 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 ...

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

thanks i gues

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.

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.

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.

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. =)

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.

lol this is a funny thread 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.

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 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>.

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