Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Wrathnut

Member Since 02 Feb 2000
Offline Last Active Yesterday, 03:20 PM

#5088124 AI Visibility test in 2D

Posted by Wrathnut on 22 August 2013 - 10:10 AM

Actually your suggestion seems quite sound. Using an AAB that completely encompasses your AI's FOV could be done for a quick check to see if the player could be in the enemy AI's FOV. Then perform a raycast from the enemy to the player to determine if the player is actually in the line of sight of the enemy. Raycasting can be done using DDA. Which is pretty quick if you are only casting one ray.

 

I am not sure about your layer concept. If you mean the upper halfof the screen is a different layer vs the lower half. Then the same grid or matrix you use for collision detection is the same one you cast your ray into.




#4895934 Gamestates and their uselessness

Posted by Wrathnut on 20 December 2011 - 05:48 PM

In your case probably not. You need to find a solution that best fits your problem. Not try to fit your problem to a specific solution. If you continue to try you will be unhappy with your code and working on your project will be like going in to do battle with the framework of your game just so you can get it to behave in the way you want it to.

That sounds like something you do at work because you have to. Not something that you do as a hobby( Unless you are masochistic).

There have been a lot of good articles on the game entity architecture. I am not sure of you subscribe to game developer magazine. But they have an excellent article In last month's issue describing the past, current and future of the game entity architecture.

I believe it was the November 2011 issue. http://www.gdmag.com/
Otherwise there have been some excellent posts through-out these forums.

Although it sounds to me like you are pretty well versed in this architecture.


#4858651 Recursion in circuit - Where to detect?

Posted by Wrathnut on 07 September 2011 - 08:55 AM

I am not sure if this will answer your question, but in a digital logic sense you do not need recursion. Certain components will require a current or previous state(j-k flip flops) depending on your view point. You should sort your network list according to it's location in the current path from the source to the ground point of the circuit and update components in that order. Your sockets would be the nodes that update and the connections would be all components that are connected to that node. Mulch-branching nodes would be the biggest issue but a simple tree structure should suffice.

If you are just looking for the final state after one clock cycle this should be ok. If you are going to poll the circuit at any random interval you will need to sample it circuit at a minimum of twice your clock speed. For example if you have an led that lights up at some frequency regulated by your logic circuits you could watch it switch off and on.

:) I am also required to say that there is no difference between a digital circuit and an analogue circuit. Everything is analogue at a small enough time slice ;p


#4808806 RPG rules / mechanics / balance

Posted by Wrathnut on 09 May 2011 - 08:04 PM

Actually a really good reference book is probably one of the older Dungeons and Dragons rule books and a Dungeon Masters guide. I am sure out right using them would not be proper, but they show all of the rule sets, probability tables and stuff that have been used for years (what like 20 years or more?) in actual play. The play balancing, i.e. enemy difficulty and economy were controlled by the dungeon master, but the general guide lines are laid out.


PARTNERS