Gestures Galore

Still at it.  Wow, it’s amazing how much of a difference repeated practice makes.  Just in the pure eye to hand motion of being able to capture things in the right size / position.

Additionally I’m making excellent progress on the thirtydays.club website.  The whole thing is coming together and I hope to have it ready for a late October launch.

On the downside.. the 3TB drive went belly up and a bunch of not essential but useful stuff went byebye..  All the really important things were of course backed up.. but there were a couple huge folders of painting videos that I’m going to miss having around. (the backup stopped working in June when I had to re-install the OS)..

Continue reading Gestures Galore

Milestone 2: Week 4 – Finallly Fixed!

Finally got some time to dev last friday and Made Progress(tm) since the week before was spent rebuilding the pc.

The Maze Generator works!

milestone2MapI’ll need to increase the internal branching, it’s a bit too linear right now but that’s just a variable that needs to be tweaked.

Rooms now get harder and harder, the further in you go.  Next up is some minor UI tweaks and then a second enemy and that’s it for Milestone 2.  Just a couple months behind schedule.. but that’s the way it goes on top of real job, consulting work, children and a house to maintain.

 

 

Dev Update Wk4 – Details details

Getting closer to the end of milestone 1.

Lots of little details checked off, because I’m totally avoiding re-working the main character’s torso twist.

spider-reskinThe biggest work went to the spiders, they got a re-skin to something more shiny, can now do a jump attack which makes them much more of a threat, and make a nice splattery sound when they die.

The UI got a couple minor tweaks and so the respawn counter now works,  Still having some problems with the UI scaling seeming a bit odd but that’s not a critical feature.

Been playing with Shaderforge a bit but not having too much progress in getting a grasp on it.  Other than that, Spent some time trying to get a better look and feel to the overall game.  I added a player light and adjusted the global light to have bit of a different look and feel, but not quite what I’m looking for, but I think it’s a bit of an improvement.

Bsddod-M1-wk4

Milestone 1 remaining features:

  • Make music repeat properly
  • Fix player mouse aiming
  • Jucify player death and respawn.

Only problem is that there’s no more weekends, so it might be a bit of a squeeze.

And here’s this week’s Playable Build:

playbutton

 

BSDDoD! Week 2 – First (barely) playable

Bsddod-M1-wk2
It’s not much, but it’s an interface and it’s informative

Milestone 1, Week 2.

Well here we are, week 2.   Not  a bad week, progress wise, but never as good as I’d have liked..

This week I started cracking my head into the interface that is Blender, and walked away with a simple eggsack model to be used as a spider spawner (pictured below).  Maybe next week I can make it move.

The beginnings of a simple UI are falling into place,  when a room starts, the room title and the challenges in it (spider icon this month) appear for a bit, and there’s a kill counter and the beginnings of a re-spawn counter (shields).  Some odd issues with them not scaling properly sometimes, but eh.  That’s manageable.

bsddod_ss_eggsack
Look an Eggsack! Isn’t it cute.

But, the biggest news is clearly that the entire play cycle is in place,  player life, death, respawn and restart all appear to be marginally functional.

So to that end,  I’ve built if out as a Unity Web Player. So if you’re so inclined you can, try it here:

PLAY IN BROWSER

As usual, feedback/bug reports etc is welcome.

BSDDoD! Week 1

 

 

 

Milestone 1 is underway.

Pretty good progress this week.

The map generation is working, still needs a couple features, like designating spawnable locations and  corner pillars and an occasional wall offset being mangled.

The World Controller object is successfully sealing a room and starting waves of challenges (Milestone 1 will only have one or maybe 2 challenges to spawn)

The actual eggsack spawners are doing their job (no graphics for em yet tho, just white capsules)

The wizard character moves and shoots, but theres some issues with moving into the player’s bolts etc,  so the move and shoot stuff needs some significant rework.

Spiders die when shot! Eggsacks Die when shot!   need to make the impact have more ‘oomph’ and some effects but the functionality is there.

BSDDoD! M1-W1

I was hoping to get a unity wev playable up on the site this week, but there’s nothing really to play..Oh well Hopefully next week there’ll be at least a basic play loop in place.

BSDDoD! Reborn in 2014

BSDD0D 2014

The time to do this game has come.  So it’s gonna be done right.  No more Torque2D, Slick, or other homegrown from the ground, unproven frameworks.  Time to do it in something that’s got support, community, a track record and a workflow.  Aka Unity.  And while we’re at it, let’s make it 3D, physics enabled and extensible by the user to add new rooms to the pool of maze chambers.

And let’s do it as part of this year’s OneGameAMonth Challenge to keep focused.

BSDDoD-SS-dec-7-2013Oh and a list… let’s do a milestone list:

  • Milestone 1 – Single Room – boxes
    • Generate Room From Map File
    • Player Spawns
    • Move Player
    • Player Shoots
    • Monsters spawn in increasing waves
    • Monsters Move toward player
    • Monsters Kill player
    • Shots Kill Monsters
    • Monsters Drop Items (coins for now)
  • Milestone 2 – Maze Generation, Enemy Waves, alt fire
    • Basic level editor
    • Single path maze generated
    • Rooms have a level and determine waves spawned.
  • Milestone 3 – Powerups and Loot
    • Player attributes, health (shields?), Speed, Damage, Rate of Fire, second power manna
  • Milestone 4 – A wizard
  • Milestone 5 – Creatures – ? Alpha ?
  • Milestone 6 – Menu and Starting area
  • Milestone 7 – Decor and Juicify
  • Milestone 8 – More Monsters
  • Milestone 9 – Music and Sound
  • Milestone 10 – Weapons and Karma unlockables framework
  • Milestone 11 – Title Screen, High Score – Names of the dead?
  • Milestone 12 – Beautification of textures and new textures/models for deeper levels?

DragonCrash Alpha Update

Not too much time this week.  Here’s the highlights:

  • parllaxing backgrounds are back and better.
  • the new House and system for adding terrain attachments is fast.  Total time was about 3 hours to add a new item to the game.
  • Improved Energy ui.
  • Particle manager for terrain effect.
  • Upgrade to GL2 base with potential hooks for shader effects.

Flap mr dragon FLAP!

Ok kinda scatterbrained right now so, let’s just get back into the blogging spirit with a short list of accomplishments:

Had to rethink some mechanics.. but the controls feel SO much better now.

The actual performance of the dive and flap buttons are undergoing constant tweaking, but the sense of control is coming along superbly.

Screen scaling is working.. but the size isn’t right on smaller screens.  I need to re-write the system to always maintain a specific horizontal distance and let it just create blue sky on top of the world for the extra space.   BUT IT WORKS..

The game is working on Android 2.3 (HTC MyTouch)  all the way to the Nexus7 and Asus 10″, smooth as butter. 🙂

I’ve been using Symphonical as my SCRUM list and I’m in love!  It’s just super easy to use.

Collisions are in (if a little buggy) ,  Basic Box for the dragon and per terrain tile polygons.

The dragon is now a fully animated Spine character  (16 different parts all animated) and is just a wonderful workflow.. Export from photoshop and it’s instantly in Spine, then a quick export directly into the JSON objects with an atlas and then a refresh. and the changes are live in-game..

Dragoncrash-8-17

 

Next up:

A little more work on the dragon animation

Then time to start adding in some terrain destructables (also Spine actors)

Then some UI work.

 

LOS Targeting

Minor but important progress. Holidays (and Skyrim) were not as conductive as hoped to progress.

Map entities (monsters and PCs) now scan for the nearest visible targets within their field of view and as within LOS on the level map.

Monsters now have a new behavior available on spawn which is to start stalking a Random PC.

The goal is to have several behaviors available for monsters to utilize what cna be mix and matched during levels.. (patrolling.. random walking, waiting,) and then have events and triggers switch them out asin-game events etc..

Next up.. either monster spawners or starting the prep work for combat mechanisms.

 

The Fall Season!

Whoa.. after what feels like an absolutely morale crushing infernal heat wave that has more or less sapped all willpower for the last several months… it’s time to get the show back on the road.

Here’s a peak at what’s been worked on.  More details as soon as I get more gameplay things put in.  And after a break to Javaland  it’s back to good ol TGB.  The upside is that things make so much more sense now.   Many more thoughts on the matter later on.

Bits N Bobbins

Short post on progress things.  Things have just been lots of grunt work and non pretty things.

Will have things to show real soon.

Honest.

  • basic player object ..er.. exists and rotates properly.. mostly.  need to knock out some better test sprites and stuff to be able to make things actually ‘work’ together, but the fundamental concept of 8 direction independently moving head, torso, arms, lowerbody seems to work and will look pretty cool.
  • monster entities can be spawned and basically kept track of.. no AI or whatnot but still it’s a start.
  • Implemented basic box2d physics for player and monsters. this will have all sorts of fun payoff later I hope. Force waves, shapnel etc 🙂
  • Got the macro tiles wired for a* pathfinding.
  • Got the World generating a Maze and then replacing it with matching macrotiles that randomly match the exits of the cell.
  • started on map rendering
  • camera instance screen objects so I can have a smooth moving controllable camera that chases the player.
See.. lots of neat stuff… however nothing that you can actually look at other than a bunch of  diagnostic log output.
Performance wise it seems to be running at ~240 fps on the low end test machine and ~somewhere over 3,000 fps on the new machine.
So I might need to add in a ‘laptop’ mode which disables the whiz bang pretty stuff I hope to get put in.
and damnit .. http://www.garagegames.com/products/torque-3d the introductory price will be ending soon.
So I’ve got to grab that soon.

Building Better Tools

So, basic progress is in swing.  There’s a bunch of stuff I can port over from the GarageGames Torque Game Builder version that I was working on, however, there are a bunch of things that I didn’t need then or just do not have access to in Java or just don’t integrate with Slick very well.  So with that in mind.. I’ve been digging  into Pre-Pre-Production.

To that end I’ve stated building a toolbox. Figuratively, of course.  Here’s a few of the silly things  that are a pain to write but very useful to have.

  • AssetLoader – based on the slick tutorial this little thing lets me have a loading bar on a title screen while the game loads every asset it needs.
  • OptionsController – manage loading and saving user settings and profiles for resolution, sound, and player name.
  • InternetFile / InternetString – for pulling a string (current version) or file (updated assets)  This makes keeping the user informed of latest news/ updated versions a snap.  Since Minecraft came out with an auto updater, it’s been glaringly obvious that at minimum having a latest version check is a MUST Have feature.
  • Movement Library – a pile of functions to take two points, and interpolate between them,given a method speed and time elapsed and whatever else that comes up.  I expect this to grow for some time.
  • ImageCounter widget – display a number with a series of images. Like hearts in zelda. Supports horizontal and vertical orientation, whole and partial increments etc.
  • Basic Image Button – yup it’s a simple little button made out of a bunch of images, it’s self contained and easy to use and change.
  • State Based Button – also called a modal button.  Essentially displays several options on a button bar and you can select one.
  • Text Block – an angelfont based text block widget , hand it a block of text, an AngelFont, and give it a max size.  It auto animates the display, pagination etc.
  • Text Entry – an angelfont text entry widget.  easy and simple..
and as I find things that would be handy in future projects I’m adding them to it.
So it turns out that making little widgets is actually really kind of fun.  Much like building the IrisEdit level builder tool that I’m using to build the levels.
And with those tools in hand, I’ve created the game Launcher / Version Checker,  Here’s what it looks like without the Launch Game button (it goes in the middle)

 

Tech Choices: Walls

Assuming you’ve decided to build a 2d engine for a non side-scroller you quickly come face to face with one of the biggest decisions you’ve had to make so far.  How are you going to represent the game world? Basically there’s two choices each with their own benefits and issues.  There’s the ‘Walls are a block’ approach where everything is a block and the ‘Walls are an attribute’ approach where walls are things that are part of a tile and appear on the edge of a tile.  Here’s a little Pro/Con info that I jotted down while deciding on which way to go for BSDDoD.

Walls are a block.

Example: minecraft, zelda This is probably the most obvious approach to building a 2d world.  Everything about the world construction is handled in a simple array of blocks letting you quickly build a map.

Basic implementation:

It’s essentially a lardge 2d array that contains the structure of the world.  With each location in the world represented by a number.  For pathfinding you can easily implement floodfill tests and even weighting the passability of tiles is pretty trivial.

Upside:

They’re easy to implement and fairly lightweight, make a whole bunch of visibility / raycasting real easy and fast.

Downside:

Aesthetically they’re not as nice/real looking as what can be achieved with thin walls.  Destructible walls are more unrealistic and the wall type is determined by the block that is the wall.  So if you want blocks with different wall textures you have to create and track many more entities. Windows are pretty much out of the question and doors tend to look a bit odd.

Walls are an attribute

Example:  X-com, project Zomboid, old Gold box D&D games, the Sims

Basic implementation:

Every game tile has 4 flags associated with it used for indicating if there’s a wall. This means that there’s a bit of extra overhead but it comes at some interesting benefits.

Upside:

Aesthetically having walls look like walls is a big bonus.  Also the ability to do things like have windows, half height walls, one way doors and portals is nice too.  Also the ability to have different textures for a wall regardless of whats in the neighboring tile is nice (but there’s workarounds for tile based maps for this as well).

Downside:

Complexity.  Pathfinding, line of sight and collision detection all become significantly more involved, not necessarily slower,  just more complicated.

What did I choose?

Well since I’ve got a bunch of the art assets already created for a straight on view, I eventually settled on the Block based walls with the Straight on view (right side of the image above).  Really that was the deciding factor.  The straight on Blocks as an Attribute would just wind up looking odd and I have no need for windows or doors since it’s essentially an arena based shooter.

For the next project I’m leaning toward an isometric Block based map, however with blocks being smaller than the characters, so that will give thinner walls and hopefully a more enjoyable dungeon building experience… but that’s still way off in the distance, percolating on the back burner.

Elements

Whoo.. what a week.. not very much dev time, unfortunately.

I’m beat so I’m going to keep it to a short what got done list.. followed by a screenshot..

  • Bolt splitters are in and work.. (except for the rotation is a bit wonky)
  • the Level editor and Level group editors are almost done
  • The core applet is almost ready to parse all data from external sources.
  • Tweaks to some particles.
  • all the  Elemental nodes now are renderable in-game and have their proper graphics.

Here’s a screenshot of where things are.

And here’s the list of priorites for the week:

  • All the ajaxy and facebook <–> applet communications need to get wrapped up asap.
  • Player object for storing scores
  • back to level select button
  • more particle effects
  • SOUND!
  • LEVELS !!!!
  • and so much more!!! Yikes!

At this point I’m getting pretty nervous weather or not I’ll even make it to complete by the contest end.  Its looking like Some things are going to have to wait to be finished afterward..  Yeesh.. well.  hopefully the baby will cooperate and I’ll be able to get stuff done in the evenings this next week or two.. cross yer fingers.