Hello! I'm looking to do something involving Procedural Generation, primarily 'tile dungeons' of various types. I'm planning to use a sort of templating method for this. Basically, I would define a set of 'masking' templates that would indicate whether a tile is a wall, a floor, or a door (The interiors of rooms would be filled in using a different algorithm such that while you might have a lot of rooms of the same shape, you'd have 'different' rooms). The algorithm would be something like:
1) Select a starting room and position.
2) Place the room on the map. (Remove any 'open' doors that have just become closed.)
3) Add all of it's 'open' doors (Meaning doors that haven't had a room attached to them) to a list.
4) Check 'open' doors size > 0
4.1) true: Select a room that can be attached to it. Then go to 2.
4.2) false: Check if certain gen requirements are met (Number of rooms, tile coverage, whether certain required rooms were placed, etc.)
4.2.1) true: Gen complete.
4.2.2) false: Backtrack and to last room addition and attempt to add a different room.

Anyway, I'm trying to figure out an efficient way of doing this. Beyond writing up all of the different room types, there's an issue that crops up when I attempt to add in doors of variable thickness: Like an opening into a hallway that is two tiles (Or if I can extend this to three dimensions two wide and several high). Any ideas/advice would be appreciated!

And the theme is "Minimalism"!

Know your Google Fu: "Adding autorun to a CD" http://www.wizbit.net/business_card_cd_creating_autorun_file.htm

You'll have to mess around with it if you're not using an actual .exe file. But you should be able to edit it to call "java -jar <executable name>" instead.

Yay, my cents!

AABB vs Polygon: Depends on how close to 'realistic' physics you want. Typically, your player will always be an AABB object with limited physics applied to them. That is: If they're standing on the ground then they're standing on the ground and gravity doesn't matter to them. At most, you'll do some basic 'friction' computations for slopes, differing ground types, etc.

The world: AABB can be good for doing a broad-phase resolution (There are MANY strategies). The only way an AABB agent can collide with something is when their AABBs intersect. After you find out that there MIGHT be a collision, then you go to the narrow-phase where you check the geometries. :3

Using the pastebin (Linked beneath the text box) please show us the code you're using for this? Because it sounds like there are multiple problems going on here.

When you use the setup UI it will generate an <Profject_Name>-android project. If you run that, it will create an APK in that project's /bin folder.

Ah, next time use the pastebin (Link below the text area) for a large chunk of code. :3

Alright, I was making some assumptions based on the code you had posted, here they are:
1) The player's location is represented by a screen pixel location (In this case, the center of their sprite).
2) You know the dimensions of your screen.

The first assumption leads to playerX being the player's X pixel location and that playerY is the player's Y pixel location. (I was hand typing things I try to keep the length of my variable names short, those two values are playerXLocation and playerYLocation respectively. Assuming that it's pixel data).
The second assumption allows us to find the displayed bounds of the screen by tiles. Let's say that the player's location is (400,500) and that the display is (480,320), and that tiles are 40 pixels wide/high. Looking at we can substitute and get
int startX = (playerX - halfWidth) / tileX - 1;
startX = (400 - 240) / 40 - 1;
startX = (160) / 40 - 1;
startX = 4 - 1;
startX = 3.
This means that to only call paint for tiles on the screen, we'd start drawing at 3 and end at some endX (Which we'd find in the same way).

Anyway, your paint loop would compute those four values and use them as a bounds for painting. Ah, I can post some code (My aborted platformer project) which has some code for doing the bound finding and paint loop.

Ack! While your case statement there will work (And you'll have to do probably do something like it somewhere) it's not the best way to handle that. This is more about your switch statement than anything. You should pull out that g.draw command and put it into a method that you call:

Then you can do something a bit better than that switch statement by doing something like:

Of course, translating the pixel values into indexes into a bounded array or something would result in better efficiency... But ah, getting off track there, hah.

Whew! That said for your problem about painting the only a sub-section of the map, you first need to decide how you're going to do it? Are you centering the displayed section on the player? And if so, when he gets to an edge of your map will the map stop following him?

If it doesn't stop then it's really simple:


For the other way (With the camera stopping at the edges) I've got a code snippet somewhere (It's a class that holds the screen bounds and stuff like that) but I'll have to dig it out.

I probably should have read the rules first. Initially I thought it was like an odd game of Go. However, it's a rather interest game and design. The only issue that I have is that the music annoys me (Personal opinion), but I always forgot about that a few seconds in (And it's easily disabled).

I should say that I'm trying it on an Android and haven't had any issues yet.

You might also look at Cortex Command. It seems to have some of the same things in it. But I've never played Soldat and am just basing things on the video of the game you posted. >.> I have played KAG though, and they're somewhat similar.

I can't believe how cool this is. I mean, seriously. This is so many kinds of amazing that I lack an adequate vocabulary to describe it.

The only suggestion that comes to mind currently is to, possibly, have the 'Result Link' open in a new tab/window when applicable instead of in the same window. If only because I tend to derp and forget to hold control. >.>

I used it thinking it was like others I've seen (Where it makes a collapse section). I forgot that this one just does the 'Highlight to see' thing. @.@

Yay, for even more beta testing/bugs, because it's a fun game.

In several of the game I've played (Perhaps all), near the middle of the map there is an 'invisible' mine layer, which just continuously drops mines into a single place. I say invisible, but it's not even really there. Can't shoot, can't do anything to the spot. Further, on the map in/around that area are several objects/things (I don't know what) that appear there that are not showing up in the actual game.

Ah, I think that a lot of ships don't keep up because many of them are just slower than the player's ship. I know I abuse that by loading down my other ships with guns and stuff, then my "flag" ship gets some mines and an extra engine to boost its speed. Then I get to drag all of these '900/400' weight ships around at a 28 speed.

As for how you can handle the fleet mechanics? My thought would be to allow the player to make a sort of "conglomeration" of ships, then allow them to decide which guns are allowed to fire within the conglomeration. So, you'd get to position the ships in your fleet in relation to your flag ship (So that you can actually use them to protect other ships), then select which guns would still be allowed to fire (Like indicate that the ones on this side are not allowed to fire. To make this less game breaking, something like lowering the speed of all other ships to the smallest in the formation would work (As well making the turn algorithm based on the max speeds of edge ships or something) and once a ship is damage past a certain point it goes into another AI that peals away and either tries to get back to a safe port or something.

Ah, I just had a crash while destroying an enemy ship. The results of the print out weren't too useful, hah.

I'll end up playing some more tomorrow (I need to work on some AI stuff myself, hah).

Typically, the red fleet not responding seems to happen not only when you've played for a while, but after you've started missions that cause them to spawn (Typically the Merchanter Fleet mission, at least in my experience). However, I did notice that the stationary protectors during the 'Take Red Port' mission do still target and attack. Further, when I did that one as well, there was a single ship that was slowly rotating in place, dropping mines as soon as it could.

The crashes tend to happen only the first time I attempt the mission (Like say if I've done it once already and restart, it's never crashed on a restart.)

With the AI shooting you, I think that the biggest issue there is two fold (And neither is really easy to fix):
Bullets travel relatively slow, at least compared to the speed of the ships themselves. A cannon shoots at upwards of 100m/s while a ship travels at around 13m/s (This is a guestimate based on knowledge and calculations. A lot depends on what type of ship yours are supposed to be). While it was somewhat easy to miss at ranges, when you were close, it was likely that your broad side would hit without the other side being able to avoid simply due to speed. I know that fast projectiles just aren't as aesthetically pleasing/fun to play against though (I know I hate it games when I'm hit by things I have no chance to avoid.)
The above is compounded by the 'cheat' used for the fleets. However, without rewriting all of that, I can't see that being fixed so easily.

Most of my suggestions on how to change the weapons would make them more difficult to play with (Or at least make fighting a bit more difficult). Somethings like making the rotational turrets fire in an arc instead of a straight line (By that, I mean that the bullets should arch up towards the viewer then back down, with only the last few ticks of the bullets being dangerous), which is targeted using the mouse. Some control on the facing of stationary turrets (Unless I missed that already being there) would probably be easier to implement and make those weapons more useful for fleet ships.

The next few times I played, the crashing issue wasn't nearly so big of an issue. Of course, that was because I had a fleet and they just blasted through the enemies.

I did, however, run into a few more issue when I started to run missions.
Some weapons impact against your fleet while others do not: Guns and Torpedoes pose a great hazard to your own fleet, with your own ships typically dealing much damage to you than to your enemies (I know that I was shot to death by torpedoes on my own ships when I ran straight into an enemy). Mines though do not pose a danger if they come from your own ships, which makes them almost game breaking since you can lay out a ton prior to an encounter and make your opponents follow you through them.
Enemy ships (Red fleet) stopped reacting to me in general (Enough so that I could just sit there and bombard them without taking any damage in return). Other fleets would still react correctly and fight (Green would turn hostile when attacked, blue was always hostile with more spawning when I had cargo).
Selecting missions will sometimes cause the game to just crash (I'll start running the game through the console so that I can see what happens).

As a further idea/suggestion: A method for assigning fleet position/distribution. It seems somewhat random when you leave port (Beyond being able to select your first ship) and it can lead to some dangerous situations, such as the torpedos on a trailing ship hitting you suddenly (And painfully) because you didn't make a turn and things like that.

And sorry, I like the concept enough that I'll be bugging you for these things. Hah.

Yes, it would be nice to have some idea of what the various people are doing (Especially since after the entry screen there's no explanation of who is what/where).

Before you work on things like rivers it would probably be better to work on the collisions, especially if the resulting rivers are less Mississippi/Nile and more like something else.

As for the pop-ups? Why not use layers instead? Freeze the game state, draw it, then make up your own pop-up style over the top of the game's state. Sort of like what you do for ports, but taking up a smaller part of the screen.

I'm just happy to see someone do a game like this, it reminds me of the old Escape Velocity games (Which were space faring rather than see faring). I mean over all? It looks great. And I honestly love the graphics style.

Another suggestion, as an alternative (Since I tend to end up getting on the bad side of the pirates really fast), is to have some option for ship-to-ship communications so that you can offer brides/buy things off close-by ships, things like that. It might be far off, but from what you've gotten up so far it doesn't look as though it would be too difficult to arrange.

Ah, instead of a hard game over, perhaps something like an 'escape pod' or the like, which can be used as an option?

Also, some sort of collision mechanic that goes beyond 'bouncing' off of enemies would be nice. When make a high speed escape and you just come to a dead halt when you hit a stationary enemy would nice.

Another thing you have to keep in mind when coming up with a story/plot for games is how you want the story to be able to progress?

Is it an old-style linear RPG where each major plot event has to occur before the next is allowed to (Think games like older Final Fantasies, where you have to go to Town A and complete some plot event before you're allowed to go to Town B and really do anything.) Or, is it a splitting style like many of Bioware's games, where the story is generally linear, but certain events can be taken from different sides such that you have some choice in the outcome? Or is it like a sandboxed RPG where there are things for you to do, but order is generally left up to the player?

Note that immediately jumping to the second and third answer, which look like they can provide the better gameplay, isn't always the best idea! Some games lend themselves to different styles.

Stories where the player character is forced into a 'reactive' role tend to lend themselves to the first style. If they really only have one course of action due to something (Having to combat the forces of evil attempting to destroy the world by thwarting their attempts at stealing certain objects) then it doesn't make sense to give a sandboxed world to play in. It removes the sense of urgency that should be there.

If the story you decide you'd like comes with situations where there could be a branching of the story based on decisions (Such as the Evil Vs. Good) then it's better to go with the second or third one. If the story is there to provide the player merely with something to do, then the third option tends to be the best.

Which is what I tend to program in when I'm doing anything game related. It's the only reason I purchased the phone I have. xD

And I thought so, but I wasn't sure. I would guess that the number of times this operation is actually used per frame would end up mattering?

I stand corrected!

It was the first thing that came to mind. And I'm not surprised that it in'it that good (More a statement of, I'm not surprised to hear that my knowledge is incorrect, than me saying I purposefully gave bad advice. xD)

You could always save a bit of time (Sacrificing Memory) by using what is called an object pool.

Basically, when you call xitinerary.clear(), you'd add all of them to some sort of collect or array (With a maximum size). Whenever you need an object of that type, you would call ObjectType.getInstance(Type1 val1, Type2 val2, ...) whatever you'd need to set the values. It would either pull an object off your collection or instantiate a new one.

West, West, Western Texas.

And yes, just like Southern New Mexico (Which is almost where I am) it bears very little relation to Hawaii. Except maybe for darker skinned natives. Does that count?

I can't really help here, but... I can ask some leading questions that might help others: What library are you using to draw these things? If it's a specific library what are the classes that you're using? And perhaps posting a code snippet of your update/draw method might help.

How are you planning on handling collisions/interruptions then?

I ask this because the way you describe it, it is likely that "faster" armies will always get to go first and will ted to interrupt/prevent other other units from being able to move where they wish which can lead to frustrating blocking techniques.

Basically, say you issued a task "Move to this position and attack Army X" to one of your Army A and enemy Army Y is given the task "Move to this position and Attack Army A". Army Y moves into a position that prevents Army A from moving close enough to attack Army X this turn, will it attempt to move and then lose its attack phase because it can't reach X, or will your AI be robust enough to make a decision that if it can't attack X then it can attack Y, and perhaps destroy it, so that it won't be blocked again next turn. (And if it's not robust enough, could the other side decide to pull X backwards, stringing you along a bit so that it can constantly put Y in your way and score several unopposed hits?)

It's a sort of swarm movement issue that can be quite the pain in the rear to decide upon, since it can give initiative a much higher bonus/value than you would expect.

It sounds like your movement interface is going to be something like Civilization? Where all of your units move at once (Or at least they all have a set number of movement points, and move sequentially before ending your turn), then all other sides get to move? Or is it more like Final Fantasy Tactics, where each unit (Army, whatever) moves individually (Meaning that one from my side goes, one from yours goes, etc. depending on speed or something else)?

Also, 2D arrays aren't terrible, especially if there are strict, coordinate based rules for movement like in Chess. It's only when you start to add in other rules that it gets to be different/odder.

One thing that I would suggest you think about is a major performance issue: Pathfinding can be expensive when used incorrectly (Expensive in the wasted cycles type of way). A lot is based on how your game's movement system is implemented and how collisions/units affect a unit's ability to move across a map.

Some thoughts (Since I haven't read a lot about your system or the intended game, or how the system will actually work.) If units cause the traversable edges of your map to change (Meaning if a unit 'blocks' travel through it's current position) then there is a high likely hood that you will run into something called Thrashing. Basically, this means that it's likely that each turn a unit takes will result in it needing to find another path across the map (Depending on density of units, etc., etc.)

Further, for Pathfinding, having a 2D array doesn't matter as much. Really, you just have to have a reliable way to fetch the list of adjacent edges. Often, this can, at least partially, be handled by the 2D array system that many games use, however that only works when you can make some assumptions about the game in general. In your case, if the method you've got (The Sectors) works, then you shouldn't be worrying too much about it (While I tend to prefer the 2D array method for a grid, I recognize the fact that it often comes down to a 'When all you have is a hammer' sort of sentiment).

I think that the 'blurriness' is coming from the fact that it seems like you have a 'Shadow' on your font. Typically this causes a 'blurring' behind the letters, but with certain color combinations/sizes, it can make the text look blurry as well.