Tag: development process

Posted on by

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

Posted on by

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.

 

 

Posted on by

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

 

Posted on by — 2 Comments

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.

Posted on by

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.

Posted on by — 1 Comment

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?
Posted on by

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.
Posted on by — 1 Comment

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.

 

Posted on by

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.

 

Posted on by

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.

Posted on by

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.
Posted on by

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)

 

Posted on by

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.

Posted on by

Screenshot Saturday

Managed to get the web editor exporting tileframe data nicely, and with a few modifications was able to get TGB to import the new map data and render the maps in the existing tilemaps.  🙂 yaay.

New tilemaps in Game Engine.

Now if I can only find out what makes it crash when you touch the mouse……

*scratch head*.. well at least it’s progress..

Oh and we have new and very awesome epic in-game music now from www.indiegraphics.net

So it’s  been a good week overall.

[Edit::]  Found the Crash.  it was to do with the checks for various player positions on the tilemap for shooting.  Which is totally obsolete, due to the new tilemap, so it was crashing.

Posted on by

Milestones

Pardon me while I ramble..   if you get bored you can pop over to the map editor and play around and let me know how it performs for you (IE users, don’t bother), and saving is disabled.   This is essentially me trying to externalize the process of development that seems to work for me.

It’s easy to get lost, sidetracked, disillusioned, or just plain worn out when embarking on a massive self guided project.

Even when you feel like you can just keep working on a project forever because you have so many ideas you risk it all if you don’t know what the final product is going to be.  For example, the megahit Minecraft was in development for over a year and sold close to a million copies before the guys at Mojang finally sat down and decided what they were actually making.   I’d wager if it hadn’t been for it going viral, it would have wound up just another of the tons of  half finished abandoned indie projects that litter the web because they didn’t know what they were making.

On the other extreme, there are just as many abandoned overdesigned, super perfectly detailed design documents for games that will never be created, scattered all over the internet as well.  Potential games that were literally designed to death, go dig around on sourceforge and you’ll find hundreds of em in ‘planning’.

So what’s an indie developer to do?

Frankly, I’m not sure.  I know what seems to work for me  (so far), and that’s self imposed milestones.

Now let me clarify a bit.  I’m not talking about your usual development project, spec sheet loaded, time and budget allocated, cut your funding if  you don’t make it milestone.  That’s for a different type of development, not a creative endeavor.  It has it’s place, but not here.

What kind of milestones?

I’m talking more of a softer, moldable, flexible type of milestone.  You take one, you work on it, do whatever you want withing the parameters specified, and when you’re done you have real tangible progress.  Then you pick another one that mirrors what you’re in the mood for.    That’s key for me.   When I get to the point in a project where I don’t have a choice in what I need to do next and don’t want to do it , I get distracted. (see the Mutant Sheep Eat the Earth!, game… it’s pretty much stalled because I’ve worked myself into a corner where there’s nothing exiting left and I’ve gotten totally de-motivated  (psst it’s not dead.. just hibernating in my subconscious.. I have plans percolating.))

For example, by the time you’re reading this, I’ll have wrapped up my latest milestone for BSDDoD! which was ‘Build a web based editor to let me edit game elements and export them into a flatfile for use in the game in 20 days.’

Flexible task definition

That’s it for the definition of it.  I didn’t have any other notes or plans other than I knew the map size has to be 20×20 due to memory constraints of the final 10×10 grid of 20×20 maps that the game will happen in.  I could go as feature rich and as crazy as I wanted to, but I always kept a mental track of trying to hit the date or at least get as close as I possibly can.   I didn’t even know what I was going to write it in (jquery, cakephp and custom javascript if you’re interested, it almost wound up a desktop based Python application or java applet)  I didn’t pre-plan features other than the map size.  This let me actually create and explore while working on it.

I really try no to make too many choices that will force me to wind up in a position of having to determine things for future milestones.  Now of course it’s inevitable that there will be some overlap, but striving to make each milestone into it’s own creative endeavor keeps me interested in the long run.

Know how long you can stay focuse… ooh look shiny!

I know how long my attention span is, and how long I can proceed with certain types of tasks before getting bored and I make the milestones accordingly, and I try to have a couple of milestone choices available to choose from, so if I’m in the mood for more coding I can do that, or if I need a break and switch to art asset creation, planning, music etc those options are available for me.

So my next choices for BSDDoD! milestones are:

  • Coding, Import map data and generate levels in the Torque Game Builder engine that alpha 4 was working in, 7 days
  • Art, Create Door, wizard (basic wand and arm) and basic creeper art assets, 14 days.
  • Design, come up with different enemies and concept art and various powerups available in the witch’s shop, 14 days.

Time is relative

Now you’ll notice that my ‘days’ have very very very little relevance to normal time, this comes with having a 1 year old, and a fulltime job, an art site and business to help launch  and some awesome swiftthought.com development work that all take priority.

That’s ok.  I’m fully aware that this 6 month project is already in it’s second year and I’m ok with that.

I can see progress being made.

I can see what  I need to do, to get there.

I still have to make up how to do it.

I can see the milestones all the way to the end.

I have no idea of  what all the things I will have created by the time I get there will look like.

That’s damn exciting.