Jump to content

  • Log In with Google      Sign In   
  • Create Account


Question about TD game's code design


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
4 replies to this topic

#1 Melkon   Members   -  Reputation: 452

Like
0Likes
Like

Posted 21 December 2013 - 04:28 AM

Hello!

 

I have a half finished TD and i decided to finish it. When i did that project i used pretty bad design, and i had a circular dependency, now i want to fix that.

 

The idea is:

Make a GameController class, the event loop run here, but GC won't handle it, it just decide who should handle it (the User interface or the map), and convert the mouseclick coordinate depending on the view of the handling class.

 

If there is an actual command from the UI (like Build XY Tower) the gamecontroller get it and drop down to the map to execute it.

 

I am sure it can work, but i am not entirely sure that's the best solution i can do.

 

Any opinion is appreciated!

Melkon



Sponsor:

#2 xenobrain   Members   -  Reputation: 581

Like
2Likes
Like

Posted 21 December 2013 - 08:58 PM

I'm on my phone so this answer will have to be much shorter than I would like to give.

Basically you want an event manager. One design is where The Input Manager would send a MouseDown event to the game view. The game view passes the event down to the screen layers, top to bottom.

The top screen layer is your GUI so it does a hit test to see if a button was pressed. If the "fire arrow tower" button was hit, send an event to the TowerSpawner system, which sets it's internal state to spawn fire arrow towers when it receives a MouseDown event.

It gets the MouseDown event when you click on a screen area not covered by the GUI. Basically the View picks up the MouseDown event from the InputManager again, then sends it to the top screen layer. The GUI Screen layer does a hit test again, it fails because no button was pressed, so the view passes the event down to the next screen layer, the scene view. The scene view passes it to subscribed system along with screen coordinate data, in this case the TowerSpawner system and in some games possibly the camera system, they react appropriately.

The TowerSpawner tries to spawn a tower at the current screen coordinates (or asks for a raycast from the screen coordinates if it's a 3d game) using the currently tower state that was set by the earlier button press.

Something like that would be a fairly common approach.

#3 Nathan2222   Members   -  Reputation: -403

Like
-1Likes
Like

Posted 22 December 2013 - 12:46 AM

What's TD
UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
:)
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy

#4 Bacterius   Crossbones+   -  Reputation: 7990

Like
0Likes
Like

Posted 22 December 2013 - 01:37 AM

What's TD

 

Tower defense.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#5 Melkon   Members   -  Reputation: 452

Like
0Likes
Like

Posted 22 December 2013 - 04:18 AM

I'm on my phone so this answer will have to be much shorter than I would like to give.

Basically you want an event manager. One design is where The Input Manager would send a MouseDown event to the game view. The game view passes the event down to the screen layers, top to bottom.

The top screen layer is your GUI so it does a hit test to see if a button was pressed. If the "fire arrow tower" button was hit, send an event to the TowerSpawner system, which sets it's internal state to spawn fire arrow towers when it receives a MouseDown event.

It gets the MouseDown event when you click on a screen area not covered by the GUI. Basically the View picks up the MouseDown event from the InputManager again, then sends it to the top screen layer. The GUI Screen layer does a hit test again, it fails because no button was pressed, so the view passes the event down to the next screen layer, the scene view. The scene view passes it to subscribed system along with screen coordinate data, in this case the TowerSpawner system and in some games possibly the camera system, they react appropriately.

The TowerSpawner tries to spawn a tower at the current screen coordinates (or asks for a raycast from the screen coordinates if it's a 3d game) using the currently tower state that was set by the earlier button press.

Something like that would be a fairly common approach.

 

Your solution is a bit more complicated than the solution i imagined. For example i didn't want a TowerSpawner system, as i imagined the GUI have a command, and i just get that command from the event loop and pass down to the map. The command can be also a Spell cast, not just Build tower, i don't exactly know yet how much thing can it be. I will think about that.

 

Thanks for your answer!






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