Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2006
Offline Last Active Today, 09:21 AM

#5281834 a* early exit on impossible set?

Posted by on 18 March 2016 - 05:42 AM

For my game aborting after X tries is enough, but if you want to use a bulletproof system, you should look into build waypoint islands. That is, every waypoint or tile get an island id. You start with processing the whole map once and whenever the topology changed (eg. connecting two islands), then before starting A* check if both waypoints (start and end) are on the same island. If you have lot of dynamic connections between islands (small houses with doors etc.), you could build an island graph (island A is reachable from island B etc.) and apply A* first on this island graph before going in detail.

#5281822 a* early exit on impossible set?

Posted by on 18 March 2016 - 03:07 AM

Just two tips. First limit the nodes you visit,abort if you do not find a solution with the given number of nodes. Second, start your search from the goal node (reverse search), with the assumption, that a goal is more often blocked then the entity, the algorithm will stop more often and earlier.

#5281816 Understanding the difference in how I should be drawing lots of objects

Posted by on 18 March 2016 - 01:45 AM

This is how I do it in my engine (first the basic idea):
1. One VBOs for all gui elements (text,buttons etc.)
2. Map the VBO, then write all widgets in the correct order to the VBO.
2.1 Remember the shader which will be used to render the widgets in a non-GPU memory (an ubershader + branching would work too).
3. Unmap the VBO
4. Bind the VBO.
5. for each widget activate shader & draw the widget (ranged draws).

To optimize it:
I. Use two VBOs, double buffering them which will display the GUI with one frame delay.
II. Merge the draw calls, if follow-up widgets use the same shader.

The latter works especially good for text rendering.

#5281815 Comments about HLSL array packing policy

Posted by on 18 March 2016 - 01:13 AM

Have you tried to move the intensity right after the pos, so that all your 3-component vectors are aligned again ? pos.x,pos.y,pos.z, intensity,col.r,col.g,col.b,is_on

#5281308 A moddable MMOG

Posted by on 15 March 2016 - 01:46 AM

A core game mechanism is more or less a single game mechanism, not a list. E.g. in a FPS shooter the core game mechanism is "shooting at stuff", regardless if you have a ladder-system, multiplayer,crafting,roleplaying system attached to it. If "shooting at stuff" is not fun, too clumpsy or whatever, your game will never work, regardless of how many other features you add.

> rely heavily on typical hack-and-slash mechanics

So, is this your core game mechanism ?

Zelda is a finished game and not a game mechanism. The importance of a core game mechanism is, that all other game mechanism you will add, will either support your CGM (good), will not support it at all (sometimes good/sometimes bad), will compete with it (bad!). E.g. if you have two really powerful CGM, you would actually develop two different games, so the supporting GM needs to respect its supporting role, else you would tear your game design (aka chasing your customers off).

Think about your CGM as what the player will experience first and for the rest of the game. Everything else can be introduced later.

So, if hack-and-slash mechanism is your core game mechanism, like in Diablo ? Start with it. Prototype it, test it out until it is fun.

#5281303 A moddable MMOG

Posted by on 15 March 2016 - 01:02 AM

A game is seldomly a technically problem , more often a design, time or cash problem (art/server farms etc.).

To get your design right, you should define your core game mechanism and ignore all the rest for now. Really, get your core game mechanism right and build the rest around it. If you start with all the features you want to add without knowing how your core game mechanism actually plays, you will throw a lot of stuff away and you will do a lot of refactoring.

So, what is your core game mechanism ?

#5280678 Selling a game on Steam- Steam and VAT cuts...?

Posted by on 11 March 2016 - 05:53 AM

> A digital publisher can buy the rights to a good for 90c per unit, sell it for $1 per unit, make a profit of 10c per unit, but then be required to pay 17c to a European tax office. WTF is up with that?

This is how it would work in germany more or less: As company you would pay € 0.90 which would include € ~0.17 VAT. Then, when you sell it for € 1 you would pay €0,19 VAT, but you can set this off, so that you only need to pay € 0,02 VAT actually, so only the end-consumer will need to "pay" the VAT, not the company.

#5280677 Cheating with graphics

Posted by on 11 March 2016 - 05:44 AM

Out of my head:

Indie shooter with high-level of abstraction: Superhot
High level of detail abstraction and color choice: The Witness
Extreme high abstraction: Geometry Wars
Detail abstraction: TF2
Shape abstraction: Minecraft

There are much more, but I would need to look them up.

1. Abstraction will help you to define limits (good for indie/hobby devs)
2. Limits will help you to define an unique style.
3. A unique style will help you to distinguish your title from others.
4. A distinguishable title will help you to attract people.

The worst think you could do as hobby/indie dev is to target realistic/mainstream art.

#5280651 A ray with an ending position?

Posted by on 11 March 2016 - 01:38 AM

Technically it is more or less the same, two vectors.

Semantically a line is has a start and end which can be represented as (position, position+direction) or (start_position,end_position). Well, a ray is typically a start point with a direction vector, so (position, direction), where direction is typically normalized.

Therefor it is easy to get a ray from a line by just normalizing the direction, either (position,normalize(direction)) or if you have a start-,endpoint you get (start_point, normalize(end_point-start_point)).

But, once you have a ray with an normalized direction, you can't extract the original line back.

#5280646 Selling a game on Steam- Steam and VAT cuts...?

Posted by on 11 March 2016 - 01:16 AM

The GST is most likely already included in the final price, much like over here in germany (thought we have a VAT of 19% :( ), I think that there's a tax agreement between USA and Australia. So, the developer will only see 90% of your $20 minus -30%. In each country, each market, customers will be used to different final prices. In some countries the final price will always include the VAT, in other countries people are used to add them on top.

#5280638 Cheating with graphics

Posted by on 10 March 2016 - 11:53 PM

Abstraction !

That is the best cheat. When you add more layers of abstractions, your art will automatically look more coherent. There are several games demonstrating that a high-level of abstraction looks pretty impressive and good.

So, here are the typically section where you can play around with different layers of abstraction:
1.color choice:
realistic->single color palette->single color palette->monochrome
2. shape:
realistic->simplified->blocky->geometric forms only
3. textures:
realistic->reduced detail(cartoon/TF2)->face colors only/flat shaded->non

#5280309 What AI Problems do YOU want discussed at the AI Summit?

Posted by on 09 March 2016 - 01:30 AM

What about AI directors, how would you approach them ?

You have a bunch of individual agents, everyone with his own set of abilities, subdivided into two groups. These groups encounter each other dynamically and a combat situation emerge.

I would like to see a AI director detecting such a scene and starting to direct the combat situation to make it more visual appealing. So, instead of each agent just following its own concerns (attack highest danger first, hide from counter etc.), a director would overwrite the behavior to generate a more interesting situation,e.g. a policeman using his radio to call support, two thugs in the backline dashing forward to interrupt him, while a police commander calls orders to someone else to protect the one with the radio....

#5280148 Selling a game on Steam- Steam and VAT cuts...?

Posted by on 08 March 2016 - 06:26 AM

It gets even more complicated, because you often need to pay VAT in the country where the person lives who bought your product (EU at least). So, when you are a french developer, selling your game over steam to a person living in germany, you need to pay the german VAT in germany. But I would be surprised if Steam would not do this for you. Eventuelly this would leave you with 50% of money... and then you need to pay taxes ...

#5278798 Dunbars number for game characters

Posted by on 01 March 2016 - 12:46 AM

> How many characters do you think most players will "care" about? Where "caring" means not just being disappointed by the failure and mechanical consequences, but actually feel sad about losing the character?

In games I think, that it is less a question of numbers, but a question of uniqueness. Games, like XCom (I only play the first part), have often very generic characters.

If you consider Game of Thrones, many important characters are easily tagged by some unique features or names, even if you don't remember their name. Most people knowing the series will immediatly know of whom I speak:
- the bastard lord
- the winterfell princess
- the sadistic bastard
- the queen
- the female knight
- the dragon queen
- the spider
- little finger
- the sadistic king
- the fire priestess
- the mountain
- the assassine girl

So I would suggeust to ignore more the numbers and to concentrate on unqiue features instead.

#5278650 Async Upload of Meshes

Posted by on 29 February 2016 - 01:49 AM

Yes, look into un-/map VBOs: https://www.opengl.org/sdk/docs/man/html/glUnmapBuffer.xhtml

You would approach this like this:
1. map VBO: this will give you a pointer to memory, which you can access from your CPU regardless of thread (just standard sync considerations, but independent of OGL context).
2. update the memory block
3. unmap VBO: this will result in an asynchronously upload if the memory is located in videomemory (DMA)
4. wait until VBO has been uploaded, then render it (else you will stall again).

The latter is important, don't try to use the VBO until the upload has been finished to avoid sync trouble. If you need to render something, either render a dummy or start uploading your mesh earlier and not just at the time of entering your vision.

Here are more readups: