Dan Violet Sagmiller

I have a random map generator, that essentially uses the X/Y location of the tile as the seed to identify its tile type.  (infinite terrain without needing to save it)

However, its too random.  the terrain is peppered with any terrain type.  I would like it to be more splotchy.

What I was planning, was to divide it into regions (like x >> 4, y >> 4) of 16x16 to increase the likely hood of a particular type, but then I end up with squares.  any thoughts? 

Here is the code I use:  

    public static int PickANumber0ThoughN(int seed, int x, int y, int range)
    {
        uint hash = (uint)seed;
        hash ^= (uint)x;
        hash *= 0x51d7348d;
        hash ^= 0x85dbdda2;
        hash = (hash << 16) ^ (hash >> 16);
        hash *= 0x7588f287;
        hash ^= (uint)y;
        hash *= 0x487a5559;
        hash ^= 0x64887219;
        hash = (hash << 16) ^ (hash >> 16);
        hash *= 0x63288691;
        return (int)(hash % range);
    }

Does any one know a good site where younger kids, say ages 8-12, can go to work on game development together, with forums, and content sharing?

Thanks.

-Compress the minimap near the edges. First you see people, then you see houses, then villages, then big cities(, then huge landscapes?) but all the same size. This might be difficult to pull off, but would be certainly interesting. Near youre interested in the small stuff, far youre interested in things like big cities, mountains etc.
Imagine like if it was a sphere, more land area near the edges.

I like this, instead of a rectangular minimap, I could use a magnifying glass.  With each ring out being a lower resolution.  Probably will end up being a lot of work/processing though.

a [+] and [-] key

That seems like a good idea.  +/- buttons/key responses.  

What was the game like btw?

City Builder Game.  Web Based, 3D.  Like Sim City classic but fairly expansive.

Minimaps are kinda useless unless they have symbolic content, such as quest-givers, doors, walls, your mount or pet if it's possible to lose it somewhere, an of course nearby enemies. Water, unclimbable slopes, and gatherables would all be nice too.

You also bring up a good point.  Its not the map that is important, but the content.  It seems that instead of a Map, I need to be looking at how to identify what is important to a player.  And how to get to that.  It doesn't "need" to have a mini map.  More along the lines of another way to list the buildings, alerts, events, etc and get to them quickly.  Such as events show up with an arrow pointing off screen.  you can move to follow the arrow, or you can just click on it, at be taken there.  

I should also consider something else.  I built the engine to have a near infinite map, because the terrain generator was fairly easy to build  (procedural, based on TileX/Y & PlayerId)  Just because I built it, does not mean I should use it.  Limiting a players range could also be part of the games increase over time.originally a 20sqkm to begin with, but then increase it as bonuses.  The range would be limited, but I could set up a function where you just buy more land, each time essentially doubling it, as much as the user wants to spend.

There are several considerations here, and I'll need to weigh them carefully for their value in the end product.

Thanks for everyone's help so far.

I think instead of taking on the whole thing, take on just a part or two.  For instance, You get a certain number of drag and drop commands, and a certain problem that must be solved with it.  You explain how the pieces work together, like a push, or a copy, and ultimately get the final value that you need.  You can make the other additional notes available, so people can understand that this game actually is assembly, setting the registers, etc...   As you add more layers, you can slide over to the next section, where you interact with different parts of the processor, and as command types come in, you route them to the different parts of the processor.  Then in another section dive in further. by getting basic gate logic, and create the IC's.  Presenting puzzles to resolve.  Even dive down to the electron, and how it is pushed through the wire at a very slow rate.  Push electrons through like water/pipes game.  but showing how it works.  Add a resistor, a capacitor, and see how it affects the flow.

I think a key trick to this is finding existing games that you can apply the same logic to. IC's could be part of a pipe game.  Some let water through some slow it down, some store it up, but each "pipe" carries the IC symbol.  giving a realistic approach to the nature of it.  Diodes producing one way.   Then you have to get the power back to complete the pipe circuit.  

Handling x86 instructional sets, like having a mask to identify which area of the ship to route the rest of the command through.  This could be like a mail sorting game, or a canal game, opening up the gates based on the first 4 colors on the tip of the ship.  and relating that to binary.  or Hex, 16 color codes for the first letter.

Each style of game play could be continuous.  As the player is working with IC's to control the water flow/return/use, it comes across with quiz questions related to what you've been doing, then continues with the level, and repeats the process.  Once all the quiz questions for that starter level are completed, a new level of that puzzle is introduced.  For instance, proven the use of resistors and lights, now you move on to capacitors and diodes, then add transistors and potentiometers, etc...   then introduce logic gates, to give decisions to the pipes, Not, And, Or, Xor, then memory, etc....   Then add commands structures.  Building the whole thing in pieces, trying to make a game that is fun on its own.  I think I would play this game.

It's just a distraction, really, not much better than a WIN button.

The rest of us probably doesn't even want to be aware of the possibility to chicken out so readily

I disagree with this.  For the same reason that millions of players enjoy Minecraft creative mode.  When they came out with Survival, they could have just turned creative off, and let it be a plugin to turn it back on, but they made it an integral part of the game.  If you talk about racing games, your car wouldn't get destroyed.  That doesn't mean you wouldn't see a slowdown when you hit things and enjoy the practice of gaining better control of the vehicle.  And first person shooters could be the same, where this mode lets you more safely just explore levels, and learn about other interesting places or secrets that you can apply in real life gaming.  Like Starcraft.  You can turn on Cheats, but as soon as you do, all awards get turned off.  Which is an enticement not to do it, but the option is still readily there.

However, I will give this significant issue.  I've played god mode on numerous games, for similar reasons as I posted above. I still had fun, but the levels were not designed for gods.  Normally, when you fall in a pit of lava, you just die.  Given that, a pit of lava doesn't expect to provide you with a way out if you fall in.  I've been stuck before in situations like that.  

I will concede that if you consider putting things like god mode, or easily activatable 'cheats' like flight, infinite ammo, no keys required, etc...  you need to make sure your game won't break down by getting a player stuck somewhere (or other equally un-fun scenarios).  Infinite ammo doesn't seem like an issue, until one of your designers thinks of an awesome idea that you enter a turret and shoot as many enemies as you can, until you run out of ammo.  If they didn't program in another way to exit the turret aside from running out of ammo, then the player is again stuck.  

I like the idea of being able to turn cheats on, just do it responsibly.

What would be really good, is that each time you die, and go back to a certain point, it shows flash backs of what the guards noticed/heard.  I.e. heard you hitting the torch with the rock, didn't see you in the cell/began search, torch on wall was gone, cell door was open, etc...  Even a little bit later (but not too far) things you did could still affect you.  So a great deal of the game is to make sure things are not out of place.  This will give you clues as to how to do things right, by showing you specifically what did not work.

 - One idea, is that when you get to the guard room, the second time, that you over hear "GO make one more round, and then you can take off for the night".  Now, you know that if you over power that guard on their trip, you can dress as them and just leave, up the stairs.  Nothing out of place.  

 - - replace the dummy in your cell, with the dead/unconscious guard, so the body isn't noticed.  

 - - Then, you start finding your way through another guard ridden cell section  That is mostly just a timing issue.  Once you get through it, you complete the level, and the past actions don't catch up with you.  The timing section after leaving the guard section, is to give the guards time to get back around, and 'notice' anything out of place, like a dead naked guard on the floor.  Once that happens, the exit to your level is sealed until the guards bring things to order, so you can fight them off, but what will ultimately will not complete the level.

Based on the image, I would start with an inventory.  

 - Hands, fingernails.

 - Shirt, Belt, Pants

 - Torch (Split into Club, Metal Bits(shielding), Flame, Fuel Source)

 - Potentially any loose material (Mud, potential Rock, rock bits)

 - Hair.

To be honest, the torch inside the room seems out of place.  Based on the logic you spoke about, who would put an ad-hoc version of a flaming mace in a prisoners cell?

Not that you'll take that suggestion, but I'll present some ideas that presume the torch is not in the room, however there still is one across the hall, well out of reach.

1, Gain rope.  

 - - Use Belt

 - - Turn Pants into shorts, by tearing strips off and tying them together.

2, Gain Torch

 - - Tie Lasso with rope.  hook it on the torch across the hall.  pull it back.  

3, Gain Rock

 - - feel the wall around the room, bumping pieces of it, until you find a lose piece.  work with it to remove it.

4, Gain Tools.

 - - Hit the metal of the torch with the rock until it breaks off. Makes a lot of noise, brings guards, losses fire/light.

5, Gain Tools with less noise.

 - - Blow out the torch and wrap your shirt in it.  Loses light.  Now hit with the rock, quieter, but not quiet enough.  Guards still come, though you get a moment more.

6, Gain dirt.  

 - - Scrape dirt off the ground, corners, walls, etc...  Collect a small handful of it, presuming damp/mud like.

7, Gain tools with near silence

 - - Repeat step 5, but this time place the dirt under it, to make less noise from the ground impacts.

(Given the nature of the game, you might want a worry bar, essentially a bar that rises as you worry about guards, traps, etc...  I.e. too much noise, coming up to a corner, etc...  Even though it won't do much for the game, players will quickly learn that it helps measure their actions, and they can choose lighter actions when replaying the same area.  (presuming numerous devastating fails.)

8, Gain Tools and Fire with near silence.

 - - repeat step 7, but carefully remove the fire/fuel source first.  - presume a split of a Wooden club, a metal bowl for holding the fuel, and the metal wrapping that also helps hold the fuel/fire, but now you can see light earlier.

9, open the cell.

 - - use the metal bits (tools) to open work with the door.  - doesn't work, guard comes by notices torch, you die.

10, Open the cell better. 

 - - Put the fuel/fire back into the metal bowl and carry that to hold the light.  pick the lock,   Before completing the lock pick, the bowl gets too hot, AOOHH! your drop it clank, guard comes, you die.  (essentially all my plans leave you defenseless, even with the club, until you can get out of the cell instead of being a fish in a barrel.)

11, Open the cell, succeed.

 - - Repeat step 10, but this time carry the bowl in the fabric from your shirt. it lights the way and doesn't get too hot.  This time, you pick the lock before a guard shows up.

12, Open the cell door

 - - CREEEEEEEAKKKKKK!  loud creaking noise brings guards.  But you don't have a club in hand

13, Open the door quieter

 - - Squeeze the dirt clump to get a finer mud liquid out, directly over the hinges, and work it into them.  When opening, there is still a noise, but not as loud.

You should leave the room with a club, a metal bowl of fire, a rope looped through your belt (from your pants shreddings), metal bits, and a bit of mud (where to put it though)

 - - Bit of dirt is in hand under bowl of fire?

 - - Bit of dirt is smeared all over you as a bit of camouflage?

If you have the dirt clump it can be thrown in eyes/face of a guard to distract them.

Some additional possibilities.  

1) Sleeping guard just down the hall, keys or weapon in ropes reach?  

2) using belt or shredded pants rope, produce noose, be ready for guard as they pass.  (this would be for more of a brawl type game)

3) Use the metal bits to remove the pins from the door hinges.

4) Complete the first part, attempt to reassemble the torch, put it back on the wall, use dirt to stuff up the key hole, so it doesn't latch again and shut the door.  Wait for the guard to pass and then follow them quietly.  

 - - This helps with the idea that if you get out, and go the direction that the patrolling guard is not, you will find it takes you almost immediately to a guard room, with others, armed.  then the patrolling guard calls out about the empty cell, and you are trapped in the path of both sets of guards, with nothing but a small wooden club for a weapon.

 - - If you follow the guard, you come up to the same spot, but now, they thing that way is cleared.  To make their rounds, they will leave out another entrance.  While they are distracted, you can take things from the edge of the room.  like a weapon, shield, change of clothes.

 - - With a changes of clothes and some batting material (could be other clothes or bags) you can sneak back to your cell again, setup a dummy in your old clothes, that looks like you sleeping in the corner.  Wait just out of site.  until the guard passes again.  Now, you can escape without sounding an alarm.  Or at least you can progress farther before that point.

In my Game Development classes, I commonly teach particle physics, to use for things like explosions and thrust.  I'm wondering what other interesting things you might use particle physics for.  Or different effects.  Here is just a handful of some I've used.

Color Changing

Alpha Changing

Directional Gravity

Orbital Gravity

Friction

Jitter

Connective, like Leash/Elasticity/Follow/Evade

Bump Logic, Bounce, Screen Wrap.

One other odd one, was identifying the color/location of each pixel in an image, placing them in an array, using the location as a target with orbital gravity, randomizing each location, and adding friction.  This created what appeared to be a star field that sat dormant, but when I activated its effects, all the stars on the screen pulled together to form an image.  Was really interesting.

I would also use this to "morph" an image into another, but scattering the pixels and applying color changers to each particle, and adding a bunch of invisible particles where it needed to add them that faded in to view.  It worked pretty nicely.

So, What other interesting particle effects have you seen/used.  I'm creating a list for students to consider.

I think that using things like system("pause") is just fine for a tutorial.  for one, you would typically present a tutorial by making everything that is not what the tutorial is focused on as simple as possible.  I'm sure your use of system("pause") gets the job done for what it needs, and is simpler than other solutions.

However, I would also recommend that you leave comments in your tutorial code at shortcuts like this to say something to this effect: "I used this code because it accomplishes [blah blah blah] in a quick and easy way.  If the Tutorial where focused on [same blah blah blah] I would have used something like this: [link to better code example]"

The point is that a good tutorial is usually focused on covering only one key topic (potentially multiple if strongly related) and that all other areas should require as little effort in understanding as possible.  Someone could get upset at a hello world app tutorial because an application that only writes out a line of hard coded text is essentially useless, but that is not a reflection on the tutorial's quality.

Actually, I do know how to make a menu. This question is for a real time rendering menu...

Several people have asked this, but I'm interested too.  

What kind of menu do you create that is not *real-time*?  Why is it not?  Are you creating menu's that some how have lag?

And what do you think makes a Real-Time menu?  I'm guessing that your just not asking your question in a way that anyone understands.  Real-time, is a common term.  According to Wikipedia, "Real-time programs must guarantee response within strict time constraints."  And so when we create menus, we typically expect a response to the players actions to be instant. I.e. when the player clicks, there is no perceivable time that passes before the program reacts and either begins its animations to the next menu or immediately displays the next menu or what ever other task was expected.

The only thing I can imagine, is that your menus are somehow resolved based on Client/Server interactions.  I.e. you see lag/loss of real-time because of the network delays.  If that is the case, you should make sure that your client side has all the menu's it needs immediately, and that additional network based options load after the view is already visible.  Or, in a separate thread, download the menu options (for the menu items available to click) behind the scenes so that if it is clicked, it already has its content on the way.  and if you click something else, stop the loading threads that aren't associated with the new menu.

Again, if you are expecting to purchase a component for this, you need to include what engine or language you are developing your game in.  HTML?  Silverlight, Unity, GameMaker, C++, Java, etc...?  Any menu components that exist are typically dependant on that information at least.  But honestly, most people just develop their own, as the menus are far easier than the rest of the game development.

 You may also want to consider where you are spending your time and money on this project.  Unless the 'fun' of your games is in the menu system, you should really just put the easiest/most obvious thing in for it, and spend your time on the components people will play.

The Controller handles all input from keyboard, mouse, timers and OS signals.

Typically the controller is also the place for handling all logic.  If you look at the MVC Wiki page, it shows the Controller as manipulating the model.

The Model knows about the game state and all objects in it. It is not real-time. It has input functions called by the Controller that will trig actions and update the time.

'real-time' has to do with the total time it takes for something to get back to the user in a way that they don't perceive a lag between their interactions and what they see, including all model changes.  I can't think of a game where the MVC as a whole is not in real time, unless your talking about a save/load button, or the start of a level.  But typically once going, the model/controller/view all act as one real-time responsive unit.

The View asks the Model about its state, and draws it accordingly.  The View will also take orders from the Controller, e.g. toggling between first person and third person or showing/disabling a chat window.

Your right about the view asking the model for the state, but typically the toggling between 1st/3rd Person Perspectives would also be stored as model data.  You should see the controller as the implementer of change, not as a constant updater of things that aren't changing.  I.e. something happens and the controller will change the state, view state being included in the model.

Essentially just look at the menu as an alternate state for your Update and Draw features.  I.e. If!InMenu - then draw the game, else draw the menu.  Then you have your menu show up as you would any other gameobjects, and your updates/interactions are just focused on presenting the menu now.

If you're talking about a particular engine, like Torque, GameMaker or Unity, there maybe some options to purchase an interesting menu system, but you need to include what engine your talking about.

I'm guessing this means there is something wrong with the crossdomain file.  either in structure or save format, but I'm not sure.  the exception doesn't give much more info.

All right, well, if that's the problem, I see three potential issues:

• You are missing a doctype declaration.
• You aren't setting a cross domain policy.
• Your web server may not be setting the right content type

How about this?
 

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
	<site-control permitted-cross-domain-policies="master-only"/>
	<allow-access-from domain="*"/>
	<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

And make sure your webserver is sending Content-Type: text/x-cross-domain-policy

You rock!  This xml solved it.

this probably would have been solved earlier had I noted your first response with the header xml.  I noticed and added the attribute, but did not notice the fact it was a different node/tag.    That was probably my original problem.  

Thanks.

I think what you have is pretty good.  However, instead of making your update check specific information about how many enemies there are, I would recommend creating a statically available boolean called shutDown = false;  (or an enum for GameState)  Then what ever might decide to shut off your game can just call the variable change for it.  Your update method won't check each area for reasons to shut down then.  Instead it just checks the one value.

But the key issue, is performance vs maintainability.  Your engine, 3D rendering, timing handlers, etc... should be performance based.  I.e. forgo easier to maintenance architectures for architectures that employ speed.  This for instance might be to use arrays instead of dynamic lists, pointers (bark bark) instead of copies and static references instead of lookups.  The layers of code that manage logic such as AI, level details, and mob generations would be best in a more manage able code approach.  I.e. highly structured code, preferring clearly named abstraction over direct but vague variable references.  Also larger separations of object code, to help organize data, instead of compressing more code purpose into one location.  Also preferring Dynammic easy to use lists, instead of additional code required for locked array sizes.

I see no problem in having a split in your architectures layout, as long as it is easy to distinguish where one stops and the other begins.  If your using an existing engine, like XNA, Unity, DirectX even, then you'll probably want all your code to be a logic oriented architecture (more maintainable)

That being said, I typically create an interface called "IModifier" (having .Modify()) and another called and "IPaintable". (having .Paint(View/Paint Object reference))

Then my main class will have a List<IModifier> Modifiers.  My update method does any generic things it needs to, like initializing the mouse coordinate variable, or keyboard variables, but then just calls ForEach(IModifier mod in Modifiers) mod.Modify();

And of course having a second loop that removes any objects marked for removal  (either another static list, or a flag on each game object to mark them for deletion)

I'll usualyl wrap that code up into a layer to manage its own cleanup.

The IModifable/IPaintable interfaces are a form of an Object Based Decorator Pattern.  Which I've found highly useful.  I typically create different Lists for managing different sets of objects, like playershots, enemy shots, enemies, stars, etc...  Then each object also gets a List inside for all its modifiers.  Modifiers would include things like friction, reactToMoustMovement, Gravity, TakeImpactFromEnemyShots, TakeImpactFromPlayerShots, etc...   Anytime I create an object, I simply create a generic GameOBject, set the image and position, and other variables, then apply a bunch of decorators to do what ever things it needs to.  Makes for something inredibly easy to manage.  

I'll also say that I'm sure there are many architectures that can work, I think the key is learning which to apply for your case that won't damage your performance.  Don't look for one perfect architecture.  Look for options, and figure out in what circumstances each work.  

I recommend looking through this to start out: Wikipedia's Software Design Pattern's List (the list is a page or two down, and broken apart a bit)

Out of curiosity, why don't you use the sprite fonts that are part of XNA. 

OOPS, a title near this one when I posted had said something about XNA and I confused it slightly with this one, presuming XNA, which as I recall allows the use of DX components.  

I'm creating my own C++ rendering engine for the sake of learning DX11. Not sure if XNA sprite fonts can be used in such application.

Yeah, same issue as prior, and I don't think XNA fonts would be usable in DX