Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Breakout code design exercise


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 DjMaSh   Members   -  Reputation: 198

Like
0Likes
Like

Posted 02 February 2012 - 01:19 AM

Hi all,

Id like to do an exercise to come up with a code design for the traditional game breakout game (google if unsure)
using an entity component system to see what designs you all come up
with, and to practice my designing skills =P.

I have my own ideas how to design it, but im more interested in the way other people think, and hopefully I might learn a thing or 2.

Im particularly interested in designs engineered towards a data-driven entity
system such as Artemis, where data and behaviour are split into components, and systems processing those components:

http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/


For simplicity, I want to focus on:

Objects:
- Ball
- Paddle
- Blocks
- Powerups
- Bullet

Behaviours:
- Ball travels with linear velocity, initially at a random upward angle.
- Ball bounces off left, top, and right boundaries
- Ball bounces of blocks
- Ball bounces off paddle

- Paddle can move left and right

- Blocks disappear when a ball touches them
- Blocks disappear when a bullet touches them

- Powerups have a chance of spawning when a block disappears
- Powerups travel down the screen until they hit the bottom boundary, at which point they are destroyed.
- A powerup is engaged when it collides with the paddle
- Powerups do not collide with blocks
- Powerup 1 - Ball sticks to paddle instead of rebounding
- Powerup 2 - Paddle is elongated in size
- Powerup 3 - Paddle can shoot bullets when fire is pressed for x seconds

- Bullets travel up the screen
- Bullets are destroyed when they collide with a block
- Bullets are destroyed when they hit the top boundary

- 3 lives
- loose life when ball touches bottom boundary
- game over at 0 lives
- game win when blocks == 0


So yeah, if you could list the components you would use to build those 5 objects, and what systems you would use to implement those behaviours, and how those systems would process your chosen components.

This is all about the details!
Hopefully someone is actually keen to give this a crack lol.

There are so many different ways this could be done. Im interested in your way

Sponsor:

#2 Telios   Members   -  Reputation: 398

Like
0Likes
Like

Posted 02 February 2012 - 07:46 AM

I would say there is a difference between a data-driven system and a component-based system. That article describes a component based system.

Are you looking specifically for components? Otherwise this seems to be an appropriate design..

Attached Thumbnails

  • breakout.jpg


#3 DjMaSh   Members   -  Reputation: 198

Like
0Likes
Like

Posted 03 February 2012 - 05:49 AM

I would say there is a difference between a data-driven system and a component-based system. That article describes a component based system.


When I say data-driven im actually meaning data oriented, where data is separated into structs (components), and behaviour is separated into systems.

Are you looking specifically for components?


Yeah, Im interested in how you break down your components and systems. Do you have a system per component-type? or do systems process multiple components at once? Do your systems process lists of entities, grabbing the needed components off each, or do they just process lists of components?

Heres my example design:

Components:
* Position - x, y
* Visual - texture
* Motion - velocity
* Physics - mask, dimensions, shape type
* Input - touch position
* Identity - stores the type of object (ball, paddle, block, powerup)
* Player - stores number of lives
* Powerup1/2/3 - stores powerup type enum, and any state associated with the powerup (maybe a timer)

Systems:
* RenderSystem - renders all visual components
* CollisionSystem - updates velocities of motioncomponents, does collision detection and response with physics components, raises collision events
* InputSystem - processes drag components, setting x-position to mouse position
* CollisionEventSystem - defines what happens when a collision occurs, responds to collision events from collision system: spawns powerups, engages powerups, deletes blocks
* GameSystem - processes player component, checks when lives == 0, checks when blocks == 0
* PowerupSystem - processes all powerup components

What do you think? Im not sure the best way to handle events between systems. Or how to tell the type of an object, so when a circle collides with a rect, how i know that rect is a block and not a paddle. Thats wat I thought the identity component could be used for.

thoughts?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS