Comments - Sploreg

We created a facebook group if you would like to chat there, please join us! Facebook.com

Hey, thanks for the feedback!
1) yes there will be a campaign, about 12-20 missions long. Plus some planned expansion levels if time permits.
2) Skirmish mode is on the drawing board, although not guaranteed to make it in. At least not yet.
3) Blobs only. You play the bad guy here, invading the towns and cities.
4) Yep, quite a few. The blobs are fairly customizable and change their abilities based on what they eat and absorb. So you can experiment and combine different items to get different effects.
5) yea that's planned. A lot of the HUD is just placeholder icons now, and they are sometimes hard to read, so that has to change.
6) dunno, probably not for the release. However the game will be fully moddable, so that would be an easy feature for a keen modder to add in.

yay!

JME3 is nice, although I am biased =)
The community is great and always fast to help with any issues that come up.
Glad you liked the article.

The Components aren't, and should not be, OO in design. The systems however absolutely should be.
The components are really just attributes, collections of primitive or maybe complex variables.
The author of your book is correct in saying that using only inheritance in OOP will make things difficult. And using an ES will help steer you in that safer direction.
I made sure to mention "no OOP" for components because all too many times I have seen (in my code and in other's) the occasional component that is subclassing another component. It's just a natural way of reducing duplicated code, but in ES it causes problems. Hopefully it will make people take a step back and think "what? really? I should take a careful look at what I am doing in here." I know it would have saved me time when I was learning about ES =)

A component should be really simple, and something that you can back by a database table or serialize easily over the network. Just be some getters() and setters() with no real operations in them; that's what the systems are for. And in a system you want to limit how many times you check "is this really an AttackComponent, or is it a subclass of it and do I need to handle that slightly differently?"

A decorator pattern needs a bit of work up-front by the class to know that it will be decorated. In ES the entity has no knowledge what any of its components are, it is just a happy little ID floating out there.

Thanks =)

Looking great!

Thanks! I want to keep the development fairly transparent to hopefully help others and occasionally solicit feedback on features.
I'm glad you like the game so far and I hope to keep you interested as it progresses =)

Thanks! We plan to post much more too on a regular basis.
Lots of practice from working on the open source jMonkeyEngine =)

I hope to post some updates every week, either detailed dev blog entries or at the least some screenshots.
Glad you are interested in it =)