approximatelymostly

[approximatelymostly]

Minecraft

Sorry for dropping off the radar, but fiddled with a whole bunch of stuff. Need to get back to working on that game, but oh piece of candy.

Got into playing minecraft again, saw some cool mod stuff- particularly Hexxit. Then I remembered a few years back I start getting into modding minecraft, but didn't know java, and there was no forge ... and thought, well this is cool, I bet in a few years it'll be robust enough that maybe you could really do something without making it your life.

A few years later.

I'm making mods using Forge Mod Loader, and working in their newer 1.7.2 stuff. But it's in Beta, and MCP is in Beta, and there are huge internal changes (good ones) from 1.6 to 1.7, but it does mean that documentation is scarce, and tutorials either are mostly for 1.6, or generally assumed you made stuff in 1.6 and are just trying to convert it to 1.7But, making progress! Behoooold. A remains block. You break it and it drops bones. Yes, yes, small potatoes, but figured how to get this all installed and working when everything shifts from Python installers to Gradle, and pieces together what to do from a patchwork of invalid tutorials, bare bones java docs, and not just a little intuition, I feel pretty good.

I got some plans man. I got some plans. But that's it for now.

[approximatelymostly]

Map Editor!

It continues.

Not done with it, but the major things are in place. Can load in tile sets from xml files (made with the ugly ugly TileSetter program I made). Doesn't explode if there are problems loading up said xml file.

The right pane is the big achievement. I wanted my editor panel to be able to zoom in/out, preview the parallax (that's why those random blocks behind don't line up, because they're scrolling at a different rate). And this coolness actually interfaces with the standard Swing Libraries! That's in JScrollPane! Those buttons, just JButtons! The images for the tileset buttons actually use an extended ImageIcon class I made that actually paints from the single Tile sheet, stretching to fit the button!

This has been a good experience. I've learned quite a bit on this whole project, added some cool tools to my programming tool belt. But trying to integrate that knowledge, to interface with the powerful Swing libraries, it's taught me to use them well. What I'm making is more powerful, more flexible, less coupled, and also in significantly less lines of code.

That TileImageIcon class is like, 6 lines of code. That's bad ass.

Long code doesn't impress me. Short code does. Any sob can make something happen with a mountain of tools and an eon of time. Make it work with 2 rubber bands and 5 minutes, then I'm impressed.

The painful part is realizing how crude or improper some aspects of my Game Engine really are. But not too painful. I've been aware that *something* was wrong with the way I was handling some things. I've just confirmed it.

Weird what gave me clarity... I saw a better way to handle 'collision' event handling from working with actual event handlers and listeners. I finally wrapped my head around the Model/controller/View relationship because of dealing with the same tile information in different areas of multiple programs (Defining in the tileset, being in the map palette, or being in the editor's world editor window). Factories from using layouts and borders ... hell, try to manipulate the same data across multiple programs where you're doing different stuff with it and you'll get a much better idea of what should be in the class versus outside inside some type of streamer/reader/loader.

[approximatelymostly]

The Tablet: She is mines

Just got myself an Asus Transformer Pad. I got it initially to reduce the space of using a collection of books/laptop during role playing games.

Yup.

Pretty neat. I've never had a smart phone, so touch interface is making me feel a bit like a 5 year old with mittens on bumbling accidentally hitting things and not really knowing where anything is. Still pretty sweet.

Looking forward to playing around with making some apps for it: but for now, the task at hand.

The map editor is coming along. I swear, the best way to learn 'best practices' is to just fling yourself into a project:

and then try to make it 'do a little more'

Pretty easy to see if you're duplicating effort, or making this or that class do too much, or have to keep track of duplicated things and synch them: because if you do it

On we go!

[approximatelymostly]

Strapless Acessories

You know what trope I'm tired of seeing in games?

'sheathed' weapons just stuck onto people's backs.

Swords, no scabbard, held in place by spinal magnetism. daggers locked by poltergeists. Staffs ... which shouldn't be 'sheathable' anyway just snap in place.

Looks even more ridiculous if the character doesn't wear a shirt.

New rule: You can't put in graphical detail to the level of nose hairs and have weapons floating.

[approximatelymostly]

So basically, your entity has one point whihc will determine it's position, and this is the point that is moved. You also have a collision box around it and this determines its collision field? I think I'm still confused. For example in your game you have tiles and each tile has a corresponding "collision field" and if your entity collides with it then perform an action, but in each of my collisions there are 8 outcomes, collision on left hand side, right hand, top, bottom and the corners...

Okay. So let's strip out slopes, inertia gravity, etc, and work with just a bounding box, a central point, and some squarish tiles, and only worry about moving to the right.Now that is a sweet bit of msPaint if I do say so myself.

So here's a tiny tile map, only 5x4 tiles.Each tile has a width and height of 1. Meaning anything where x >= 0 and y >= 0 is in tile [0, 0].

The player's current position is a point, noted by where the dark green diamond roughly in his center.

He has a bounding box to define how 'large' he is for world physics. To make it simple, let's say he's 1.5 blocks tall, and 1 block wide. The bounds are relative to the entity's true 'position:" so let's say:

(left = -.5)  (right = .5), (top = .75), and (bottom = -.75).

His current position is: (1, 1.75). That way he's effectively on the ground, even though we're not fiddling with gravity at the moment.

Now for actual movement.

We've got a velocity of +3 blocks. Normally, depending on update rate, we wouldn't be moving all that at once, but let's do it in 1 fps. So delta X is +3.

since ( dx > 0) we know we're moving right.

First I find my box in real space. My right edge should be my X position, plus my right Bound: 1 + .5 = 1.5. Likewise, left bound is x + leftBound: 1 + (-.5) = .5. Top and bottom follow suit so I get:

Move-box:(left = .5)  (right = 1.5), (top = 2.5), and (bottom = 1).

Now to figure out where I'm trying to get to: destination. Since we're moving right, his is the move-box's right edge + delta 1.5 + 3 = 4.5.

We now effectively have a second box: a box of the space we're moving through. Left = (movebox.right), right = (destination), top = (movebox.top), and bottom (movebox.bottom). Now it's just a matter to iterate through these tiles and see if there are any issues when move right through them.

Now, looking at that new box, it's pretty easy to tell which tiles we have to try and move through to get to our destination.

I don't just 'move through' the tiles. I actually ask the tiles a question: "Assuming I have a bounding box this size, do I hit anything if I try to move to here." Tiles are dumb. They just link to a rule (solid, sloped, empty, etc) They don't even keep track of where they are. in a real world sense.

public CollisionObject testRight(left, top, right, bottom, to, tileX, tileY)

left, top, right, bottom are the pauper's box, to is the destination, tileX and tileY are the tile's coordinates.

This test returns a collisionObject. This sucker holds all the useful information like "was there a hit" if so "what type" and x and y coordinates of said hit, etc.

Iterate through each of the colums of tiles, going from left to right (since if we get stopped early, there's no point testing all the way to the end).

If the returned object says, no hit, all's good. I don't even store it. If it is a hit, I put it into a list, ordered by which ever's hit at is closest (in this case, the one with the smallest X).

So, what's going to happen here?

well, first I test against 1,1 and 1,2. Any issues moving through you to 4.5? my feet are at y=1 and y =2.5. Both tests say no collisions. On to the next column:

2,1 and 2,2. Clear here too.

3,1 and 3,1: ah, here something new is happening. We have some walls.

3,1 is fully solid. It knows that if you're trying to move through it, you are going to hit. But what is the math behind it.

It's fully solid, so effectively it has a bounding box of 0,0,1,1 locally. It knows it's tileX and tileY (because it was passed in the test) of 3 and 1. So it's real world bounds is (x1 =3, y1 = 1, x2 = 4,  y2 = 2). It's left edge is 3, and the destination is 4.5! Hit! The returned collisionObject is set to true, hit type is 'wall', hitX is 3.

Now we're going to test against tile 3,2 as well, and it's going to count a hit as well, but at hitX = 3.5. When collecting up the collisions, 3,1 is closer, so while I would have hit it, the lower tile blocks me from ever having struck it.

Now: resolve.

I have a collision at X=3. That means I can only move up to that. My resulting position will be hitX - rightBound. x = 2.5. That's how far I get to move.

 I also have all the information about which tile I hit, how fast I was going, where exactly I hit on it, etc) to do whatever else I want to do. I could play a sound effect, set my velocity to 0, spray some particles from the hit location. Sky's the limit on how responsive you want that collision to be.

Also, and just as importantly, you don't throw any false hits from your potential hit in 3,2, or any of the potential hits behind it.

The tiles themselves don't do an action reflexively when you 'hit' them. You figure out what 'will happen' then determine what 'will happen first', then respond accordingly.

And to bounce back to talking about your '8 possible results' there's really just 2. You either hit moving this direction, or you don't. It doesn't matter if you stub your toe not jumping high enough over a tile, or catch your head going through too small of a hole, or smack bodily into a wall. If you catch on something moving horizontally, your horizontal movement is cut short.

[approximatelymostly]

Hi I was just wondering how you did the collision detection with your character and ground blocks, mine seem to work okay but I think it has the potential to be very glitchy

Do you mean ground blocks as in map collision in general, or ground as in the ground under his feet? I'll assume the first but if you had questions about something else feel free to specify.

Briefly: entity has both a position (point) and a bounding box (left, top, right, bottom bounds relative to 'point'). Calculate the real world bounding box by combing the the 2. Determine relative movement aka change in position aka (delta) for both x and y.

Movement is broken up in a cardinal directions: left, right, up and down. Left vs right are resolved first, then up and down.

All directions are resolved basically the same way: here's right:

Determine destination: (where I'm trying to move to). this is edge facing the goal (right edge) + delta.

Iterate through the tiles the box would move through. This would be 2 for loops, for each column ( tiles overlapping right edge to destination) test the tile at that row ( tiles overlapping top to bottom).

Get the tile from the map. Test bounding box and goal using the tile's 'test right' method. Tile will return a collisionObject or null. Null says all clear, collisionObject marks the type of hit, tile's coordinates, hit's coordinates, etc.

Store any collisions in a list, ordering the most significant (closest) first.

After tests, if there are any collisions, move up as far as you can: newX = closest.hitX - rightBound. React to those collisions in any way you see fit (stopping, throwing particles, ricocheting, etc). Else, it's clear, newX = destination.X - rightBound.

That's the core concept. It takes care of a lot of issues like not accidentally registering colliding with one type of tile (say spikes) when another closer collision (say a slightly raised table) keeps you from hitting it. He said, with not just a little venom directed at Rogue Legacy.

Now, this is like the 5th or so generation I've made of this collision system over a couple years. You speak of concerns that yours may be potentially glitchy. The hell with you spell checker glitchy is a word and don't try to tell me otherwise. Added to dictionary. There. Where was I? Oh yes, glitchy. What specifically are you worried about?

[approximatelymostly]

Finally, got my Tile Set creator done.

It's definitely not the best interface, but it does function. The internal code looks a bit like puke, but it functions and it saves/loads to an XML file. So, even though this program needs to be just done from scratch again correctly, now that I know how to do all this cool GUI stuff- the XML will stay the same.

So I can clean that up, whenever. The important part is it's something, and it works.

The actual map maker will be a lot simpler.

I really need to button down what this game's going to do. I could make something super generic... but I just can't do that. I think I'll make an actual game.

[approximatelymostly]

So...

I now know an awful lot about layouts, listeners, actions, and drag and drop.

And what, it only took a good week of vulgarity punctuated research.

For some reason FRAPs really doesn't want you to see the nice looking drag and drop feature I have where I drag the images in the sprite sheet(on the left) over to the graphics box on the Tile definition on the right.

Making the drag and drop took more time than I expected to figure out because Java's DnD is extremely powerful. The drag and drop can interface outside of the JVM, to other non-java applications... or from them! So there's a dense bit of code to figure out what does what.

So even though I really was only planning to drag from one type of component to another specific type, you still have to deal with: what happens when a different drag operation goes to drop there, or you try to drop at a different type of drop target. Or cancel. And then there's infrastructure for for different DnD types (move, copy, insert, etc) and all the handshaking back and forth. There's a lot more going on than you would initially believe. Here's a list of the stuff used

DragSourceListener

DragGesureRecognizer (how the application knows you're starting a drag)

DragSource (connects the component to the listener).

DropSourceListener

DropSource ( connects a component to the drop listener)

Transferable ( the DnD's package )

Because the source or destination of a DnD may be outside of JVM, the source/destination can't talk directly. This has to be done through a Transferable (it's an interface) which, if you're intending to going out of the JVM must be able to serialize.

The bridge-like nature of the Drag Source and Drop Source means that you can hook up DnD Behaviors to components that do not have inherent to the component.

So very powerful, very flexible, and consequently very long winded and complex.

[approximatelymostly]

The Ballmer Peak

Unsuccessful Ballmer Peak experiment. Have become sleepy. Test data possibly corrupted by pre-existing illness that is dampening mental processes.

Only logical course of action is to replicate experiment.

Science.

[approximatelymostly]

Hubris thinking I could get it done that fast.

Still not done. But I'm muddling my way through. I had had little experience working with 'GUI' library stuff like events and validation and such, or dated experience where I was flinging code like a monkey.

But, dedication and focus can in fact make one progress at a faster rate. Towards mastery or an aneurism ... debatable.

I admit to getting a little ahead of myself on some of the 'neat' bits instead of getting it just functioning first... but I'll chalk it up to ultimately beneficial to the learning experience. Besides, what the point of a GUI if it doesn't give you ready feedback to shield you from overlooking stuff, or strive to let one develop at the speed one conceptualizes.

So I can enable/disable indicators for the tile cells numbers and their usage. Everything flows and wraps. Think I'll have the 'tile definitions' have those two panels, one for graphics, one for collision. They're to be sort of a preview.Double clicking will pop up a menu for editing.

Blank and static images are obvious. An animated graphic would reasonably do the animation.

The collision preview will be like, a solid Brown square for a solid. A green line for a jump through platform. Brown quadrilateral reflecting the slope.

Maybe the color of the collision will reflect material rules... like blue for ice. Red for spikes. I dunno.

[approximatelymostly]

I am aware this is psychosomatic but this wounds me to look at.

Things I have to say you to do.

1) Determine the relative position of the mouse to the player's position (so the player doesn't always have to be in the middle of the screen... of a fixed size).

so ( x = ( world.x + mouse.x) - player.x )

2) determine the angle. Normalize angle and  take arc tangent, convert to degrees to make it simple on yourself.

3) take angle. Divide by 30. Round up. ( or add 15 and then divide by 30). If result is 9, set it to 0 ( this is the 345-360 angle).

4) Probably should use an Enumerated for the direction. WEST, NWEST, NORTH, etc. Or constant static int values. There is an order to them.

Can you tell I learned to code off a .PDF I downloaded from the internet?

[approximatelymostly]

Hell yeah.

That looks like SVG.

[approximatelymostly]

Need a tool to make my thingy.

Edit: So Tumblr deleted all the content from the post's body. Well ain't that swell.

Ugh. Restated, but briefly: Narrowed eyes when I realized that I needed to go ahead and make a map editor so I could implement loading worlds to highlight the 'intro' / in game switching. Narrowed again when I realized I needed a Tile Set Editor to define the Tile Sets to use in the map editor.

Down rabbit hole.

Tile Set editor should in fact be brief to make. Can make new/save/load tile set. New tile sets take a tile sheet (image). Tile definitions (index number, graphics, collision) are added as entries. Simple drop down choice for the other two options.

Two panes: tile sheet broken down into blocks on one side, Tile definition on the other. Tile sheet will put an X over a block image if that cell has been  used at least once in a graphic. Tile definitions will stay in order by index value, warn when you save if there are gaps. Friendly stuff.

Whole thing saves to say XML format. Wise, portable choice. Easy to parse.

[approximatelymostly]

Physics and Collision

Reworking my physics and collision code. Methodology is sound, but the physics component has a pretty big 'nightmare section' that is very scary to look at.

My rule of thumb is if I go back and look at something a week later and it looks like a mathematician got drunk and punched a keyboard, I don't have it laid out very clearly.

By its nature, physics is mathy, and a touch head ache inducing. Therefore, I should try to be less 'clever' and more clear.

Plus I want to be able to be able to tell which tiles I land on, rather than just stopping.

[approximatelymostly]

Bugs, Interfaces, and tweaks.

Spent the last few days fixes things, cleaning up and improving bits.

The bugs were mostly logical derps. (noticed I had done goofed with the volume control ... volume updated before it actually changed the values).

The Menus are way better now. The Menu doesn't have any graphic fluff built into. I just overlay the menu over the world.

That intro screen with the particles floating in it? Well, now it's just a game world with a particle sprayer entity. Small enough matter to have a demo world running in the background.

So... let's have an intimate moment. I shall reveal to you a secret. (for full experience envision a well furnished study lit by a fireplace. I really didn't see the appeal of Interfaces. Well now I do. There are a decent number of reasons to use them, but I'm going to give you one.

Tile Collision: I have tiles more or less broken into two major aspects: Tile Graphics rules, and Tile Collision. Let's say I have 3 basic tile collision rules, a solid one, an empty one, and just for luls, a Tile that's a circle. Using sub-classes, which is the base?

One might assume the empty or fully solid one is a good enough base, being the 'normal' like ones... but what does a circle tile have at all with common with either? Why extend if absolutely everything will be overridden, and none of the member variables would be used?

Better to use an interface. That way 'circle collision' can implement, only have the stuff it needs, and doesn't have to build off something else in a weird way. And I can still extend a class that used the interface if it makes sense, say like a 1 way platform could extend from a fully solid tile.

[approximatelymostly]

More flexible Menu, persistent config file, and on the fly resolution changing:

Put in the new menus. Ultimately did use a stack. Basic structure is like this:

MenuController   Contains instances of SubMenus, and a stack of type (SubMenu).

SubMenu:   Has a large variety of subclasses (Options Menu, Audio Menu, etc). Each subMenu has a list of choices. When activated, these choices activate an action.

Action:   The action could be to change the resolution size, or go into another submenu (push onto the stack) or back out ( pop the stack).

Had to tweak some stuff, but got it to work. It did screw around a bit much working on full screen... bleh.

Settings also get saved to a config file. If none exists, it loads default values.

As you can see, I can also go into the Menu IN GAME. It pauses and everything- though it does have the flexibility to not pause (like in menu for multiplayer). I have no plans for multi player... but it just seemed like the right thing to do.

Also have in game volume control. Woo.

[approximatelymostly]

Stuff

FYI I'm not dead, nor abandoned project. Got a new job and been at work the entire week /w hr long commute, and didn't feel like what I'd actually added in the1-2 hrs I had to work each night was worthy of an update.

In process of revamping the Menus. GameMenus are now overlaid atop the 'game world'. The starting menu with the logo and particle generators are actually just a tiny level.

Also worked out and tested having a config file store settings like resolution and volume. Plus having it load cfg from a default.cfg if no current one exists.

Should have this all in sometime tomorrow. Right now, probably best thing is sleep.