Messages

61

SFML game jam / Re: Jam 2 completed! Now what?

« on: February 12, 2014, 09:06:18 pm »

The jam unfortunately came smack-bang in the middle of my final year exams for University. Next time I'd love to take part I'm not so sure about a 2-week "thing" though (2 weeks seems too long to call it a jam), although I do quite like the idea of those "1-month: Get a game released and make at least 1p off of it" things Ludum Dare do.

62

SFML projects / Re: Flappy Poro

« on: February 12, 2014, 09:04:33 pm »

Like Cadisol87 said, if you don't like a game, just don't play it

Or if you don't like a game, give constructive criticism and then don't play it. For example, "I feel the game has a difficulty curve too steep for me to enjoy it. It may of been beneficial to provide a lower difficulty option".

I'd rather someone politely tell me why they don't like something than just go "lol this sucks" and do no more

63

General discussions / Re: Unit Testing

« on: February 06, 2014, 10:10:48 am »

I like to explain it as, whenever I write code I want to see it work and see it work immediately. Testing something inside the running program can take a lot of effort and time, firing up the program and getting it to the exact scenario and point that triggers the code, and so is done when the feature is all written to make sure it's actually working.

But along the way, I'm a serial recompiler. I want to see everything compile and work. Now, to do that quickly I want to isolate the code as I'm writing it and call the functions to make sure they behave as expected. So pre-encountering TDD I would be keeping a separate main function that let me run what I was working on and see it work.

Effectively, I was constantly writing and throwing away unit tests. Post-TDD I have a framework that helps me write and keep those tests, so I can keep them to document the expected behaviour of those functions and even run them when I make further changes to make sure I haven't broken any past behaviour (and naturally I can modify them when I want to break past behaviour).

It also helps that practising stricter TDD tends to self-enforce a lot of SOLID principles. The real trick comes in learning to 'read the tests', namely accepting that if testing is becoming difficult there's a reason for that. Testing becoming difficult is a code smell, and often is indicative of code hitting a point where it must be refactored and evolved.

And whilst very useful for business applications, client/server applications especially, for programs like games ATDD (automated testing of your acceptance criteria/high level specifications) is dark witchcraft and may actually be more effort than it's worth. I have heard there is a whole team at Microsoft dedicated to writing AIs to test people's games via friend-of-a-colleague, but that's really all I know on the subject.


The tricky stuff for me comes in how testing integration with 3rd party libraries is something of an art-form in and of itself. I've yet to find a way I'm happy with, especially for C++.

In languages like C# and Java there are libraries that (ab)use the reflective features of the language to let you mock out real classes instead of interfaces, and C++ has a couple of libraries that abuse the low level memory access and inherent understandings of how specific compilers work to achieve a similar result but it's not cross-platform and can break from compiler version to compiler version (especially if you like to work with the latest and greatest of everything).

Typcially the solution involves a facade later around the 3rd party library that must be extensively tested manually, or in passing delegates/individual functions (via std::function) that are easier to mock and test. Neither of these are ideal but they are the lesser evils in my mind, at least for C++.

64

General discussions / Re: Unit Testing

« on: February 05, 2014, 06:39:15 am »

TDD is very nice. I've worked in the business industry at a firm that did extensive TDD from high level acceptance testing right down to the lowest of unit tests (creating a fractal of tests). It's incredibly effective when done right, when you allow the tests to shape your code instead of trying to hammer the tests to fit your designs.

I'm a pretty big advocate of the practice, and that it's not trivially mockable is one of my biggest gripes with SFML (but that's a whole other can of worms).

UnitTest++ is nice but showing it's age and era, as is GoogleTest and Boost.Test. Personally I'm an advocate of the more recently released libraries (and even wrote my own, http://github.com/MorleyDev/UnitTest11) since they take advantage of C++11 features like lambdas, and as such remove the macro-heavy uglyness of older testing libraries.

http://banditcpp.org/, for example, looks very nice and I'd recommend it over my own library. It's better documented and looks prettier, I've not had time to do much work on mine lately and need to get back to it at some point.

The one advantage I think my UnitTest11 has that I should probably push more is it comes with a pretty decent mocking library integrated into it. It doesn't automock since this cannot yet be done cross-platform. I would love for a new version of C++ to include compile-time reflection that would allow this functionality...

65

SFML projects / Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)

« on: February 05, 2014, 06:24:14 am »

std::shared_ptr<void> voidPtr = std::make_shared<int>(10);
std::shared_ptr<int> intPtr = std::static_pointer_cast<int>(voidPtr);

std::shared_ptr<int> intPtr = std::make_shared<int>(10);
std::weak_ptr<void> voidPtr = intPtr;
std::shared_ptr<void> sharedVoidPtr = voidPtr.lock();
std::shared_ptr<int> otherIntrPtr = std::static_pointer_cast<int>(sharedVoidPtr);

As I understand the term, shared_ptr offers a fairly safe type-erasement, because the shared_ptr will pass the correct destructor functor to std::shared_ptr<void>, meaning if it falls out of scope everything will still get deconstructed safely. shared_ptr supports move semantics, and for avoiding circular references you can always weak_ptr.

A cache can nowadays just store the weak_ptrs, it then tried to lock the weak_ptr when someone requested the resource. If the lock returned a valid shared_ptr, just return that. If not, reacquire the resource.

66

General discussions / Re: Mutual following on Twitter!

« on: February 01, 2014, 03:04:28 am »

If networking is the name of the game, https://twitter.com/morleydev

67

SFML projects / Re: Feather Kit - A C++ Game Framework

« on: January 21, 2014, 06:03:56 pm »

Interesting, I was working with similar ideas awhile ago. It was workable but I was never happy enough with my solution to release it though. Will have to dig into your code more to see how you approached some parts.

For events most my woes came from how I used std::function instead of inheritance for the message receivers. My main issue was with handling removal of a receiver (since you can't compare), and in the end I settled on adding a receiver returned a movable RAII object that on final deconstruction would remove the handler from the dispatcher. A solution with problems, but workable.

I guess the main difference looking is the higher level stuff.

My entity-component system didn't have entities directly knowing their components, instead they only existed as a UUID EntityId stored in a centralised datastore that mapped that id to components. Then the interface was based around getting all entities with a specific subset of components and doing operations on the datastore to CRUD those entities.

I also opted not to use a stack or FSM system for game state, instead there were a set of discrete Controllers that responded to events and enable/disable themselves as needed.

But yeah, looking at this I like the basic design of it. The emscripten support is awesome, and I can appreciate the headaches that must of caused to get working.

68

General discussions / Re: Favorite IDE

« on: November 20, 2013, 06:29:13 pm »

If we're going pictures, what Visual Studio has going for it over all other C++ IDEs at the moment for me is summed up in this picture:



It's a plugin, true (actually I use two for C++) but none-the-less that I can put the cursor over graphics::Texture and hit Alt+Enter and have that appear is nice...Are there any other C++ IDEs that offer this kind of thing, but perhaps have better C++11 support (the plugin doesn't recognise Variadics yet)?

I know a lot of code completion works via Clang nowadays, any refactoring tools leveraged that yet?

69

General discussions / Re: Favorite IDE

« on: November 14, 2013, 06:27:42 pm »

Favourite? For editing, probably Visual Studio 2013 with Visual Assist X.

As a student I got a hefty discount on Visual Assist X. So far it's the best refactoring and coding tool for C++ I've found, although I did recently get access to the Resharper C++ Early Access. Whilst RC++ lacks some important features (for example it does not yet understand Variadic Templates), JetBrains know their stuff and I've already seen things in it that impress me enough to think it could easily become the principal refactoring tool for C++ in the future.

Likewise the upcoming C++ IDE from JetBrains is really the only thing I can see that could challenge Visual Studio for C++ editing for me, especially given it'll be cross platform. I already use IntelliJ for Java and Scala and love it (it's definitely the best IDE for Java by far) so I have some high expectations there.

If I'm on Linux, I'm usually working in the shell so honestly I just use Vim with a bunch of plugins for code completion and the like. I think the best actual IDEs I've found for C++ on Linux are either Eclipse of Code::Lite but neither were reliable enough for my tastes. Never got around to trying KDevelop.

70

General discussions / Re: SuperLongName.com - a new kind of gaming hosting site.[FREE]

« on: November 06, 2013, 04:02:58 pm »

Interesting. So it's a blog/comic/game hosting PaaS type thing? The web interface looks a bit under-developed at the moment, it could benefit from being more reactive the the size of the viewing window. On a 1080p monitor it's very vertical and there is a lot of horizontally wasted screen real-estate.

What advantages does it offer over something more established such as Desura for game distribution? Do you host game files? If so, service guarantees and back-up strategies are always useful to present to your potential client/user as well. Plus, I'm always impressed by high-level descriptions of the back-end. Is it a distributed system, or is it a centralised single server? If you plan to potentially deliver a lot of games to a lot of users, then that's a pretty complex bandwidth-intensive set-up, how will you solve that problem?

Essentially, what business and technical benefits would this service offer me over competitors?

71

General discussions / Re: Exceptions in SFML 3 ?

« on: October 14, 2013, 10:12:25 pm »

"Exceptions are for the exceptional". The blog post in the thread that spawned this one makes a good statement: They are best used in the situations where you did everything right, but it still didn't work because of situations largely out of your control or what could be reasonably expected of you.

However, the question then becomes does SFML provide the means to perform that checking, to "do everything right"? And in what situations does the language sufficiently provide them?

Take the file example, should SFML provide the means to check if an image file exists? And it's decodable? Well the only good way to check the latter is to decode the image so it can easily be argued a non-decodable image is more or less an exceptional death scenario. But the former part, that a suggested file exists. Is that within SFML's scope? I'm not asking that because I think it isn't, this is more a question to promote discussion since I'm unsure.

And yeah, exceptions are often overused in Java. I can't stand checked exceptions, and the saner usage of exceptions are one of the reasons I much prefer Scala and C# for that kind of development.

As for Nexus' earlier suggestion about dropping C++03 support in SFML 3...yes please? It's been long enough since C++11 went gold. and SFML 2 is very usable by those constrained to C++03. I believe the need for new libraries to support C++03 has passed for the majority of situations (with the exceptions that I would avoid the threading part of the standard when possible until MinGW consistently supports it without needing experimental builds).

And as for following those library design guides, only part I really disagree with is the avoidance of inheritance and virtual functions. That rule is well suited for purely algorithmic libraries and code such as the STL, but I wouldn't say it applies for something such as SFML.

72

General discussions / Re: Exceptions in SFML 3 ?

« on: October 14, 2013, 08:43:00 pm »

My point way-back-when was simply that I find it conceptually simpler that an Image is simply an Image, all it does is be an Image and all it knows is how to be an Image. Not create one, not decode one from a PNG or JPEG file, just be an Image. People disagree, cool, I can accept that and understand why. I defend my opinion as reasonable but can understand the others and see that they too are reasonable.

Plus, I also acknowledge that the significant rewrite it would take would be presently more effort than gain. I feel that has caused some confusion, I may have not made it clear I've been having a theoretical conversation that I acknowledge has some practical limitations with the current system that would most likely make such a redesign more effort than it's worth.

Although with you're diagram...Well, I may be an odd duck since my first step when confused with a library usually isn't to browse the documentation but to browse the autocomplete and even the headers for something that looks useful and see if I can use that. If they fail, documentation is the next port of call before 'random googling in the hope someone posted something on a forum somewhere'.

EDIT: And I was in the middle of rewriting this, so...I guess I'll move it here. Exceptions!

I am being won over by the "two-interface" approach, main concern would be a lot of boilerplate code would get into SFML though and it'd be annoying to maintain.

I'm guessing there'd one implementation that outs the error, and one that passes through to that outed error and throws a different exception based on the error? Or the other way around? Actually I'd probably prefer the other way around, it lets SFML at least keep the advantages of exceptions internally even if that doesn't get exposed to the user who doesn't want them.

Either way, it seems like it could be a lot of boilerplate to do that for every function that could throw an exception.

73

General discussions / Re: Exceptions in SFML 3 ?

« on: October 14, 2013, 07:53:03 pm »

Oh yes, it's always a trade-off that calls for pragmatism. I like and encountered most the phrase "Diminishing Returns" to describe it. Stop when the returns start to become diminishing, and continue again the next time you need to go to that code and the returns have become undiminishing again. It'd say it's more something it's good to strive towards.

But for a library I guess a degree more up-front design must be done than other projects which can limit the ability to be iterative.

For tools, Visual Assist X is a good start. I use it, it's good for exploring but the actual code modification tools are still a little limited. But it's C++, and comes with the territory. Still gonna miss the one-button "Extract Class" option xD

The solution to things that shouldn't be 'public api' but are by nature of the language..., well the cowboy in me says if it's not documented, don't count on it continuing to exist. But that's probably not a good attitude, hence why I call it "Cowboy Me".  The most common way I see usually involves a detail namespace in C++. SFML seems to take the "put those internals into the CPP files and compile them in" approach.

*sigh* I'm going more into general design approaches now because this is something I just find generally interesting, and straying away from the main SFML topic.

74

General discussions / Re: Exceptions in SFML 3 ?

« on: October 14, 2013, 06:25:44 pm »

In my experience, the most common solution to situations where a deep inheritance tree or "friends" are starting to form is usually that if X needs to know about an underlying part of Y, then that is not truly an underlying part of Y but a separate Z waiting to be extracted.

Usually if you need friend, it's because there's a third class sitting in there somewhere, a dependency to extract that can marry the two. Extract it, make it it's own beast, and then inject it where needed.

But this kind of thing is much easier to do in languages with good refactoring toolage. C++ is not one of those languages, the available refactoring tools are limited and rather primitive compared to a lot of other languages. It's why I'm eagerly watching JetBrain's upcoming C++ IDE. They provide some of the best tools for developing in Java and C#, and to add C++ to that list? Gives me goosebumps.

The logic goes that the less an individual class/function does by itself whilst still fulfilling the duty given to it, the better because it means that each class/function is easier for the programmer/user to understand, to comprehend and to use effectively and efficiently, and so by reducing the complexity the possible mistakes and bugs in any given part of the system are reduced.

The more something does, the more complex it becomes, the more difficult it is to grasp it conceptually in it's entirety at any given moment. Quite simply, the more something can do the more you have to remember could be done to it and with it, the more difficult it is to use and maintain.

You have to remember more ways it can be manipulated and consider when those manipulations could happen and what their effects would be, and it makes coding in it more difficult, because you have to remember more ways it can be manipulated and how that could change the internals of the class and how the externals interact with it. It's more of a cognitive burden.

It also helps that having many small tools often brings greater flexibility by allowing for the composition of those small tools to achieve a wider variety of results with less effort.

75

General discussions / Re: Exceptions in SFML 3 ?

« on: October 14, 2013, 12:49:31 am »

We are getting rather distracted with the Image part of this, streams like for sound do add some complexity...hmm. I find it funny this was literally an aside-comment of mine, and it's turned into a debate alongside the exception one >.< Makes me feel guilty.

I definitely agree if any library did go this way, it would be useful to provide a facade to hide the complex innards that are unneeded for the basic use-cases. But I would expect that facade to need to be be nothing more than a few line long negotiator between the existing classes/functions.

I don't really see the problem with loadFromMemory/loadFromStream.  I never felt they were "straying from the way SFML wants you to do these things."

Yeah, I didn't like my wording of that so I removed it from the post right after I clicked "post" xD Guess you saw the old version >.<