~Info

Engine Used: GameMaker Studio 2
Repository (GitHub): https://github.com/gurpreetsinghmatharoo/lowrez-2018-procgen

~Procedural Generation: How does my system work?

At a time, a certain square area is generated. Its size is in the AREA constant, currently at 512.
The constant DIVISION is the size of the distinct parts of an area (of the size AREA). A division currently is 256 (so each area has two divisions). Each division is of a certain type; it can be a village, a forest, a hostile area, and so on.

The constant SIZE (12) is the size of each individual block that holds something (grass, tree, house, etc.). You can also call it a cell or a tile.

So when the grid for the current area is creating, the divisions are generated, and looping through the divisions, tiles are placed. Different tiles have different chances of being placed inside different divisions.

~Team

Music/SFX: Micah_DS
Everything else: Matharoo

2 days ago I've collaborated with Kipar to make rogue-like game in Fallout style. More info coming soon!

c:

I just realised that my game is not 64x64. I set my resolution to 64x64, but then I went and set the camera zoom to really far out without thinking about what that meant. So yeah I'm dumb, and I guess my game is technically disqualified xD I tried changing it so that it actually is 64x64 but it turns out the game is not really playable at that resolution haha. Anyway I'll leave it up unless I'm asked to remove it, otherwise feel free to rate me 1 star on authenticity.

Let's do a quick post mortem on Pixel Beard, while it's all still fresh in the mind.
Two weeks is probably about the minimum for a jam I can do these days just due to time constraints.. I didn't even bother with Ludum Dare this time round, as I just cannot dedicate an entire weekend to something. As it turns out, I'm not all that great at finding time over two weeks either...

Week One.

I effectively had about 2-3 hours a day; an hour before work, my lunch hour, and an hour after work. I was able to quickly build the various mini game stubs together, and was quietly confident that they'd all slot in to the overworld nicely towards the end. In actual fact, they did; as they were written as entirely separate modules, and store and tear down their own state - following a simple init, step, draw, end framework. I also started to add a few things to the general game state that sadly didn't quite make it; factions for instance. There is basic faction code in there - to the degree that there's four types of pirate running around, but they don't really do anything. There was a Stats screen created that showed your relation to them, and you'd be able to do a bit more in the Town to see their relations with each other, but I had to take it out - it needed more work, and there was no time. Additionally, there's Quest code in there, as Towns would give you Quests to go and capture something, and the Treasure Maps would actually give you a minimap cut-out to go find it yourself, rather than just increasing the chance of a treasure chest.

On the plus side, the overworld did get infinite procedural generation of maps. If you swim or sail off the end of one, a new one is generated. You can go back to a previous one as well. The entire world state is renewed each time you spawn, so for what it's worth, you should have infinite maps to play on! There's also a day-night cycle, with nasty sea monsters appearing at night. There was meant to be more ( there's code for sharks and wolves ) but they didn't quite make it.

Unfortunately, when the weekend came, most free time just disappeared as kids started back school and things had to be done for that...

Week Two.

The entirety of week two gave me 8 hours. Four of these were on Thursday night, stripping things back and finishing things off as frantically as I could to get something playable for submission.

As said, kids started back school.. and I lost the hour in the mornings so only really had lunch times. I had also thought we had Friday as well, after misreading the time as ending Friday 12am to mean the end of the day, not the start of it. As such, there is no sound. At all. I also managed to mess up the scaling ( which is now fixed so those with 4k monitors can have fist-sized pixels if you like ) and that "title" splash was done in five minutes on my laptop track pad just before submitting - and it shows. Given the same amount of time as the previous week, I fully believe I'd have been able to get everything else in, but oh well.

It was fun though. I think there's actually a fair amount in here for a change. You can die in a few ways - some fairer than others. And while there's a few minor gameplay bugs, as I basically have only tested it properly today, it's relatively playable and a nice foundation for further work.

Now to find some time to rate the other entries... this "life" thing needs a pause button!

I'll update this as I go, but first, a quick Q&A:
Q: What is STATS! about?
A: Fishing.

Q: Really?
A: No.

Q: What is it about then?
A: Stats.

Q: Will the game be fun to play?
A: I simulated the game via an extended conversation with a family member. He enjoyed the conversation, so I can only assume that means the game will be great.

Q: Any more information?
A: I'm not an artist and I only started learning to code anything a few weeks ago in my spare time. I'm working on this alone, but if I can get the game done I genuinely think people might have some fun playing it. I'm literally learning as I go so it might not turn out exactly how I'd like it to, but if everything goes to plan, there will be choices, there will be risks, there will be rewards, and there will absolutely not be any text.

I decided during the lead up to the event that there were a few things I wanted to try a do in this project. 

• Continue working with procedural stage generation.  I started playing around with this in my  A Game By Its Cover entry.
• Create a seamless world wrap, so it feels like your moving in a infinite loop. I tried this in  past project years ago, and never got it to work the way I would have liked.
• Create a platformer where you can jump on enemies to "attack". As simple/basic as it might seem, I've never actually done a project that uses this mechanic.
• Create artwork last (or much later in pipeline). I typically lead with artwork and as a result usually have a very incomplete feeling project as far as mechanics and level design. I'm even going to try and put sound ahead of visuals.

So, over the last two days I started working on  a vertical, procedural generated, "out-run" platformer. The back story that I've started working out in my head is you play as an alligator in a sewer that is being flushed out by an exterminator. I already have ideas for the pixels, but I've resisted and will hopefully start tackling those tonight/tomorrow.

For the procedural generation, I plan to create modules(a section of platforms/world approximately 64x64 or 64x128)  that will be strung together to create the level. I had initially thought I'd do an infinite runner, but decided I wanted to add another bullet to my scope list. Boss Battles! I'd like to include boss stages and boss AI(something else I've never done). Keeping with my story, the exterminator is the big bad. In fact the boss will always be the exterminator, that will get a new attack/mechanic each time you see him.  Right now, I've thrown together a few "modules" (they need some work as far as good platforming) and the amount of modules used will increase with each stage.  As you advancing to the higher stages it will also pull from a larger module pool, including more and more difficult layouts. Will probably insert the boss stage every 4 stages.

I'm not sure how I feel about the "seamless loop". You can compare the following two gifs to see the difference.

The above capture uses a stage that is only 64px wide (the width of the window). However, the camera always follows the player and the world is infinitely wrapped. As a result, the world feels a little larger and you end up with some interesting approaches to the platforming.

The next capture is the same stage but this time the camera is static on the x-axis. The player still "wraps" but the stage definitely feels smaller and more confined. I think I like it better though. It may be the nostalgic callbacks to the original Kid Icarus though.

I've also created 4 enemy AIs (though they aren't used very well in the prototype).

• "Ping Pong" (red) - ping pongs at walls and ledges.
• "Dropper" (red with blue down arrow) - ping pongs at walls but will drop off ledges
• "Hopper" (orange) - will hop forward 3 times when player is within range
• "Dasher" (green) - when the player is within line of site, will do a windup animation (not present in prototype), and then charge towards the player.

I'm thinking about adding two more enemies

• "vomiter/slug" - this would be a re-use from my last lowrez jam. vomits a hazard as well as leaves a hazardous trail on blocks
• "spike" - an enemy you cant jump on.  Mainly to add more difficulty in later stages.

I'll be posting pixels in my next update hopefully.

If you're interested in trying out my prototype, you can download it here.

Trello board: https://trello.com/b/guORrPwT

Game Page: Coming Soon

Current Status:
Door in place and camera pans to boss room.

Next Goals: Code boss, reset level on death, way to kill things.

==========================================================
Original Post (Not updated)
==========================================================

So this is now my third low rez jam if I remember right. Last time was low rez knight which was kinda a zelda-like that didn't have any story what so ever. This jam is interesting since it will be 2+ weeks long. Unfortunately that probably means I'll slack a lot. Anyway, onto the actual devlog.

First day, I made a basic environment to get started with. I'm using my own package I call maker. It's a tileset painter that runs in the actual game. Eventually I will probably sell it, but for now it's my tool and no one else can have it >:D. Anyway, it's more or less a tool to turn your game into a maker akin to mario maker and the like. Why not add a level editor to your game right? Well, it's not finished, and also t keep in theme with the jam, I'm only really using it to make the levels for the final product rather than have an actual editor in the game. Anyway, here's an example of the terrain.

It works pretty good, but as expected, limited space for gameplay in a 64x64 pixel screen.

I also made 2 frames for showing the main character Astrea walking. Here's a single frame of her:

There was a lot of talk in the discord last night about help getting unity setup to be pixel perfect and show the right resolution and all of that, so I made a zip file containing an entire get started project for the low rez jam with unity. You can check it out in the resources subform here for the jam. It contains a camera that automatically snaps pixel perfect and a script so that you can add it to other objects. There's also a canvas that adds borders to the screen in case it's in a widescreen format when you play the game. Yay for black borders am I right?

Anyways, the first challenge was to decide what kind of game I was making. Last year I made G-dungeon, which had some problems, but overall it was an OK puzzle game. (Except for the difficulty which was just absurdly hard. I just went back and had to use my own help files...)

This year, I wanted something different, something with more movement and life. Because of the limitations, a fast-paced game is near-impossible to pull off, so I was left with two main ideas: A rougelike, or a turn-based strategy. In the end, I decided to do both. I always had the problem of overscoping my games, so I'll try to keep this as simple as possible.

With the genre and style in mind, I had to create the actual game mechanic. This had to be good, because it needs to give a lot of complexity in a small, confined space. The game itself is played on an 8*8 grid, each tile 8*8 pixels, and the mechanic I went with was a basic gravity-changing one. The setup is simple: There are enemies and traps that try to kill you in their turn, then you can squish them in your turn. Should give enough depth to the game, and it's not too complex.

For today, the first task was to create the basic game window using Game Maker 2, so here are the results:

I just wanted to test the pixelation in work, so by the next update I should have the basic mechanics done.

UPDATE 1:

Now, the main player control is done, with some visual effects:

This move really had to be powerful, so it doensn't seem like the character is just moving. It needs to have an inpact, where you can believe it could finish off an enemy. For that, I used 4 different effects: A smoke trail, fading player sprites behind the player,  screen shake and a landing "dust impact". I also added a few test targets just to take a look at how it feels to destroy something with this, and for now, I'm happy with the results. 

As for the camera, controlling it with the mouse works for now, but it gets too unstable with bigger maps. I might have to think about a multiple-room map system if I don't figure out something soon.

I also made a small tileset, though I'm not too satisfied with that one. Not too bad of a placeholder though. Also, I have no idea what the player could possibly look like and I can't just leave it like this, so there are still enough things to do.

I like to divide work up into phases, so here are the ones I'm starting with this time.

1. Initial setup
   1. Cards
      1. Define and implement Card data structure(s)
      2. Define and implement Unit type
   2. Battlefield
      1. Piece together background sprite
      2. Create battlefield scene
         4 rows, 4 cols, 0px borders: 16x16px cells
      3. Basic battlefield manager script
         1. Start with placeholder static player/enemy Decks; only attack-type Units, no Instants
         2. Shuffle Decks
   3. Rendering
      1. UI corner card rendering with deck count
      2. Player hand overlay of top three Cards
      3. Sprite rendering of Unit on battlefield
2. Punchline
   1. Play a card
      1. Implement Card click/touch in overlay
         1. Fade out overlay
         2. Remove Card from deck
         3. Instantiate and render Unit (fade in)
   2. AI intro
      1. On AI turn, play a Unit card if possible
      2. Instantiate, fade in Units same as player
   3. Initial round
      1. Implement 3 or 4 board positions for player and AI, if not already done
      2. Alternate player and AI playing Unit cards for 3 turns
      3. Third turn: Start enforcing must-play rule
         1. If no Units in deck, lose
         2. If Unit(s) in deck but none in hand, require discard until one is found
   4. Unit on Unit action
      1. On third turn completion, start fight/draw process
      2. In order played, Units select and attack enemy Unit
      3. Trigger next player, AI turns
   5. Win, Lose, or Draw
      1. Lose/Draw screen (same result for player)
      2. Win screen
         1. Show and award player one random card from opponent’s hand
            1. Level up this card to initially make winning useful
         2. Create dummy card management scene
         3. Redirect player to card management
3. Come with me if you want to… die
   1. Deck/library UI
      1. Two rows of tabs on top; horizontally scrolling card listing on bottom
      2. Implement live filtering for primary/secondary tabs
      3. Need UI element to enter fight
   2. Card click overlay
      1. Move card to the left and show buttons
      2. See pixel layout at bottom
      3. Deck add/remove, trash buttons
4. Heal/defense
   1. Add/implement this type of Unit
   2. Test with player deck
5. Instants
   1. Add Instant type cards and effects
   2. Implement in battle scene
6. Superficial Intelligence
   1. Teach AI to heal
   2. Teach AI to use instants

Here we go!

Debug Snake is a game that takes inspiration from snake and other classic games.

You play as Debug snake with your goal being to reach a score of 1000 by shooting broken code (Bug spawners), smashing paint cans and kill 10 bugs. The only way to kill the bugs is buy the leftover paint that is left by smashing the paint cans. A game of simplicity that's difficult to master!

Released a patch on 15/08/2018 which fixed minor bugs and improved on mechanics.

Myself and J.Omar have been working on a little platformer about bees! 

Basic collisions and movement all went off basically without a hitch! Even solved my half-pixel collision problem that I also had in another project. Everything was great until it came time to deal with the health mechanic. I'd never dealt with any sort of melee attacks before so had to take some time and do some learning. I'm happy to say that so far as I can tell, player attacks, damage and enemies are all working! 

NPCs were next and without issues! 

The boss battle has definitely been the biggest challenge of this project so far! It's still very much a WIP, but the boss attacks & takes damage now! The timing between different states needs to be tweaked for sure & nothing happens yet when he dies. I'm also getting a glitch where the boss stops creating it's hitboxes if you restart the game a few times. 

Unforunately I've been on the road for the past 4 days (and again for the next few) so I've lost a lot of time on this. There's 100+ things we've been thinking would be awesome to add to this so we'll see what we can manage! Hoping to make this game the best it can bee! 

Here's a little mockup of what's to come! (by J.Omar)

Dev status: done. Play it here.

This game is a turn based tactical game.

You control 3 spaceships, to complete a mission you need to take down every enemy spaceships. The game is broken down in 12 missions (selected from a list of ~ 40missions), with increasing difficulty.

The final score is equal to : total life points * 100 . To get the highest score, you need to finish the game without taking damage, and also extract the life points from the planets you will occasionally encounter. To achieve that you will take advantage of your squad abilities:

• Ship 1 : Move fast, has an attack ability
• Ship 2 : Support. Move slowly, cannot attack but can grant a shield to a friendly unity. A shield prevents any damage once.
• Ship 3 : Move moderately fast, has an attack ability. Also has Hack ability. Hack allow you to manipulate turn orders by switching two characters places in the turn list.

Planets are also friendly units. They can launch a nuke, which is a powerful attack that strikes at the beginning of their next turn.

Screenshot1: Gameplay
Screenshot2: Reallocating life points between two missions
Screenshot3: Hack skill demo

This year I'm hoping to do what I couldn't do last year with the game: More levels, more environments, more enemies, and more moves! It's going to be a fun challenge, and also a bit of a time crunch. I'll be exhibiting my main project, Atmocopter, at 2D Con from August 3-5, so that'll cut into my development time a bit. Between that, my regular pixel art work, and real life, we'll see if I make the game happen in time!

Check back often for updates... I love to write 'em!

DAY 1 (August 1)

I'm a bit rushed to fix bugs in Atmocopter before the convention, but I started work on Demon's Hymn 2 today. I got the project set up and running, and made some palette updates to the main character. Because I'm planning a few different environments for this game, I decided I'd use the Dawnbringer 32 palette to try and give all the game's art a cohesive look.

Here's a mockup of how a level in Demon's Hymn 2 might look, using the DB32 palette. I'll be leveraging some of the art assets I've already made to speed up development and make the game the best I can. The tileset pictured is Retro Pixel Cave. I was a little concerned about whether or not the character would stand out enough from the background, but I think it'll be alright in motion.

Aw, what the heck. Let's just animate it quick and find out!

Should be fine. He might get lost a little in the bluer areas of the background, but the motion should be enough to make it clearly visible where you are on the screen.

Finally, here's the title screen.

Tune in soon for more! ୧(๑ﾟ⌔ﾟ๑)୨

I'll be doing Pico-8 this time, with the 64 pixel hack code to keep the res true 64 pixels.  I've developed a grand total of 2 released alphas on the system (which were unremarkable and quickly forgotten about by the community), and a pile of half crashing buggy silliness to remind myself I'm no programmer on my pocket chip.  So that makes me a total master in indie terms, right? :D 

PRO TIP:  I recently discovered you can enter floats for the "sprites to copy" command in this engine.  Since the sheet defaults to 8 by 8, this trick lets you blot 4 pixel wide sprites using 0.5 as the number of sprites.  Pretty sweet little trick.

Last time I did this jam, I used Clickteam Fusion, and the lack of limits made me scope way too far for the jam length.  (The result was eventually the game Drake, you can search and play it here on itch.io, but the road there was much longer then the jam time so the jam version was a single level amount of sad :p).  So I hope that by picking a more primitive engine, I can limit my scope better.

Got an ambitious prototype in mind for a random generated metroid-like experience.  (Good job, I just failed my scope objective and the timer hasn't even started. )

I've had the basic plans for almost a year, but never found an engine I was happy with to build it in.  My hope is that by making a scoped down version in a primitive software, I can motivate myself to get the real game out later.  Basically Drake project again.

Given the game engine I picked, and my current "super lua powers" of accessing empty null parts of tables 90% of the time,  It will be interesting to see how far I can get before breaking down into insanity and crawling under a table.  :p  Oh well, shoot for the moon, right?  

At least the graphics won't be a problem this time.  

I'll try to post at least one update a day during the jam to keep myself accountable.  So if nothing else, you get to read stuff from me.  My hope is the game ends up being more fun then reading this, but at least we have two weeks of posts like this to fall back on.

Let's rock!  And to everyone else entering, best of luck with your games!  This is a great jam to prototype stuff or just play around without needing to worry about graphical talents!

And a very special thanks to the jam hosts!

BUILD TURRETS. KILL VIRUSES. PROTECT THE CORE. EASY.
Mr.Tobro antivirus is here to save YOUR system! At first, you'll be tight in Mr.Tobro small window. But the more you kill viruses, the greater it becomes!
I submitted Mr.Tobro for Ludum Dare 42 and the LOWREZJAM.
It's a SHOOTER TOWER DEFENSE where TOWERS DON'T SHOOT AUTOMATICALLY and where YOU RUN OUT OF SPACE quickly. 

For now the is not well balanced, I think I'll add more enemies and modify turrets prices.
Don't hesitate to let me feedback so that I can make the game better before the end of the Jam !

--CLICK HERE TO GET TO MR.TOBRO ITCH.IO PAGE--

For those interested, I'm writing my game in Python using only pygame (at the moment). My plan is for it to be a basic RPG in the style of classic SSI Goldbox RPGs (Like Pools of Radiance)... mostly the exploring and talking with NPCs part of it, anyway.

I'd like to say I'll be coming back to keep this Devblog updated, but I generally have limited time after work and most of that will be actually working on this game... so... I'm not sure how often I'll be able to update.

That said, this is open source and all my work can be seen at https://github.com/ObsidianBlk/Goldbox64 . Feel free to look around!

Anyway, until next time!!!

Following the first and second games, it's time for the third entry in the Legend of Xenia series! Now for the first time ripping of the Legend of Zelda in the third dimension. At this point I am not sure whether this is a sequel, prequel, remake of 1 and/or 2, an actual ending to 2, or all of the above ¯\_(ツ)_/¯

- Day 1? It hasn't even been 24 hours yet, but I'm going to bed now. "Day 0.5"?

I spent today doing some preliminary engine work. I'm using GMS2, and I'm doing a 3D game, so I set up a base project, and tried to program some simple 3D collisions and ramps. The entire project hinges on this, so it better work. For now it looks like it does, so that's nice.

If Legend of Xenia 1, with it's simple Pico-8 look, was inspired by Zelda games on the GameBoy, and Xenia 2, with its Minish Cap-esque colours, inspired by the GBA... Friends,  it's time for janky 3D graphics like on the Nintendo DS! 😃

The idea of making a game where I can't design everything specifically for the 64x64 resolution (as I could with 2D pixelart) is very interesting! I am looking forward to the next 2 weeks a ton.

Clickromancy is a teen-weeny clicker game (think Cookie Clicker, or Clicker Heroes) where you click the magic tome - the Clickronomicon - to summon as many minions as you can!

I've got the basic mechanics of the game completed already:

- Clicking to earn minions

- Buying buildings to earn minions passively

- Unlocking more buildings to increase your minion summoning potential!

At this point I'm just coming up with new buildings to add, making sure the art is ok and polishing bits where I can. I'll post some gifs on the topic tonight when I'm back at my PC, in the meantime you can check out my twitter to see the game in its current state: https://twitter.com/LewisCIark?lang=en-gb

This is my 3rd official jam, didn't have time to finish the previous one unfortunately. I need to take a break from trying hard stuff so I'm going to chill a bit and try something fun and simple for a change. I am absolutely HORRIBLE at art though so don't expect anything good there, thankfully cc0 exists.

So what's this game about ? ( Edit: better gif )

Ah. It's just a "let's mix stuff I like for the 64x64 support and see how it goes" to be honest.
It's actually not a roguelike at all! Right now it's kind of a Final fantasy legends with roguelike graphics using the final fantasy adventure battle system. Yeah, I just had the gameboy games in my head for a while so I'm just going to experiment. I went with a 8x8 roguelike artstyle because of the screen gameplay space I wanted, 16x16 even centered on the player would feel wayyy too big.

Anyway right now everything feels a bit too green so I'll work a bit on the colors and tiles before starting to think of the worldmap.

Day 1:
 Start working on a movement mechanic and display on 64*64 pixels.

Day 2:
I planned to use sprites in the 3D world using bill-board. Everything looked good until draw order issue appeared. It took a few hours to solve this issue by wrote own sprite shader instead of unity's sprite shader and set "camera.tranparencySortMode" to "Ortho"
   Also, Implement flashing light from the phone to interact with objects in the game.