Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


dublindan

Member Since 05 Oct 2002
Offline Last Active Aug 23 2014 01:22 PM

Posts I've Made

In Topic: How do you make these "long" web sites?

23 August 2014 - 01:22 PM

I really dislike parallax scrolling on websites. I find it very distracting and makes it hard to focus on the actual content. Please don't ever do it.


In Topic: Own game distribution platform?

23 August 2014 - 12:41 PM

I'm a gamer and I know a lot of other gamers and all of us use steam quite heavily. A handful occasionally buy games on gog.com too. Most buy humble bundles. Very few use any of the other distribution platforms (desura, origin, impulse). Personally, I wouldn't install anything other than steam, so as a gamer, its highly highly unlikely that I or almost all of the gamers I know would install another distribution platform.

 

Unless it has something EXTREMELY compelling.

 

I mean, more compelling than Humble Bundle's pay what you want bundles (or, at least, a bigger/better library of HIGH QUALITY games in that model). Indie games are a dime a dozen - the greatest find their way into Humble Bundles or get onto Steam through the greenlight program anyway, so a large free-for-all in Indie games doesn't cut it IMHO. Too much noise. So unless your "official" catalog is really great or has some insanely good exclusives, I don't see how this can compete without something else that is extremely compelling (and the only thing I can think of is _maybe_ a hybrid mix between Humble Bundle and Kickstarter, but I'm not sure if it would work or if that's enough).

 

I'm not sure what you can offer developers (especially medium and bigger studios) to help make your catalog great.

 

Sorry to be so negative, but its a very tough space to break into IMHO.


In Topic: Anybody left from the 2003 crowd?

06 January 2014 - 09:39 PM

Does anybody remember the pink gang? Though that may have been 2004.

I had a different username in those days.

In Topic: The 'Thick Client' is dead...

17 September 2013 - 11:46 AM

In my experience, native clients are not dead, at least in some industries when it makes sense (eg visualisation heavy or processing heavy applications and applications where offline access is desired). I've seen plenty of desktop GUI applications been built in Qt. I haven't seen that much in Java lately, but I'm sure it exists. Mobile native apps are also very popular.

 

There is definitely a trend of things moving to web apps, but I don't think its over yet for thick clients. It will probably become ever-more niche though in the coming years.


In Topic: Composition heavy OOP vs pure entity component systems?

23 August 2012 - 11:39 AM

Don't be too philosophical: classification of objects and relations are only important in software design if they are actually used.

I was merely pointing out how composition has a better real world analogue than inheritance. An analogy to explain how is-a isn't as clear cut as it first seems. In most software, you are unlikely to require the flexibility of adding or removing components at runtime, but I feel that in games, having the ability to do so should you want to is a huge bonus and allows you to do cool things that would otherwise be hard. Ideally, the development kit would be able to bake entities that do not use the flexibility so you don't pay for it if its not used, but I see that as an optimisation (which should be done later). I think it rarely makes sense to hard code limitations into the very design.

Howitzer and MachineGun because the distinction cannot possibly matter, ever, because all code works with generic Weapon entities.

Sure - I would see them as being the one Gun or Weapon component and the differences between them are defined purely in a data-driven way: their attributes have different values. Data-driven design is certainly a very good thing.

Removing pieces of objects is also utterly uninteresting from a software design viewpoint, not only because we never ask whether the mutilated object "is-a" something

Sure - but I often see it driving a design. Often people start with "Well, X is-a Y, so I'll derive X from Y and..." while I think this is the wrong approach. Instead, I feel is-a is only useful in the sense of "does it provide the interface I need?" - think of it like duck typing. So, instead of trying to figure out if something is a type of something else or if it has a something else instead and then building an inheritance hierarchy from this, I feel a better approach is to compose all components rather than inheriting from them.

I used to like hardcore OO a number of years ago, but these days I find it has too many limitations, both in design (as I've been trying to articulate in this thread) and technically: eg, OO and concurrency/parallelism, OO and cache/memory friendliness etc. Therefore I nowadays prefer a functional-programming approach, though I still code in a style that I would consider somewhat OO - except that my entities are now compositions of components with little or no inheritance in sight - functional programming makes it easy to compose both data and functions. When I program in C++, I obviously do use classes and even inheritance, but I still like to design my programs with functional programming in mind and I find that it not only simplifies the design and makes it more flexible (in real life that flexibility often gets traded off for performance later when its apparent that having two components instead of one is 1) not required and 2) a performance issue), but it also makes it easier to support concurrency safely and to solve cache/memory issues - hell, that was one of the big goals of component entity systems after all.

but more importantly because the altered entity is either in a valid state or corrupt, according to the invariants and expectations that the code contains; nothing uncertain or ambiguous can happen.

Sure. This is a very important point, regardless of the design.

PARTNERS