Time Tank – the distraction.

I was plugging along on this Grocery Store game just fine, when all of the sudden, a GMC Jam jumped out in front of me and made me pay it more attention.  Now that the Jam is over, I still have this thing called “Time Tank” distracting me and demanding my attention.  I can’t seem to shake it

Wow, I never noticed before now. “Time Tank” is such a fitting name.  It truly is tanking all of my time.

But, fortunately, it’s not all for naught.  I’ve learned a few things while making Time Tank that will actually help me out with Smalltown Grocery.  Turns out, I CAN use a larger object with a smaller grid size.  I just have to use an mp_grid and use ‘precise’ checking.  Actually, no.  Now that I think about it, I don’t think that will quite work.  Anyway, that’s subject matter for a different post.  Let’s talk about Time Tank!

Here’s the quick and dirty logo I made for it (complete with the wrong tank sprite – it’s using an enemy tank instead of the player’s “time tank” –smh lol–)… and an early mock-up we made of the game…


And our tagline:

Travel back in time to defeat the fascist onslaught of WWII in order to shape a better future. Beware – your success may trap you in an unforgiving time loop of unintended consequences.​

Basically, it plays the same level over and over again, but with tougher enemies each time.  The premise was that you were sent back in time to defeat Hitler’s Nazi army before the holocaust could happen (don’t worry about all the time travel paradoxes and timeline changes…  Trust me, it doesn’t apply.  lol)  However, by defeating the Nazi army, it makes way for a different army to take it’s place in history — Hitler’s SS army!  Remember, this is World War II, so after that, it goes:  Japanese army, Russian army, then one we made up — the Plumpf army.  If you make it through all 5 levels to the end defeating the Plumpf army (the 5th level), you save the world and win the game.

Deep, eh?  /sarcasm, in case you missed it.

So, yeah — the story could use some work, but the game was pretty fun to work on.  Before I get too deep into this, I need to mention that I recruited Rusty from the GMC as my Jam partner to be the main “Art Guy”.  He and I had decided on the game’s direction and design before the jam started.  I suggested something in the vein of “Ikari Warriors” and he suggested “Tanks”.  Rusty threw out a quick story line (basically what I already wrote above — we didn’t even try to improve it – lol), and we both got to work.  Rusty got busy spriting and I got busy coding.

What we ended up with for the Jam was a half-baked, vertical-scrolling, plain shooter with failed retro limitations (weapon aiming locked to 45 degree angles), and a very lackluster AI.  Here’s a little gif…

Rusty didn’t like the fact that it was unfinished, but that it seemed close to being there.  He wanted to keep working on it and “mop it up”, as he put it.  I agreed that we could give it another week and try to wrap it up.  That was about a week ago.  I’m still working on it because… well…  it’s got my goat and I want it back.

Here’s the fixed up Jam Version of the game if you’re interested:  Time Tank — Jam Version

I say “fixed up” because it took two extra hours to get it to this ‘not buggy’ state.  The ‘on-time’ submitted version didn’t advance levels correctly, plus it had a few other non-game-breaking bugs/glitches/annoyances that I can’t remember right off hand, now (It was a mad rush to get as much done as fast as possible).  Anyway, here are some quotes from the “rave” reviews the game received:

“Game was quite fun at first, but tedious after a bit. Your levels were so long I started just running through them…”

“Ultimately I ended up just rushing past most of the enemies to reach the next level.”

“At some point I just started driving past everything and using leftmouse for flags I couldn’t drive over and ignore all tanks.”

“This was another mouse aim top down. With the game in a window, I was constantly clicking the game out of focus.”

“…overall the game dragged on a bit. shorter levels and skipping the second level would improve the experience…”

I think I see a recurring theme.  Uhh… perhaps the levels need to be longer?  /more sarcasm, in case you missed it again.

Now that that’s out of the way, here’s what’s happening with it now.  I’ve given the enemy tanks a grid with which to pathfind, along with either an attack state or a defensive state upon creation.  Defensive tanks will try to maintain a distance ahead of the player while continuing to shoot.  I’ve also incorporated a checkpoint system that breaks the levels down into 4 sections.  When you come upon a checkpoint, your ability to progress is halted until all enemies on screen are cleared.  Now, the player cannot just rush past the enemy to the end of the level.  Rusty wasn’t entirely sold on this idea, as he wanted to use a constant auto-scroll to force the player to the end of the level, but I nixed his idea (we tried it out) because it felt like it took away too much control from the player.  But he had some nice ideas to implement to the checkpoints, so I think he’s fine with it now.

I threw out the 45 degree angle aiming and shooting (with Rusty’s blessing) and implemented accurate point-to-point aiming and shooting and it was amazing (to me, at least) how much it improved the gameplay!  Rusty had already given enemy infantry this ability (along with some better AI for the infantry), and so I gave accurate shooting to the enemy tanks as well.  Rusty’s Infantry AI was pretty good, but since I had a grid, I wanted to give the infantry pathfinding too.  I used Rusty’s AI conditions, but implemented them to the grid pathfinding.

Also since the jam, I’ve added some more particle effects.  I beefed up the blood spatter so you can actually see it now, and added damage hits and tank explosions.  I’m working on smoke right now to signify a tank being on the brink of destruction.

I still want to add some more effects; stuff with shooting and bullets, screen shake from explosions, visual feedback with some of the scoring, with picking up power-ups, and with checkpoints.  I want to make the power-ups more noticeable in the game because right now they are easily confused with their icon counterparts of the GUI.  I also want to pretty-up the GUI and maybe replace the health point’s number text into a bar/meter instead (or also).  And I can’t stand little hearts signifying lives (though they’re kinda funny in a tank game), so those will probably get replaced as well.

So what’s left?  AI to code for two more infantry types (using the same infantry AI code with some adjusting should suffice), some audio fx for audio feedback with explosions, dying infantry, and enemy shooting in general, perhaps some more music, maybe level-end bosses, and then there’s a game menu, game intro, splash screens, and maybe cutscenes.

Sorry, Smalltown Grocery… We may be here a while.


Smalltown Grocery – DevLog 3

I must admit, the name “Smalltown Grocery” is growing on me.  I may leave it as that, as mundane as it sounds.  lol

Anyway, I have some sad news to announce.  If you’ve been following along, you may have noticed it’s been a while since my last post.  In fact, it’s been 15 days.  (Half a month!  Holy cow!)  That’s what entering a game jam does to your productivity and workflow on a personal project.  It brings it to a screeching halt.  Let that be a warning to you, if you are a fellow aspiring game developer.  Game jams are fun, but they have a way of barging in and taking over.

Luckily, The day after I wrote my last entry (January 22nd), I did a little bit of work on Smalltown Grocery.  Here, let me make a new gif…

I created shelf items!  Yay!  I revamped the boring-looking art a little bit, too.  I’ll explain the shelves in a minute, but first I’ll tell you what happened.

I went looking around the world wide web for some inspiration.  At the end of the last DevLog, I noted that I needed to get to work on developing this game’s design more thoroughly, but I was hitting a block.  I couldn’t think.  But I knew there were other shopping games out there, so I went looking.  I found the typical lemonade-stand-type of game and diner-dash-type of game, and even a kid’s math game, but those aren’t really what I want to make.  I suppose the diner-dash-type comes the closest, but it lacks the depth I’m looking to create.  (I went looking for links just now, but I can’t seem to find again the things I found two weeks ago.)

But then I found “Supermarket Tycoon Prototype” and struck gold!  This was very close to what I was envisioning.

After watching the video, and reading the info and comments, I found the game on steam.  It took a bit of doing since I’m not as familiar with Steam as I probably should be, but I was able to find it and actually play it.  I have to say, Toby Kellaway (the game’s author) shows brilliance in this game, in my opinion.  It was inspiring.  Kellaway’s use of color and light-hearted character sprites heavily influenced the change in my art’s direction.  I don’t know if I’ll keep the character this way (since I’d like to keep the overhead view constant), but it sure has an appealing look to me.  I am definitely going to be using the color coding of shelf categories.

Speaking of shelves…

If you notice in the gif above, I was able to give each shelf 30 items.  (The game speed and movement speed was sped up for testing/debugging purposes.)  These items are arranged in 10 rows of 3.   The shopper chooses a shelf from which to get an item (randomly, at this time), takes one item from a randomly chosen row, then chooses the next shelf he will visit.  Each shelf has its own 3D array.

item[row, stat]

row number = (0-9)
0 = quantity (0-3)
1 = face position (0-2)

So when the shopper takes an item, it subtracts 1 from the quantity in that row, and adds 1 to the face position (product facing).  This way, later in development of the game, I can have the employee come along to face the shelves and/or fill it with more items by easily manipulating this code.  The drawing of the shelves and items use these arrays to position everything.  I surprised myself when I got it all working.

But then the Jam happened.  Now I’m stuck trying to finish that game.  Read all about it in the next blog post!  :)


Smalltown Grocery – DevLog 2

This week I’ve managed to come closer to terms with my limitations.

While trying to prototype grid-based pathfinding (using the gamemaker mp- and path functions) I have realized I will not be able to use small sized walls (4 x 4) in conjunction with larger objects (32 x 32).  When I tried it, the customer would travel too close to objects, overlapping them.  Plus, it causes major headaches when trying to map out a grid, having to adjust for the 4 pixels of the wall then start counting by 32′s again.  It’s probably do-able, but not by me!  No, thank you!  So I’ve determined/decided that a 32 x 32 square will be my grid cell size.  Thereafter, all objects will need to be placed so that the unused cells will allow for pathfinding.

Many of my shelves (Produce, Cold Cases, Freezers, Dairy Coolers) are 32 x 32 and they will work fine, as long as I don’t double park these on two or four different grid cells.  I must make sure they line up with the grid cells perfectly when I create the store layout for the game.

The regular store shelves are 32 x 16.  These are a little tricky.  I need to make sure the fronts of these shelves are adjacent to an open cell, otherwise they won’t be reachable by the pathfinding.  This leaves me with a slight dilemma of unused space behind the shelf if I want to put these against a wall. (You can see what I mean in the gif below.)

I found some graph paper and began scrawling out a level.  This was a good move on my part because it helped me begin to visualize what I was wanting to accomplish a bit better.  On graph paper, I mapped out an entire store.  But right now, I just wanted to figure out pathfinding from shelf to shelf.  A small prototype room of walls and shelves and a customer is what I need.

So, after throwing out a bunch of code and starting over, I was able to make a small (un-animated) prototype of a customer wandering to randomly chosen shelves, grabbing an item, then moving on.  Not great progress, but progress nonetheless.  Baby steps, man, baby steps.

The numbers on the shelves represent the amount of items on that shelf.  The black dot is a debug item I made to show the intended destination of the current path. (The coordinates were off a bit at first, so this was how I helped myself to see it better, along with the debug text at the top-left.)  The way it works is — it finds all the available shelves, randomly chooses one of them, finds the grid cell coordinates of the open grid cell in front of the chosen shelf, and then creates the path to those coordinates.  There’s a delay between paths with a toggle to grab an item from the shelf at that location.

After putting this together, I’m contemplating how to give different shelves (items) popularity factors.  With a high popularity factor, that item has more of a chance to be chosen as the next path destination.  I’m debating whether to give the shelves item types also (canned food, baking goods, pet food, etc).  This also gave me other insights as to what sort of stats I’ll need for the customer.  Stuff like:  number of items needed, perhaps types of items (produce, dairy, meat, etc), and customer satisfaction (if a desired item is unavailable).  I’m really going to have to give this a good, healthy think.  I don’t want to get bogged down in a bunch of unnecessary features, but I don’t want it to be too generic, either.

Looks like I’m going to have to get serious about writing out some game design elements and features on paper.  I’m pretty sure that is my next step, as I can’t really write code for features and ideas that are not fully formed.  :P


Smalltown Grocery – DevLog 1

I haven’t had a lot of time to work on this game, but I’ve done a few things.

Thanks to a few people from the GMC, I have a few game title suggestions to make the game sound more fun/exciting:  “Cleanup In Aisle 3″, “Attention Shoppers”, and “Checkout”.  I haven’t made up my mind about the title, whether keeping it as “Smalltown Grocery” or changing it, but the suggestions definitely help get the thought processes flowing.

Mostly, I’ve been working on sprites.  I’ve started an ‘art assets needed’ list and have been working through it, though slowly.  I’ve made a customer sprite and an employee sprite by modifying the person sprite in two different ways.  I’m not perfectly happy with it — I feel like I could make parts and pieces more interchangeable and modifiable if I separate them out more.  For instance; leg sprites, upper body sprites, head sprites — then combine them and color-blend them with code for variety.  But for now, I have a brownish customer and a black & white employee.  I also created a shadow to help contrast against the floor.  Now I’ll have to give everything else shadows — doh!


I’m a little stuck with how I want to go about coding the game, as far as laying out the store’s floorplan.  My shelves will fit into 32 x 32 grid squares, so I was thinking of using grid collision and pathfinding.  However, I don’t want my walls to be 32 pixels thick.  I want them to be 4 pixels thick.  So, I’m trying to figure out how to manage the two different sizings, but I really have no clue about where to begin.  I found a write-up about using something called HAA* pathfinding to do this, but it was beyond my ability.  Trying to read and comprehend it was turning my brain to mush.  Maybe with more study and patience I will find a solution, but for now I think I’ll keep working on sprites.

So, that pretty much sums up my progress.  Not much this week.  Probably not much next week, either, but we’ll see.


Older posts «