As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm new to stackover and this is my first ever post, so please be gentle :-)
I'm in the middle of developing a multi-level shooting game, and I'm questioning the best OOP design for my purposes, explicitly to manage the bullets.
Generally the game has multiple players and multiple enemies, each of which has a gun which fires bullets. There are bullet classes which manage multiple bullets well, their position, animation, rendering, etc, and these work fine.
My question is, am I better off instantiating an instance of these bullet classes per enemy, or am I better off instantiating one instance for the level which manages all bullets (irrespective of who fired it)?
The benefits of a single instance is that the bullet management and rendering can be optimised for them all at once, however they need additional state information so we remember which bullets belongs to who, how many bullets can exist for each enemy, etc, and it isn't as loosely coupled. The benefit of a separate instance per enemy is that it's neater and less state information needs to be stored per bullet, however they would be managed and rendered on separate calls for each enemy or player. Inter-bullet collisions would also prove more difficult, but luckily this isn't a requirement of this particular game.
Has anyone else written anything similar and how did you structure it? Which factors should I consider before deciding, and are there any game design principles for this?
Regards
Nick
For general Game-structures you may want to read this.
It may be my personal insight but, I think a level-wide handler for the bullets should be more universal.
When a player shoots a bullet, it sends a signal to the Bullet-handler object, and decreases the bullet-count by one. The bullet would have to store which player shot it, so you can look back which player shot which player, or increase stats.
Not to mention a level-wide bullet handler could be extended later to handle grenades, mines, exploding gunpowder-filled rabid weasels or whatnot.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been researching and looking for answers here to a problem that I suspect might be solved by a better understanding of design patterns. I think the problem is that I am a self-taught coder and people seem to tend to assume familiarity with a lot of esoteric terminology; I have ended up in Wikipedia spirals trying to determine what some phrases mean.
That said - on to the coding/structural problem.
Actually, just before I start, I should point out that I may well be making unknown presumptions in the way the code is structured in my question. If this is the case, could folks suggest alternatives to what I'm suggesting? I'd really appreciate learning how to better code as opposed to simply being told I'm doing it wrong.
OK...
Let's say we have a Room class, which has 4 Walls, a Ceiling and a Floor. These are instantiated 'inside' the Room. The Room also has a Table which has 4 TableLegs, again instantiated inside the Table, inside the Room. (This, I believe, is Composition, but please correct me if I've got that wrong!).
Finally, the problem:
If someone, somehow, pushes the Table, the TableLeg(s) will need to check the type of Floor they're standing on to trigger the appropriate sound. This, currently would be my solution:
The Table dispatches an event. The Room listens for that 'table pushed' event, quizes the Floor to determine its type, then passes that type to a method on Table, which in turn passes it to the TableLegs.
This, to me, seems fairly inelegant; hence my suspicion that knowledge of design patterns might be useful.
Is there something fundamentally wrong about the structure I've described that I'm not appreciating? If so, what is the alternative?
Finally, I have heard of the Gang of Four book. If that's my first port of call, is it written in an accessible style or will I have to have studied computer science to grasp it?
Sorry for the long, design-pattern-beginner's question.
The Floor could listen for objects Events. The Event interface could expose information about object geometry, material, etc. Then the Floor could check for collisions and play a sound.
I recommend the book Head First Design Patterns
I don't know if I can answer your question, but I can tell you something about the "Design Patterns" book.
It was an instant classic when it was published in 1994/1995. With examples in C++ and Smalltalk (there was no Java or C# back then), it listed solutions to 26 common problems in object-oriented programming. It provided a format for documenting forces and resolutions that was eagerly snapped up by academic conferences for years after. Lots of programmers, including myself, were studying it like holy writ in the hope that a single book could make them superstars.
Then reality set in.
Functional programmers said the patterns were work-arounds for flaws in OOP. What's the fuss? They could do these things without resorting to patterns.
The usual response on first reading the book is to try and fit as many patterns as you can into whatever code you happen to be writing at that moment.
You'll find yourself using the pattern names in design sessions: "I think we need a Chain of Responsibility here!"
Eventually you calm down and realize that patterns aren't the answers to your problems. The best way to use them is to think hard about your problems and solutions and suddenly realize that your answer happens to fall into a pattern.
As for your problem, I don't think you need a pattern. Have the Table send a message to the Floor to ask about its type before you generate the sound. That'll do it. Simplicity is a virtue.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I just read a comment saying something like
Yet another reason never to use nibs
Is it such bad practice to use nibs to construct your views in iOS? I think it's a fine system, enables you to construct views quickly without writing a lot of code. I've been working with nibs for a while now and never saw much downsides to their use.
So my question is: should I use nibs or code my views, and why?
I think the statement "never to use nibs" is ridiculous. You just have to know when to use them and when to avoid them. They're great for complex but static views, where you would waste a lot of time getting the coordinates and sizes right. For dynamic GUIs of course you should use code instead.
However, some people might fear that the GUI is out of their control, if they don't create it themselves by code and see every detail. But that's a subjective point.
One sure downside is, that xibs are hard to merge if you use source control. Xib files are actually XML files and when you change something in the GUI, a lot of references are added, removed or changed in the background. This will then result in conflicts that are very difficult to resolve.
Another one might be performance reasons. Loading your GUI from a nib file is slightly slower (in some cases) then creating it directly in code. Some people suggest not to use any nibs for the GUI that has to be loaded at application launch to shorten the launch time. But I'm not sure if there is a significant difference or not.
I prefer using NIBs wherever possible!
My reasons are:
Easy to maintain and in need of a change I can view the result right away.
Now that IPhone5 has a new resolution - things were really easy to do in the NIB
Easy to use
Less code to write
I even make SMALL popup views there and set the container view to hidden.
then I show/hide these popup views with containerView.hidden = YES/NO;
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My understanding is that the fundamental tenant of OO design is that one should focus on modeling a class as the union of code and data. In day to day development, however, I tend to separate all of my business logic into classes of their own. The 'data' ends up being in tightly controlled POCOs/DTOs with basically no real code or logic. I then instantiate a business logic class and pass in POCOs to each method whenever I want an operation to occur.
But this feels like two separate approaches. In fact, the latter approach seems to be at odds with the purpose of OO!
I supposed I've always kept the two things separate since business logic may function on multiple POCOs. Plus, not forcing validation on the data in the POCOs made it easier to unit test since it seemed simpler to prepare the POCO for a test (no need to worry about internal class state, encapsulation, etc). Now that I'm looking back on those reasons, they seem weak.
I'm looking for a comparison/contrast of the two approaches. Specifically, why does it seem that making 'dumb' POCOs is the way to go these days? Why not just stick the data and the business logic into a single class? Are we abandoning the original goals of object oriented design?
Thanks!
Indeed, separating business logic from associated data goes against the principles of OOP, and this is what Martin Fowler refers to as an anemic domain model. Personally, I would always go with a proper domain model that puts data and behaviour together.
Specifically, why does it seem that making 'dumb' POCOs is the way to go these days?
I don't know why you thought this was so, but this is certainly not true. There are many "dumb" models out there, but there are also many well-designed domain models.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been working on an application from past 4 months and it's very much depends on Google Maps on iOS platform. Recently one of my friends raised a concern that what if Apple Inc. decides to use a different Map provider?
It turns out after few searching on internet that Apple is going to replace Google Maps with some new advance 3D maps build by company called C3. (One of the researched resource). Well now I am worried of my already written code,
Should I delay my development work until this new technology gets in? or just wait until Apple announces officially.
Thanks
This is a common dilemma in programming, and there's a common solution too. Develop your own primitives - whether you need to display overlays, show landmarks, draw polygons and lines, do everything through stubs in your own code. If the underlying platform has to change, you then have a few well-known places to update to the new API.
Be very strict about not accessing the underlying API anywhere that isn't in your wrapper layer, and it should be straight-forward to change to a different later. Not free, of course, but so long as it's possible to implement the primitives you need in the new layer, you just need to change those, and can leave the rest of your project untouched.
It's not worth losing months' of having a finished project to avoid this situation.
Edit: This approach has another benefit - if you end up writing multiple primitive layers for different APIs, you may be able to let the user pick between them: you may have a (more expensive) higher-quality map layer which you charge for, and a cheap/free one which you don't - allowing people free access to a lower-quality version, and letting them buy an upgrade to the better maps. Or ... there are lots of possibilities. It's the same pattern some applications take with data-persistence layers, letting people run the same application on top of differing data platforms. There are lots of examples of this patterm.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I have seen some people who refuse to use Interface Builder and prefer to make everything using code. Isn't this a bit tedious and doesn't it take longer? Why would people do that?
This is usually a holdover from working in other environments with other UI builders. A lot of UI builder programs are viewed as newbie hand-holding at best and outright harmful at worst. Interface Builder is unusual in that it's actually the preferred way to create interfaces for the platform.
Some people don't like mixing code functionality in interface designs. Another example is when flash devs would include lots of code snippets directly in the stage (fla files), rather than in separate .as files. With xib it's not as big of a problem, since they are xml and can be merged quite easily when using source control. I personally like using xib's because we have a team of devs and designers -- splitting up the work load is nice. The designers can easily port their photoshop/fireworks designs into xibs and we can focus on the functionality.
Sometimes you want to do something that the UI builder can't quite handle (these situations aren't common, but they do come up now and then). Sometimes you may feel you have better control over what's happening when you write the code yourself. Me, I prefer to let the UI builders do it as much as possible, but sometimes it doesn't always work that nicely, and I sometimes have had to write the code myself.
Possibly because the Interface Builder is another tool to understand. Also, it's useful to know how to do things programmatically in case nibs don't give you enough functionality.