Slick Forums

Ok, I have a difficult time finishing games, not so much starting them. Let's hope by entering this contest I have reason enough to finish a game.

My entry is called "Modulus" (suggested by a co-worker). It's a space domination game, RTS based, and you battle enemy fleet with your own fleet of composed ships. Gameplay is somewhat inspired by Gratuitous Space Battle and Upgrade Complete!, my own previous strategy games (unfinished, Towerfield, Galactic Commander), and even Minecraft and Desktop Tower Defense. I use my own unique minimalistic graphical style. But still, it's quite a unique concept I believe.

The player creates ship templates by selecting "modules" from a list and dropping them to the template. Each module is a hexagon tile, and all modules are of equal size. The modules vary from hull to cannons and to propulsion.

Once the templates have been defined the player can drop instances of them into a overview of the battle world. He is limited by $$$ how many ships he can drop. Once done, he hits play and commands the ships in battle against another formidable fleet of AI controlled ships.

There will be a few battles to play, all very difficult to beat and different environment that require different type of ships. E.g. there might be asteroids hitting the ships dealing damage, requiring heavy armor or anti-missile defense, or radiation requiring deflection shields.

No one configuration of ships will work in all battles, so the trick will be to find the "right" configuration for each battle.

I'll post updates as needed.

Day 1 (yesterday)

Spent the time mainly doing the graphical concept work. Very simplistic but hopefully effective. Here are the results:
http://gamadu.com/temp/modulus/design2.png (won't embed because of size)

Currently I'm pondering how to implement some sort of nesting feature in Artemis. Easier said than done, probably the biggest weakness with Artemis currently. How do I interconnect all these different modules and make them behave and interact as it was one ship? Hmm..

1. Hmm..make a component called "MasterEntity" with a member variable named "entityId"?
2. Use the tag manager for the master entity with an id prefix?

I'm experimenting with two components now:

"Children" component that would be attached to the "master" entity. (not sure if I need this one though).
"Parent" component that would be attached to any child entity.

Then I have a system that is called NestingSystem, that processes all entities with a Parent component and updates it's transformation (x,y,rotation) according to the transform of it's parent entity.

A thought: I might need to store the "local transformation" somewhere, because I have no way of calculating the "world transformation" if I don't have the local one.


edit: TagManager shouldn't be used for this purpose, only for very special entities like "PLAYER" or "TERRAIN" or something very specific and unique.

Looks great, looking forward to how this game shapes up.


This is the same reason I entered

nice concept! I love this kind of graphical style!

- Do you plan to use Artemis for it?
- it's all real time or turn based ? Or real time with tactical pause? With many ships could be a problem after some time to keep exact control of all my ships!
- Can player choose color of ships or they are faction based?
- Different part of ship are colored different? For example Weapon = red, Shied = green and so on ?

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

- Artemis, yes, hopefully.
- Real-time, although slow paced. You can order your ships to move, not attack.
- One color per faction. Perhaps player can choose color. Not a big thing really.
- Well... maybe not like that, but I'll need to give this some thought. I could make the fill color of different shade for offensive vs. defensive vs. support modules.

Wow, very impressive!

_________________
=)

Day 2

I've solved the nesting issue. I have created 3 components:
- Children, that is attached to the root entity, and contains bag of child entities. (not needed)
- Parent, that is attached to child entities and contains reference to parent entity.
- LocalTransform, duplicate of Transform, but contains only relative transformation from the transformation of parent entity.

And a system called NestingSystem, that ensures that all entities possessing Transform, LocalTransform, Parent, are updated so that Transform represent absolute world transformation, using the transformation in parent entity and local transformation.

In theory this allows for multi-nesting.

Maybe not ideal, but works for now.

I like your abstract but cool looking graphics style. I already loved your tanke game demo! That's really an appealing graphics style to stay with.

I'm looking forward to see how Artemis works for your game - would love to see the source code when it's done.

I really had to chuckle when I read that your component based system doesn't work well for nesting - I thought that's what they are good at

But great to hear that you managed to solve that issue!

Good luck with your entry - sounds very promising!

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

It's just that I never really had to solve that issue After a moment of thought I realized it's really simple.

how will you make sure that you are updating your transformations top to bottom?

ie: a system rotated one entity that is in the middle of a tree so its LocalTransform is changed, but the Transform isn't if your NestingSystem tries to update a child of that entity then it will use an invalid Transform from its parent, unless the parent was updated first.

In a normal SceneGraph you would update transforms top to bottom to ensure that the parent world transform is updated before the children need it and then if needed update bounding boxes bottom to top.

_________________

Game Dev Blog

Thank you for your comment.

I'll change my design, you're right.

Already have an idea how to do this properly.

Ok, it's solved using a SceneGraphSystem and a Node component.

SceneGraphSystem has bag of "root" entities (that have null parent).

Node has reference to parent entity and a bag of children entities.

SceneGraphSystem processes the root bag, and for each root entity it processes it's bag of children. For each child it updates it's world transformation according to the parent transformation, and then continues iterating like that.

That ensures top down iteration.

Scenegraph working: