Messages

1

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 09, 2012, 05:07:25 pm »

MorleyDev, a rose by any other name is still a rose.


Nexus,

that's revisionist history, inheritance/type based polymorphism had been a part of C++ for 15+ years at that point.

In general, code was not written like that because people were just starting to figure out the ramifications of the "new" C++ standard, it was written like that because as an industry that sort of architecture was a best practice.  C++ developers didn't start preferring composition over inheritance, the industry did.

Todays best practice is tomorrows mistake

It is a fallacy to say "look, maintainability regards led to these bloated hiearchies, therefore it is better if we do not do it". You can't just leave out all the cases where intense planning resulted in good code design.

You are not understanding me.


maintainability and scalability arguments are roughly the same in terms of usefulness.  Here's what I mean.


We need to do X because it's more scalable
vs
we need to make sure we can handle 10k concurrent users even though we're only estimating needing 3k concurrent users.  The business leaders tell us they expect us to double in size over the course of the first 6 months, that should give us breathing room.

One of those will lead to much better decisions than the other.


Likewise with maintainability.

We need to do X because it's more maintainable.
vs
We need to make sure this algorithm can be changed out easily since we're not sure exactly what the performance requirements are, but we know that this is going to be integral to said performance.


And look at the counter-argument

we don't need more maintainability.
vs
No, I don't think that piece is going to be the bottleneck for performance.  Why don't we stay simple, slap this algorithm in, but with the idea that we may need to abstract it later.  We'll get something up and running quickly and then test, because I think we're going to find the performance bottleneck is going to be the DB I/O, not the number crunching.


One of those leads to a more valuable discussion.

Which is why I say, if the only argument you have for doing a thing is that it's "maintainable" or "scalable", or "readable", then you have no argument.

Lets write tests because it's changeable.  vs We're writing accounting software, which can get our asses sued, so for the calculation module, we're going to Unit Test.  We're also going to implement code reviews, but only for this module because both of these things have an up front cost that isn't worth it for the rest of the application.  risk vs reward.

What tends to happen is that when people don't have the knowledge either due to inexperience or external factors (business doesn't know what's going on, the software is new, what have you), you need to be making concrete decisions based upon that lack of foreknowledge, not based upon 'maintainability', et al.

And that's the context we're speaking in, someone who is learning.  It is better to stay simple, and refactor mercilessly, than to wax poetic about how you have 90% test coverage.

It's all about making good decisions, and basing your decisions on something as nebulous as "maintainability" rarely turns out to be good.

2

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 07, 2012, 12:55:40 am »

In my opinion I think that making things work in order to understand them and then going for a structure once you do is the right choice.

Since you can't know how to build something if you don't know what you're building it with. Of course the testing takes time, but once you know your all-around environment you can make well thought structures without taking too much time because you already know how things work.

Basically.  Software is emergent, it's a mistake to think you can successfully plan ahead for something you've never done.  Software developers tend to be intelligent people, but they put too much faith in that intelligence.

At my work, the old code has parts where it's a mess of inheritance and what we now at work consider poor practices.

Lots of inheritance was a 'best practice' for many years.  Who do you think wrote that kind of code?  The ones who believe you should do the simple thing and move on, or the ones who believe you should think deep thoughts and write 'maintainable' software?

What things are you doing today that the future developers are going to complain about because you architected it in such a manner as to cause them undue pain?  What best practices are you employing now that in 10 years we'll know has a tendency to lead to difficult architecture?

I don't know, and neither do you, but the difference is that one of us is moving forward as if we do.


And that's a major reason why I dismiss arguments about maintainability.  Well, that and the aforementioned nebulous nature of it that causes people with weak arguments to fall back to it constantly.

So at this point Morley, it's safe to say you've continued trying to press the maintainability argument, which means I'm finished with the conversation.  I'm just not interested in something that's neither actionable, nor concrete.

3

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 06, 2012, 09:05:09 am »

Isn't maintainability just a shorter way of saying "ease of making modifications and additions without a big risk of breaking the rest of the program that works, and ease of debugging when something goes wrong and the cause tracking down"?

So maintainability means familiarity with the codebase? 

http://www.infoq.com/presentations/Simple-Made-Easy

Really pay attention to his distinction between simple and easy, this talk is phenomenal.


Maintainability is important, but the problem is that it isn't concrete.  I could argue The One True Brace Style and use maintainability, but at the end of the day, as a developer, having the brace on the same line vs the next has no bearing on my ability to read the code (and I question anyone who claims it does).

At the end of the day you have truly beautiful code, truly awful code, and then there's this huge grey area in the middle.  Most code falls in that grey area.


Nexus,

I can't respond to every little thing, if there's something in particular you want me to respond to, let me know what it is.  Having said that, as you discovered, my position is not the extreme of 'absolutely no thought', I didn't respond to that particular point because there was nothing to respond to and I didn't want to get into a rousing discussion over whether or not it was a strawman argument (and I still don't).

4

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 05, 2012, 10:24:47 pm »

One thing I like to tell people is the following:

If you cannot couch your argument in anything but 'maintainability', it means you have a weak argument and you really need to look at the alternative.

readability, maintainability, scalability, these are all nebulous ideas that you can't really put your finger on.  As such, they're the go to for people who have no real concrete basis for their beliefs, whether that's due to inexperience, or emotional appeal (ie, they just want to do it that way).

I don't mean to pick on you, but talking to me about maintainability is like trying to speak to an Atheist about God (or your deity of choice).  I'm just flat not interested in hearing it.

I'll argue until we're both blue in the face, until the conversation turns to maintainability, readability, or scalability.  At that point I check out to go do something worthwhile.

5

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 05, 2012, 05:40:05 am »

That applies to the most other answers here, including yours. Beginning a sentence with "The truth" doesn't change that

Everyone makes assumptions, but some assumptions are more dangerous than others.  The inexperienced believe they can think their way around that inexperience, the experienced know better.

Balanced isn't relevant, we're talking about a specific context, an inexperienced developer trying to write a game.  That's automatically unbalanced, said developer has no idea what a balanced approach is, much less the ability to take one.

Instead of believing you're smart enough to 'figure it out', it's better to admit that you're not, and *plan* for mistakes by making them as cheap as possible.  One of Erlang's strengths isn't its ability to never fail, it's the ability to minimize the impact of the failure.  It's the same idea here.

If you're writing YAGE(Yet Another Game Engine), have at it, use your prior experience to try and navigate some of the pitfalls you've seen.  Until then, admit that you suck, and work on minimizing the impact of your mistakes.

And to be clear, by inexperienced, I mean inexperienced writing that type of software.  An experienced game developer trying to implement a CMS is probably going to make a bad job of it, no matter how many years they've been developing.  Until their 2nd or 3rd CMS.  In other words, we're all inexperienced in some area's that we may have an interest or a need in.

6

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 04, 2012, 10:28:09 pm »

Of course the "write shitty working code then refactor" approach has the slight downside that shitty code tends to be difficult to refactor by nature whilst good code is inherently easily refactored and re-used. You can easily code yourself into a spiderweb of a corner if you don't keep that in mind xD

That's a statement that you cannot prove or disprove, you can only assume.

Your other assumption is that worrying over the design is somehow going to get you to the spot you want to be when you're inexperienced.

The truth, the thing people don't like to say, is that both approaches are just as likely to 'fail', meaning, you end up with a design that's not good for the task at hand, and it's directly as a result of the experience of the developer (or lack thereof).  That experience factor outweighs any amount of planning you do.

You'll find you save time by not making decisions.  "I don't know what is best here, so I'm going to do the simplest thing that works and see how the usage shakes out" is often times a superior approach, especially when you're developing software you've never developed before.

At least when you're doing that, you're not wasting time building abstractions and architectures that are ultimately harmful (or at the very least go away because they weren't really useful).  In both cases you'll find yourself having to refactor, in one of those cases, you spent a lot more up front work, and throwing TDD into the mix just amplifies it even more.

7

General / Re: Having lots of trouble with sf::Clock and sf::Time

« on: December 02, 2012, 07:11:50 am »

http://www.sfml-dev.org/documentation/2.0/classsf_1_1Clock.php#a123e2627f2943e5ecaa1db0c7df3231b

restart does 2 things.  It resets the internal counter to 0, and then returns the amount of time that has elapsed since your game started, which means your check is always going to return true until the total time that your game has been open exceeds your time variable (which I assume doesn't change), and then it will always return false.;

Look into:
http://www.sfml-dev.org/documentation/2.0/classsf_1_1Clock.php#a799feb6acb099b57b58d8d20984fce11

What you want to do, is when you shoot successfully, restart the clock, and then in your recoil function, check the elapsed time.

clock.getElapsedTime().AsSeconds() < time

8

General discussions / Re: Engine Dev or Game Dev...Which one goes first?

« on: December 02, 2012, 03:17:59 am »

Well both of you strike a good argument(And articles), I never did want to reinvent the wheel.
The fact that I'm here, on a forum of a "Multimedia" library, proves that I speak just that.
Also i'm in the right place... considering what you guys told me.
And I knew making a engine would be a stupid endeavor, You guys proved it and now I know for sure.
If I wanted to make a engine all by my lonesome... there would be no "game".... or engine.
Not that I couldn't do it but because I would get bored... I like games not tech demos.
I was also right that it WAS a stupid question... Ha!

If this is all true(About the game not the engine), What would the workflow be to make it?
And I did see TDD, I like it, and I might try it. but I want this to be answered.
So far my workflow has been very hectic and irrational most of the time.
And what I usually get is either incompatible code from the last thing I implemented.
Or I strike gold and get something I want, Which is 4/5's of the time.

I watched Notch write a game for a Ludum Dare, on I think twitch?
He had this workflow about it where he kept pounding at it and didn't care to much for the structure of it.
So it looked crude and inefficient(Structure not speed), Granted this was Java and he can see his changes as he set them. But it wasn't enough for me to stand up and say "Forget this, its Java now".

Then I watched one of the Amnesia Dev's, No different, He had low level code for the complicated and High level scripts for the simple, and yet again... he got it out fast, even faster than notch did.
So basically I believe at that point, that a good workflow and style is key.

So you can tell, I am not all sorts of confused. I'm actually hoping you guys might have a tip that might help me. Maybe a library that has a usable interface to Python like the amnesia Dev? Or is that something I might need to make?

But so far, I got a lot to chew on now, Thanks!
-

As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent )

I'm late to this, but just wanted to add my opinion.


shitty working code is better than non-shitty, will work one day code.  GNU Hurd is an unfair example, but still an example.

Throw your code out there and make it work.  Don't worry about style, structure, or anything else.  Once that's done, refactor mercilessly.

The problem with writing an engine before a game is that it requires experience.  You don't know what problems need to be solved, you know what problems you *think* need to be solved.  So you write sloppy code, get it working, then later on, use your practical experience to refactor it.  By then, you have a much better idea of the problems you need to solve, and you may even know a bad way to solve them (Because you did just that).

If Carmack wanted to write an engine before the game, let him.  He knows what the hell he's doing.  You most likely don't, write the game, let the engine be emergent.

9

Graphics / Re: sf::Texture out of scope?

« on: November 28, 2012, 06:32:13 pm »

I believe the standard requires in order initialization w/i a translation unit, and I know of no compiler that does not implement it that way.  The standard also guarantees initialization before main is called, which means using a pointer solves the problem entirely (as does handing the global texture to anything during execution).

But cire seemed to be implying SFML itself was sensitive to init order as a result of the implementation.  Is that not the case?

10

Graphics / Re: sf::Texture out of scope?

« on: November 28, 2012, 02:28:21 pm »

While I agree with the sentiment, initialization order of global objects can be problematic with SFML, so I would keep away from them for that reason.

I'm curious about this.  What aspects of SFML are sensitive to the order of initialization of objects?

11

General / Re: Design Question: Memory usage vs Run-time speed.

« on: November 28, 2012, 02:23:31 am »

Without more information it's all just stabbing in the dark.  What exactly are your concerns?  Are you experiencing performance problems now?

I mean, there are general things that can be said

- object allocations tend to be a lot more expensive than most developers realize,
- Many times it isn't the amount of memory, it's your access patterns to said memory.

But that's all mental masturbation without something concrete to talk about.

12

Graphics / Re: sf::Texture out of scope?

« on: November 28, 2012, 02:04:56 am »

Hey Tacostomp, I went through the same pain.  The API doesn't really feel like it communicates the behavior very well.

If you let the texture object get destructed, it destroys the underlying texture.

Keep the textures in a class that exists longer than your sprites. And don't use global variable or singletons, they're unnecessary.

Personally, I disagree with this.  If Tacostomp is just trying to learn SFML, building a use-able resource manager (even a super simple one) is solving a problem that isn't getting him to his goal.  If using a global eases his pain and doesn't get in his way, then it's a good solution.

Granted, it isn't generally sound *practice*, but when the code isn't supposed to be super robust or professional, who cares.

13

Graphics / Re: Rotating a sprite about a point?

« on: November 28, 2012, 01:43:50 am »

And this is exactly what the component approach is: you set the final position, orientation, scale of the entity. You don't combine custom transformations to produce the final one. It is a totally different approach -- even though it internally uses the same low-level class.

This is why I think the extra documentation is so important.  To me, when I see something 'high level' like a sprite, I think of something I can push and pull around the screen, not necessarily something that's meant to save the final combination of translation, rotation, and scale.  Documentation explaining how it's meant to be used can go a long way to prevent someone from wasting time on it.

Unless you mean by passing a transform in directly to RenderTarget::draw?

This is what I mean, yes.

So that's one part of SFML I do like.  I haven't really dug into the view/viewport stuff yet, but the ability to specify a final transform that goes into the draw is fairly elegant.  It's always there but you guys leave it open and available in a structured manner.

So I think SFML did its job wonderfully: you were able to find a set of classes/functions that exactly fit your needs

There's a lot I like about SFML, but there's also things I don't.

14

Graphics / Re: sf::Sprite vector reference to sf::Texture vector

« on: November 28, 2012, 01:42:42 am »

yep, std::vector storage is required to be contiguous in memory (makes interfacing with C API's much simpler), which implies copying everything over when the vector needs to be resized internally

I don't personally like the design decision to have the texture destroyed in that manner, but it is what it is.  I second exploiters recommendation of using a Smart Pointer.  Even if you don't have access to a compiler that allows you to use the new C++ features (where they're built in), there are plenty of smart pointer implementations laying around for you to use.  It's kind of a pain, but you can also pull specific parts of BOOST out without using the entire library (they have a tool for doing so).

It might be more work than it's worth depending on the scope of your project, but lets call that the long winded version of "you should really be using smart pointers, and they're available for just about any C++ compiler made in the last 12+ years".

15

Graphics / Re: Shape not placing properly

« on: November 28, 2012, 01:32:11 am »

It sounds like you've solved your problem, but just an fyi for my benefit.

I believe it would be better for you to set the origin directly in the center of it (width/2,height/2), otherwise it draws from the top left corner, which is just weird.