Jump to content

  • Log In with Google      Sign In   
  • Create Account

Waterlimon

Member Since 28 May 2011
Offline Last Active Today, 08:16 AM

#5224333 A brief discussion on design: handling visibility

Posted by Waterlimon on 19 April 2015 - 12:00 PM

Aww I wrote some stuff and accidentally hit backspace...

 

Anyways, I had the following idea:

 

First, the map has to be randomly generated.

 

You can only see the portion of the map directly/indirectly seen by currently active unit (units should share their view if theyre close enough).

 

Now, the player can draw freeform maps (either using some kind of pencil, or annotated points, or hexes, whatever). The map is in no way linked to the real world (it wont show where your units are, it shows nothing, everything is added on it manually).

 

So if the player sends out an exploration team, they get pushed around a bit by wind, end up in a storm, and after 10 years find land, the player has barely any idea where they are.

The player will explore around a bit with this exploration team, drawing a local map (centered around the "landing point" for example).

Now, the player also has a local map for the main base.

Then, the player can create a 3rd map, name it "global map", and drag and drop the two local maps onto this global map as single entities, positioning and rotating them in an attempt to make their relative positions as accurate as possible (perhaps the player knows the approximate direction the exploration team went, and the approximate speed, and hopes they didnt do a 180 turn on the way)

When further information is received, the player can adjust the global map by repositioning the local maps.

There can be as many maps as the player wants, and any map can be included in any other maps as many times as the player wants. So the player could have a map for each continent (filled with local maps), and a global map with the continents glued together.

 

Now, this mapping process takes time and effort, so it should obviously be central to the gameplay to make it worth implementing.

 

The maps are needed for efficient long distance navigation, so what can we do to make that really important?:

  • Unique resources found in far away places (find a way around the globe to get there faster? Maps should wrap around and be of random size so you never really know if you got around the planet or if you covered 25% of the map or if you circled it 4 times)
  • Knowing where an important location is on one local map, but needing to know where it is relative to another to be actually able to get there. Eg Exploration Team finds a map to a treasure. The map is relative to their current location and the player can use landmarks to figure out where the treasure is on that local map. But the Exploration Team lacks the resources to go after it, because of course its on another continent entirely. So, you need to know where the treasure is relative to Main Base in order to send a stronger team for it. In order to do this, you need to have a reasonably accurate global map where both the local map of Exploration Team and the local map of Main Base have been placed. If you have such a map, you will immediately know where to go from Main Base to get to the treasure. If you dont have a map like that, youre not getting there any time soon.
  • Knowing where the enemy is relative you in all directions once you find them. Maybe you only explored to the west (Wherever that is...) and find the enemy far away, but if you explored east you might have found them much closer to you. If you have a good global map, you would realize this immediately, but if you dont know the size of the planet, youll have no idea.
  • Maybe you need to create maps for traders or allies to properly interact with them. If your maps suck, the traders will never get to you and neither will your allies when youre in trouble. (it could be interesting if you could share your maps with your allies in multiplayer, so they can use them as parts of their global maps, or maybe teams have a combined pool of maps editable by the entire team)

 

Overall this could be fun, but the games will have to be very long (not a problem if single player. But for multiplayer It might make sense to have big teams where people can come and go, but the maps remain. Thats how maps evolved in real life anyways... Difficult to implement well though)




#5224257 how much xamarin and other cross platform api,s are good?

Posted by Waterlimon on 18 April 2015 - 07:20 PM

http://xamarin.com/faq

 

It says on iOS its compiled to a native ARM executable ahead of time, on android it doesnt explicitly say that (see this stackoverflow answer for reasons why). And it says ("your Xamarin app is compiled to a native binary, not interpreted") without specifying which platform, so both probably.




#5222675 How to create a circular orbit and an angry bird space like orbit ?

Posted by Waterlimon on 11 April 2015 - 05:55 PM

For the 'orbital decay' due to atmosphere (2nd problem), you can just apply some drag if the object is in the atmosphere.

 

Calculate the resistance force and apply it in the direction opposite to the velocity vector (as in slow down using that force)

 

IIRC

 

drag = objectCrossSectionalArea * objectSpeed^2 * airDensity * someConstant

 

where airDensity is a function of distance from planet center (or surface, doesnt really matter), see wiki article (seems complicated, so maybe you can just try a few simple functions like constant, linear, exponential etc. and see what works best).

 

You might want to not apply atmospheric effects above a certain altitude (define some cut-off point), so anything above that altitude wont be slowed down due to atmospheric drag.

 

A simple model would be constant air density + cut-off at some height (like in that angry birds pic, you could draw similar 'atmosphere circle' with constant air density inside and no air outside), which might be how angry birds does it.




#5222614 inifinite mass and a jitter problem

Posted by Waterlimon on 11 April 2015 - 10:35 AM

Need more specifics.

 

What do you mean by 'jitter'?

 

Post the collision detection/response code as well (or describe it carefully).




#5221850 [HLSL] Decreasing Shader Model from SM5 to SM2 (vs_5_0 to vs_4_0_level_9_3)

Posted by Waterlimon on 07 April 2015 - 09:13 AM

Less bones! :)




#5219612 Logo Feedback

Posted by Waterlimon on 27 March 2015 - 08:40 AM

Yeah, anteater was my first impression as well.

 

But the way its curled up in a ball or whatever doesnt really tell me much...




#5212294 problem with circular resource movement in strategy game

Posted by Waterlimon on 22 February 2015 - 11:51 AM

Do not write the same data you are reading, or at least write the system such that the iteration order adds no directional bias.

 

You can do this by double buffering the relevant game state.

 

A more memory efficient method, if you can guarantee that you only read data from adjacent tiles and write to the current tile, is to go on a row by row basis, and BEFORE writing to a row, save that entire row in its 'previous state'. Use that saved row for the reads that access that row when processing the next row (instead of reading the 'new state' you just wrote to that row!). And when processing the row itself, use a similar method for the other axis, as iterating from start of the row to the end of it.

 

Basically, make sure you are only using previous state when calculating the new state (you can forget the previous state when you no longer need it to save memory, and you dont need to save a copy until you are about to update it with new data).

 

 

This issue is usually discussed together with grid based fluid simulations (since iteration order bias can cause fluid to prefer to flow in one direction).

 

Another 'hackier' solution that is probably easier to add, is to change the iteration order between each update, such that the bias will even out over time. In your example, this would mean that sometimes you get that lock situation, but sometimes dont, so it still works out. This solution causes your simulation rules to be somewhat 'nondeterministic' or unpredictable, so take that into consideration.




#5210921 Different factions or different units

Posted by Waterlimon on 15 February 2015 - 10:22 PM

Factions can be there for two reasons. Either story forces you to have them, or they exist to give the game more content.

 

If youre not forced to have factions, I wouldnt have them. If you want to give players a big "A, B, or C?" decision, just do it at the beginning of the match based on for example what type of factory the player builds as the first production building, or a similar big choice that you cant really undo or youll be weakened.

Importantly, doing it ingame allows for more possibilities. Ingame, you can easily combine many decisions to give a ton of permutations (do I start with two tank factories, or one tank and one robot factory, or one plane factory and then save the remaining resources for later etc.). With factions, you can have only so many (=very few) options until it gets messy, AND its probably a lot more work for factions anyways, because you want them to look different and so on.

 

In that sense, choice of faction is no different from any other gameplay decision, except its usually costly for you to implement and balance, and offers very little extra depth to the game in comparison to adding some other game mechanics that offer far more options for far less cost.

 

Basically, if you COULD make factions be a decision of which is the first building you start with, do so. This gives you the freedom to make the system more interesting. If you choose your faction from a list at start of match, its very difficult to expand on the system. If you keep it ingame, you could lets say change faction midgame. Or belong to 4 factions at the same time at endgame. Treat it as not being different from other game mechanics.




#5210353 best and fastest way to understand a code written by some one else

Posted by Waterlimon on 12 February 2015 - 03:39 PM

Someone else who was trying to understand a big messy codebase in another thread benefited from documenting the code himself as going through it.

 

So create documentation for it as you read through (assuming you understand it to SOME extent)?




#5209721 Bug when dealing at around 1,000,000.0f of coordinates

Posted by Waterlimon on 09 February 2015 - 07:40 PM

Read about how floats work.

Probably just the limited precision causing issues because youre dealing with big numbers.


#5209024 Filling in the gap: What to do while waiting on the game to finish an action ?

Posted by Waterlimon on 06 February 2015 - 04:47 AM

Maybe add a general planning mode where you can place stuff to be built without having to commit to building them until you realize the plans.

Similar to orders I guess but not as concrete.


You can also add small things like scouting or doing mini ambushes with a few troops if you havel the time to micro them.

Adding customization of all kind could be fun so you can spend free time making your stuff look more badass by adding decorative spikes and stuff.

In my own experience the free time is needed to think of your next move or try to predict the enemy. So in that sense, dont make a game that plays out the same every time, so people needed all the time they can get to process the novel situation.


#5208450 Issue using 2D depth texture array and regular depth texture in same shader

Posted by Waterlimon on 03 February 2015 - 01:59 PM

err... update drivers?




#5208217 oblem with OpenMP for loop

Posted by Waterlimon on 02 February 2015 - 10:51 AM

This says the drawline operation is not guaranteed to be thread safe.

 

So you probably shouldnt be doing it anyways (applies to all drawing to the same graphics object instance thing basically).

 

 

If performance is an issue you could see if the methods that can draw multiple lines are faster, or switch to a modern GPU API to do the rendering in a HW accelerated way.




#5208082 Forward declarations of classes :S

Posted by Waterlimon on 01 February 2015 - 02:56 PM

You should include the forward declaration in all the files that need them. Dont rely on it implicitly being forward declared in some included header file (that just creates a confusing dependency that makes your stuff break if you remove the include, and it wont be as clear that its only a forward declaration of player that is available and not the full declaration).

 

Assuming what you need is the forward declaration only.




#5207275 Second programming language...

Posted by Waterlimon on 28 January 2015 - 03:33 PM

Learning Lua could be useful too, since you can use it as a lightweight scripting language with C++ and the language is quite compact/elegant so it should be easy to learn.






PARTNERS