The temporary name, 64x64 ill-fated, is aiming to give you a simple game that you can play with other 3 friends.

This is something totally new from me since but I have a bit more time than last year when I did 64x64 UFOs in just 15 hours.

I hope we can give you something nice to play.

Here is a first video of the game in action:

Let us know what you think about it and follow the development.

Thank you!

My experience in gamedev thus far can best be summed up as a trial-by-fire-where-everything-is-on-fire-and-new-fires-keep-popping-up.

The trickiest part of this whole process has been bridging the gap between expectations and reality. I’d tried to establish manageable goals for myself, and I don’t think my rationale was too unreasonable: a game limited to a 64x64 canvas using PICO-8. The constraints were so small that a game just had to get made, right?

That was how LOWREZJAM began for me: cleaning the barrel, loading the chamber, and priming the trigger just so I could shoot myself in the foot down the line. I’d read several beginner's guides to game development and gotten it into my head to not start with my dream game. That was fine. My roguelike dating sim will just have to wait. From there I reasoned, “Well, why not use arcade games as a template? They’re simple and straightforward with plenty of replay value.” Not a terrible point of view to approach the project from. No, instead what was terrible was how much I allowed that initial concept to evolve into a Frankenstein’s monster patchwork of ideas and mechanics. The game, whose final release title is A-Taco-Lypse Driving, was supposed to be “an arcade-style vertical scroller where you deliver food to customers while avoiding hazards and battling enemy competitors. Easy enough, right?*

*see previously linked video

The original proof of concept drawn by my brother. 

With a concept in mind, most of the time spent on the game was taken up by learning how to code. I’d attempted other projects in Lua before, but this was the first time I’d really dug into the language and what it was capable of. In spite of my best efforts, the problems that arose seemed to be unending. For every issue I solved two more would pop up in its place. 

One of the issues I encountered early on. Lesson learned: be better organized.

For several days my process essentially boiled down to throwing possible solutions at the wall until something stuck. The big paradigm shift that increased my productivity occurred when I approached the game on its more elementary levels. For something that involves so much math and logic, it’d taken me longer than it should have to realize that planning out possible solutions with discrete data and information produces better results.

Remember kids: always show your work.

This was also the point in the development process where I realized my scope was larger than I had anticipated. In a bit of interesting retrospection, my friend Julian had the notion that I may have bit off more than I could chew and warned me as much. In a recent conversation with him, however, he admitted that it was something I’d have to find out for myself. While coding proved to be the bulk of my challenges, I most definitely learned more than just programming. Ironically enough, my focus on shoring up coding deficiencies resulted in me neglecting perhaps the most important part of the game: the gameplay.

Believe it or not, the released version of the game is just as cluttered and messy, if not moreso.

I had gotten so wrapped up in getting my game to work that I completely forgot to take a step back and figure out if the the game was fun. The development process for me was a triage of shoddy mechanics when it should’ve been a clear roadmap of priorities. My mistake was in not understanding what my limits were and what I was capable of. This goes back to my conversation with Julian where he helped me realize that perhaps this would be (and it was) a fact that I would just have to learn the hard way. The hard way ended up looking like:

1. Start with a nugget of a game idea
2. Add more facets/features to that nugget
3. Figure out how to program it into the existing build
4. Realize there are roadblocks and obstacles popping up that prevent me from easily implementing these features
5. Spend time to try and work it in anyways
6. Be pressured by the deadline and shift focus onto another aspect of the game
7. Realize these features also have their own roadblocks and obstacles
8. Back to Step 2 and keep jumping around Steps 2 to 8 depending on the mood of the day

I saw the words “Runtime Error” more times than I care to admit. And I’m already admitting having seen them a lot.

What was interesting to see in how I worked was my tendency to fall back to my comfort zone. On a micro level this meant fixing the issues I could immediately address and/or knew how to address. On a macro level this meant stepping out of the developer role into the manager role. I was fortunate enough to work with two incredibly talented individuals, my brother, Noah, and my friend, Grant, who helped to produce the visuals and sound respectively. Coming from a background in the arts and entertainment, it took me (comparatively) little effort to crystallize a final vision for the narrative aesthetic and tone for the game and communicate that to the rest of my team.

Original game is 64x64 but PICO-8 scales screenshots up to the engine’s default 128x128 resolution. Here you can see the ravaged post-apocalyptic wasteland of the distant future: 1999.

The end result is a game that has a strong personality, but is severely lacking in mechanics. There were far too many moving parts that weren’t intuitive and didn’t mesh well with each other, pitfalls of the game that stem from the seat-of-my-pants approach I took with the development process. 

The final PICO-8 Cartridge. 

In spite of all the glaring flaws with gameplay and the amount of stress I endured, creating this game left me with a complete and utter sense of satisfaction, something I haven’t felt in a long while. This was entirely a labor of love and I think (read: hope) it shows. 

Organization is still very much an issue I face as an artist and developer. Maintaining focus and discipline towards a project is a difficult endeavor, especially knowing myself and how easily I lose interest or steam. But understanding my shortcomings is worthless if I don’t take steps to rectify them. The first step to avoiding these mistakes in the future is to take it slowly, ensuring that above all a finished product will have polish. What that means for me is understanding my limits, both in terms of what I can and can’t do. 

And maybe, just maybe, that roguelike dating sim I have floating around in my end will someday end up on somebody else’s screen.

-Kyle

I have a good concept and I'm proud of it but I don't want to spoil it for now, so you'll discover it when the game is ready.

I started with the title screen

And I made the song!

Even if there is not much to see at the moment, what do you think about this game? 

Good luck for this jam ;)

A small rogue-like inspired by Zelda 1 !

#1 - Mockup !

The idea of the game is based on a mockup I did for Pixel_Dailies. The theme was "Dungeon", and I got inspired by the dungeons of Zelda 1. Some 8*8 tiles later, I've got this :

https://twitter.com/Le6barbare/status/853395895580319744

Then for the jam, I've extend the mockup, with a title-screen (there will be a transition between up and down), some more tiles, characters, items, and the inventory !

There is a lot of things I'm gonna change/rework, but this can wait. ^^

#2 - Unity

For now, I need to work on actually making the game !

And it's gonna be hard. First problem, the resolution... But hopefully, with the help of the people on the Discord Server, we have a guide !
But I think I'm gonna try another method. Will talk about it later !
I've had some problems with the import of my sprites, but again, people of Discord were here to help, thanks !

So, Froak! was a bit of fun to unwind a bit from crunching on our main project - Snake-A-Roid 2.0. We'd just come back from the 4TG Game Con in Aberdeen that weekend, we were knackered, and it being the end of the Summer holidays, the kids were extra hyper about going back to school... so a perfect jam environment!

Froak's initial design was scribbled out on a small notepad the day the competition started during lunch.
It was actually going to be quite different from how it turned out.

Originally, the plan was to test out ideas for dual-stick controls... left stick to bounce about the lily pads, and right stick to flick out the tongue in eight directions to catch a fly. I threw together a quick arena of lily pads, calculated a grid, gave all of them a fly, and made a frog to jump about.

Then life got in the way until the weekend.

At this point, I hadn't looked at using the right stick yet, and was spending my time trying to get the jumping between lily pads sorted, and just collecting the flies as you went past. It seemed nice enough, and thinking it was too easy, added a lily pad sinking mechanic so that while there was a frog sitting on them, they'd slowly sink. ( Though at this point, they resurfaced rather than disappearing completely like the submitted version. )

The weekend came and went.

Over the next couple of lunch times, I added some more elements - the logs and crocs - and tested a few level layouts.
At the half way point, I stopped to have a look at everything and realised that the 4x8 grid layout I had given myself wasn't going to lend itself to interesting puzzle levels. I'd either need to make a bigger play area with a scrolling camera, or have a rethink. I'd already coloured four different frogs, so thought of changing it into a multiplayer "battle" thing instead. Be the greediest frog, eat all the flies, jump on the heads of the other frogs to steal theirs. Simple!

The next weekend appeared quicker than I expected, and I only then managed to sit down and write a little bit of "AI"
They ain't smart.
What they're supposed to do, is look at the (usually) 8 squares around them and jam all the cells with flies in a list. Then randomly pick one and go after it. If there's nothing in the immediate cells, look another set out. Repeat a few times to make sure the reach goes from top to bottom and failing that, pick another frog to go after until flies respawn. Pretty straight forward stuff.
What they actually tend to do, is pick the top left fly and go after that, then get confused when something else eats it and jump in the opposite direction.
Emergent Froak behaviour... honest!
There is a bug in here though.. in that I lock on to the fly's position, rather than the cell position.. and as the flies buzz around a bit, the frogs can get confused and think they're further behind/infront than they are, and jump about a bit more erratically than they should. Another bug, is that when they sink, their state can sometimes get mixed up and they go into limbo.. I didn't find this one until after submissions had closed, sadly.
I also got multiple pads working in both browser and Windows, so upto four players could play, and had the keyboard work as a separate interface from pad one... so if you only had one pad and the keyboard, two players could still play.

So, Monday rolled round and it was still pretty quiet... so I tried throwing some music together.
It was surprisingly harder than I expected, just due to having been working on Snake-A-Roid; an Arcade Arena shooter with a crunchy chiptune soundtrack with a much darker style than Froak. I needed something bouncy and happy. So nothing worked out. Spent most of Tuesday at work listening to Spectrum chiptunes to get those happy bouncy squarewave arps in my head! Not sure if my headphones leak or not, so that must've been fun for anyone walking past.

Tuesday night, I rattled out a title tune, and did two ingame tracks and a podium win on Wednesday plus sound effects.
Turned out alright, I think!

Wednesday lunch time; added some menu states in and the game loop, so you went through: splash -> controllers -> game -> win -> controllers etc... and threw together a few more arenas that are randomly picked. There's five in total.

Wednesday night; finished tidying things up a bit - such as the lily pads not resurfacing - and finished the music.. did some quick tests in the browser to make sure it all behaved, then just threw it onto itch.io about half an hour before deadline.

And that's that, really!

Nice and simple little game.. a couple of bugs lurking, sadly, but fun enough to hopefully continue later. Might stick up the GMS2 project later, if anyone's interested.

Now to go rate some games!

A sequel/prequel/remake (or something like that) of my lowrezjam 2016 game Legend of Xenia.

Quick jump to update: → Day 4 → Day 5 → Day 6 + 7 → Day 8 + 9 + 10

Day 1 + 2:

I, uhh, spent day1 finishing another game, Snowfriends. I then wanted to start lowrezjam on day 2, but was lazy and played PUBG instead, whoops 

Day 3:

I spent today doing art research and doing some mockups. I know that I want to make a game in the same universe as my last lowrezjam game, Legend of Xenia, which was (supposed to be) a small Zelda-like, so I replayed that game and took a look at the art in it. It hasn't aged well, to be honest. It was primarily inspired by the GameBoy Colour Zelda games, as well as some Pico-8 games, and the colour palette was Pico-8 as well (I'm not using that engine though). I want to have a similar look this time, but with higher quality art in general, and a much nicer palette, so I started researching other games and stuff, and started doing some mockups by basically enhancing the assets from last year. Here's what I've got so far:

Legend of Xenia, from 2016	Legend of Xenia 2 mockup	Comparison GIF! :D

As you might guess, the new colour palette (and style for things like the grass) is heavily inspired by The Minish Cap. So where last year had art inspired by Zelda games on the GameBoy Colour, now the palette is inspired by a Zelda game on the GameBoy Advance! Hehe, next year Nintendo DS?? 

That's it for now, see you again tomorrow where I'll start programming. 

→ Day 4

Latest update: demons have arrived

Intro

Hi everyone! This is my first game jam, and I have to say it's really amazing to see all the work that everyone's put out so far 👏

So, what is Off-Grid Orcs?

Theme

• I've had orcs on my mind ever since watching the Warcraft movie. Warcraft II was totally my thing when I was a kid, and I loved building bases, gathering resources, researching upgrades... If I can capture a bit of that feeling, then I'll have accomplished the primary goal of this game.

Graphics

• One of the previous #LOWREZ games that caught my eye was Norman's Sky -- I had no idea that that kind of rendering would look so great in 64x64. I'm curious to see how far I can push these pixels myself (in 2D).

Control

• A pet peeve that I have with strategy games is that unit control doesn't scale (for me as a player) at the endgame. I always lose track of units/areas because I'm busy micromanaging, when I'd rather be sitting back focused on strategy. This seems like it'll need some heavy AI lifting.

Tech

• To make things "interesting" I've stacked on a couple more tech constraints: make the game with HTML5, and use a Functional Core, Imperative Shell architecture. This will be my first big program to use functional programming through the whole core, and I'm really interested to see what benefits it brings.

Anyways, I'm finally at a stage now where the first orc shows some interesting behaviour. Here's the build process (sped up for the GIF):

The next thing for me to add is that once the first building (HQ) is built, new orcs will come, and you can start expanding the settlement. I'll have to see if you'll defend against nightly waves of demons before this jam finishes 😅

What do you think? Is there anything that you'd love to see in this kind of game?

Oh, and if curious to see what Scala.js game code looks like, I've got everything over on GitHub

I was trying to start making a beat 'em up game for several years now. It is the most successful attempt so far :D

Test 1.  This is of course using a test track (Mario Circuit from Super Mario Kart), but the general look is what I'm going for. It does also show that a LOT of detail gets lost, so I will likely have to use a super simplified coloring and sprite style to make sure things look clear and interesting.  

A problem I realized I'd hit very quickly was working with Physics + Physics2D issues. This ended up being an issue for mainly the movement and triggering system (that'll come up a bit later) , but primarily for getting the ship to recognize different terrain. Due to the rotation of the camera, the sprite wouldn't lay correctly on the "terrain" to pick up terrain friction,  so I jerry-rigged a solution: 

On the left is the sprite I'm using for the track. On the right, is the heatmap I'm using for my gameobject to raycast the color for - thus knowing what type of color or terrain they're currently above. The added bonus for this that I didn't think about until much later was that this can also help for non-terrain specific situations - such as the charging pads in FZero. Here's the setup for my player controller currently:

https://itch.io/jam/lowrezjam2017/rate/166162

Also, updated the game page to include some better (maybe?) instructions

https://anarbitrarymustache.itch.io/tiny-loot-runr-64

UPDATE 4

Been a very busy day. Normally, I do my updates the following morning, but it's already morning and I'm still up so what the hell! I'm just gonna list out what I managed to get done.

• Fixed my pause system - turns out the dug-out blocks weren't pausing. I decided to go back and completely rework how I was pausing, which is now much more flexible. So, hopefully no more problems there. (That would typically be a bug I wouldn't get to until after the JAM).
• We have sound! (not that you can tell from the GIFs though). I think I've completed all of the sound effects (some still need to be tweaked). I have place holder music in place right now. May try to capture a video. Will see how I'm feeling tomorrow.
• 2 new enemies! - which led to me re-working my pathfinding system. The good news is it seems to work better (not perfect still) and the code is much cleaner and compact now.
  • "Slug" - very slow and leaves a hazard in his path. Slugs can't crawl out of holes, so dropping one into a hole is a guarantee kill, which can be incredibly dangerous with the mitosis. You can use your digger tool to clear the hazard trail. Slugs won't pickup coins, but will instead "taint" them, turning them into hazards for about 10 seconds.  I'm considering having the digger tool remove all connected trail, and then have random breaks so it isn't t
    
    
  • "Spider" - this enemy doesn't actually hurt you. They seek out coins and then burrow/hide with them. The only way to get the coin back is the use your digger tool on the block the spider is hiding in. If no coins are left in the level the spider with target the player and can steal coins. Spiders do not respawn when destroyed.
    
• New hazard/obstacle? - added "metal" blocks that cannot be removed with your digger tool. To top that off, they will actually cause your tool to backfire and shock/stun your player momentarily. They are easy enough to avoid once you learn the hazard, but as later levels have trickier layouts and multiple mobs (especially once they start respawning and multiplying)  you run an increase risk of being jammed up if not careful.
   

UPDATE 3.1

Grabbed a capture of the "Mitosis" in action.

UPDATE 3 (day 6)

Went back to a style that was closer to the previous. I like the crisper edges on such a small canvas. I didn't have as much time the past two days to work on this as much as I wanted. I spent what time I had working on the enemy AI routine.

In my previous pathfinding code, the enemy would just stop if no path could be found. They now go to the last known location. Because I don't allow enemies to drop from ropes, the AI has no path to the "island" platform in the GIFs above.

I also gave the AI the ability to climb out of holes - just like in the original game. So you will need to time your "digs" if you hope for the enemy to not climb out.

And finally, I worked on the "Mitosis" system (not pictured). What I came up with is when the stage loads, all free squares, minus a one square buffer around the room, are compiled into a list. The list is shuffled and fed into a stack. When an enemy dies, the top value from the stack is popped off and used to spawn another enemy (on top of the original enemy respawning at his original spawn location). When the stack is empty, we've reached our max. However, the likely hood of every making it close to using all the spots is incredibly slim.

I'm hoping to be able to give a decent push this weekend. I'd like to have the core game finished by Monday and just work on polish.

On deck for this weekend:

• Audio - I've started to include some sound effects. I still haven't found exactly what I'm looking for for music but will most likely be putting in some place holders this weekend.
• Second enemy design - not sure how he will differ just yet, but I'd like another challenge as you advance further
• Another challenge - I'm leaning towards a "metal" block that can't be dug out. This should be pretty easy to implement.
• Polish! (like, I'm not happy with my intro screen/menu, so I'm sure I will end up wasting enormous amounts of time tinkering and fidgeting with that)

UPDATE 2 (day 4)

I decided on a name. I also messed around with new pixels, but I think I may have gone too far. The one's above were supposed to be just place holders, but I think I like the feel of them better. I lost that feel in the latest design. Gonna play around some more and see what I can come up with - maybe find a happy medium. I only have two stages made, so I've got quite a bit of work to do making levels. The game is also entirely void of sound at the moment which I need to remedy. 

UPDATE 1 (day 2)

I was originally going to try to fit the levels into a 64x64 view, but decided it just wasn't enough pixels to work with for my taste. So instead, I went with 128 x 128 and have a camera. I like the "tension" this adds by not always being able to see where the enemies are. I think I have most of the game mechanics worked out. The enemy path finding took the longest - I don't have a lot of experience with platform path finding, it's definitely different than top down. I fortunately made my life much easier by not having a jump. Currently the path finding doesn't take advantage of the "world wrapping" - but I kind of like the end result.

KICKOFF 

I like the addition of the(optional) challenges - I'm going to see how many of them I can work in. I originally wanted to create a FPS in the vain of Wolfenstein or Doom, but decided it may be more work than I have time for. But who knows, I may change direction in a few days and attempt it anyway.

I'm currently envisioning a Lode Runner clone. It was always a favorite of mine back in the day. The main mechanic hits two challenges (Pacifist and Eco-friendly) and I'm thinking I would work in "Mitosis" by having the enemies multiply if they die - may turn out a little too chaotic, but am willing to give it a go. Not sure about the last two challenges. "Freak" wouldn't be that hard, but I'm not getting any ideas for "Yin-Yang" just yet. We will see.

I threw together a quick test of the platform engine. I'm also thinking about including world wrapping. The visuals are very crude at the moment. I should have  some artwork mock-ups and further progress on the engine later tonight.

We use Unity 3D as engine. A camera render to a texture target with the mandatory size (64x64) and we use a basic UI object to draw the texture to screen.

[03 August 2017]

• we start the project
• we are Blackbones and we are 3 (1 designer, 1 artist and 1 coder)
• the dwarf can walk left and right
• parallax scrolling

I'm making the game in javascript using Phaser. I'm creating the course using Tiled. If it goes well then I have some ideas for turning this into a full size game.

I really like the simplicity of 8x8 tilesets. So much quicker to make, yet can still be quite expressive.

https://sprvrn.itch.io/slowrez

Hi!

So here's my project for this wonderful jam. I'll try to describe my idea as best as I can:
This is a action plate-former, you can attack with your sword or with your bow. The controls are similar to a twin stick shooter game.

There is a "slow passing time" mode, so you can easily aim and firing arrow to slain your enemy while the passing time is halved by 2.

But it doesn't mean it will be easy! This will be a die 'n retry game style, so be prepare to be outnumbered by the swarms, fall into trap and .. well, to die a lot!

I hope to create a fast paced, fun to play game!

Progress

Day 1 (2 august)

• Player moves and sword attack

Day 2 (3 august)

• Player can aim and fire arrow
• Monster with limited AI
• "slowing time mode" triggered when aiming
• Drew some sprites for the player, a monster and some tiles for the map
• Display level from a XML file (edited with Tiled)
• So right now you can : play one level, kill a monster or be killed by the monster and retry the level (there's a lot of physic bugs)

Day 3 (4 august)

• Fixed some bugs
• Transition between levels
• Timer
• Reduced the tile  size from 8x8 to 4x4

Day 4 (5 august)

• fixed bugs zzz
• Cooldown added on time slowing mode
• Various features added...

Day 5 (6 august)

• Visual feedback
• Added mob spawners/turret
• Worked on keyboard and mouse controls

Day 6 (7 august)

• Added optional bonus to each level
• some level design
• I'm finally able to make gifs !!
• Best time per level is now saved
• Start menu + level select menu (with best time and % completion)

Day 7 (8 august)

• Minor fix
• Drew some levels!
• I messed up the UI scale. need to fix that D:

Day 8 (9 august)

• a few fix
• some new features
• still struggling with the UI
• 12 levels and one boss in total

Day 9 (10 august)

• changed the color theme of the game
• player animations
• a lot of bug fixed
• and level design...

Day 10 (11 august)

• some fix, as usual. I don't really keep track of what i've make now

Day 11 (12 august)

• Yay, bugs fix!
• Add a Pause menu
• Add sounds
• aaaaand the game is playable now!

So I came across the LowRezJam on Twitter and got excited - what an interesting challenge!! So I have decided to give it a go! This is my second ever Jam, so let's see what happens :) I'll only have about an hour a day to work on it, so not sure how good it'll be, but hey, should be fun!

Will keep a short Dev-Diary here, but will also randomly post on Twitter @IndieDevBateman.

Day 1 : Decided to join the Jam! Drew my first ever pixel art... It's not good lol. But I'll work with it!  This is Jack - he's going to be the player character. The game is going to be called The LowRez Dead. You're going to have issues with zombies. Play mechanics to be determined... The important thing I think about a Jam is that you try new things. So I plan to try for the first time 1) Pixel Art and 2) Path-Finding AI.

Day 2: Built the camera system so that the view follows the player in 64x64. Detail is going to be mega tough at this resolution, so things are going to have to focus on a fun mechanic. I think it's going to be one large map that you have to get across without dying, with kind of a Cannon Fodder meets Hotline Miami meets Walking Dead meets rubbish Pixel Art theme! Main time today was spent making sure the player moves around without running into boundary issues! 

Day 3: So today I have spruced up my character sprite taking inspiration from others who are obviously far better at this pixel art than me! Jack is now looking a lot better and has some basic move animations. I have also reworked the camera system following a change to the control scheme. As I like to make games that are playable on PC and mobile, my controls are going to be mouse based only. I've therefore ditched keyboard movement and built in some basic pathfinding. Now the player is moved around by left mouse clicks. Right mouse clicks are going to be for shooting zombies! Here's Jack making his way around obstacles during testing. Next up is going to be shooting bullets and starting to build the environment! 

Day 4/5: Started making zombies and got the basic AI ones complete. Jack can shoot them - and be killed by them! Also created some keys and some locked gates to pass. My pixel art sucks massively, sorry about that ;) But I'm learning and having fun doing so!! Next up, some chasing zombies and buildings.

Day 6/7/8: OK, so big update. The game is going well! I now have zombies that will chase you if you get close, buildings, rival gangs of men who will shoot at you, a halfway boss character, a story, and the map almost complete! So basically lots of progress!  Just got to create a final boss and add music. Then it'll be play testing and tweaking time. 

Day 9/10/11: I have added the final boss and music. Just trying to test it now to make sure it runs OK. The biggest challenge I'm finding is in making the AI a reasonable difficulty.  I'm either getting my butt kicked or finding them too easy... I hopefully will find a good balance. Then if anyone actually plays the game I can tweak on feedback :)

Day?: I have no idea what day of this project I am on, I think 12, but maybe 11. I need to work that out next time I do a Dev Log!! Anyway, I've made the game available. I think it's bug free but it probably isn't. Hopefully people will play and feedback any issues! My main concern is the difficulty. I can't tell if it's a good level or not... Again, if you play please let me know and I will tweak it! Now to see how it does in the Jam!!

Game Synopsis

The game has evolved into a top - down mouse controlled game, where left button moves you and right button shoots. You are Jack Times, and the zombie apocolypse has happened. Your food supplies are empty and you need to restock - by finding 10 portions of food! 

The game is played across one large map. It is one hit kill so if you die, you restart. A part of the game is learning the map as you die and restart - getting better each time. To access new sections of the map you must find keys to unlock the gates. You must also keep finding bullets  - ammo is precious. 

There are two bosses to kill, one halfway and one at the end - these are tough buggers. For those who like it and complete it, the run is timed; so you can try and beat your time / post your best time!

The game has been 100% completely made during the Jam time frame, in my spare time. Hope somebody likes it!! :) 

Oh dear... Time limitations and other projects have prevented me from continuing the Green Island project. I'm afraid I will never be able to finish this in time. I guess I probably aimed far too high for my available schedule.

Day 4... Already???

It's been 4 days already but only now I found a bit of time to start a development log. I'm trying to make a prototype puzzle platform game that I'm provisionally naming "Green Island". It's simply based on a character that moves around a set of floating desert islands solving puzzles in search for the legendary Green Island.

This was my first mockup that already includes the nearly current player character. This was before the decision to move to a more desert-like scenario. Then there was the decision regarding the main character... This was not easy due to the 64x64 limitation. Here are some examples of my attempts... Initially I was looking for a "prince of persia"-like character

But this was probably too large and elaborated... I also tried a flashback-like character:

But it would take me forever to make all the animations with my very limited art skill and it is also way too big. Next, I tried a variation of a character I found in OGA with a reduced size and made a few sprites for it:

Finally, the mockup decided that to fit everything that I needed in a 64x64 window, I really could not go any more than 5 or 6 pixel high character... Hence the last variation:

Here the animations are still very very unfinished. I'm now working on those as well as some dust support for the walking and jumping. The character colors are inspired by Omar Sharif's character in Lawrence of Arabia 1962 feature film though I do not want to include any form of violence in this prototype game.

But the main palette is nearly decided and I will start building the world in the game engine very soon. By the way, I'm using Godot Engine 2.1.3... Many folks are already trying 3.0 alpha but I don't think I will have the time to learn it for this jam... Maybe the next.

My first attempts using Godot with a 64x64 window faced some issues when I tried to use screen shaders for some effects. This seems to be a known bug with some limited workarounds. Anyways, I'm sticking to simpler shaders, such as cycling the clouds and such.

And this is it for now...

update... Added death by falling, respawning and some dust animations to support walking and jumping. Sorry for the mouse at the end...

Day 6:

Unfortunately, I've had way too many things to do that prevented me from devoting the proper amount of time to Green Island. For this reason there have been very few updates and I am starting to fear that I will not be able to produce a half-decent prototype of this game. Nonetheless, I will keep trying produce a few things towards the final idea.

I've been trying to introduce some active assets. In particular, the character will need to use a ropeway between islands. So I started making a simple one based on long ago ski trips. I'm still having serious problems with physics whilst the player is on the ropecar but I don't think I will have the time to solve them in time. I also added some particles  that move according to a randomly set wind variable, just to complement the environment. Not sure if they really work... I guess I have to let it sit for a while until deciding to keep them or not.

Finally... I'm looking for puzzles that I can implement on to the game. Since I'm now visiting my parents, I found this old book in my dad's library on the "Art of Wasting Time". Sorry about the portuguese title: "A Arte the Perder Tempo". Anyway... I found a few very simple logical puzzles that can be incorporated into games. So I'm going to try to use one or two of them.

Update:

To rain or not to rain?... This is my question. I have been thinking of using a rain effect I made for Godot some time ago. It works well at a (not much) higher resolution, as can be seen below.

However, the effect is not the same at 64x64. So... I'm trying to decide to use it or not. The whole idea of the game is to find the "Green Island", which is bathed by rain.

For details on the effect... It is based on the Godot infinite bubbles demo, adding collision to the bubbles. The rain drops are spritesheets, which run when starting, dropping, and/or hitting something. The scene is then composed by setting a series of collision polygons where the rain is generated and terminated without collisions as well as polygons to define the collision areas. If you are curious, you can find the details here: https://github.com/securas/raindemo

Anywho, I'm currently trying to make a somewhat minimalistic platforming. ^^; There's a few basic things you'd be able to do in the game, like collect keys to open doors, jump into enemies, and stand awkwardly close to NPCs to talk to them. So far, I only have a preloading screen and a the jumping implemented so far, but I'm always open to critique. ^^;

But those are tomorrow's plan, now it's break time.

Last night I spent time figuring out how to get Unity to render to the 64x64 grid (not pictured below but I got it working).

This is my first game in Pico8 and I'm loving it.

Next up I'll make some missiles\machineguns... I can't wait to get some nice mini-isometric art happening.

8/4/17

Quite a successful day of implementing the A* pathfinding algorithm, and instructing the little fellas on the finer points of digging. I should probably teach them how to drink beer next, or at least get them to fend for themselves a little. I got A* working, so how hard could rudimentary AI be...? :/

Going camping tomorrow, so no more updates until Sunday.

8/3/17

Currently have a tile engine working, with sprites, mouse interface, and a simple job system. The dwarves will take a task and execute it, and the only task right now is a request to move somewhere. It's been tricky remembering how to do smooth movement with a strict timestep, and keeping simulation logic cleanly separated from all rendering logic.

Next up is getting them to dig, and I suppose some form of A* or Djikstra path-finding would be good...

UPDATE THREE: August 10

Let there be lighting!

I got my asset issues sorted out the other day and re-unwrapped my whole little level. It took about 10 minutes instead of 3 hours! That's more like it. Yesterday I hacked in some lighting calculations based on this great tutorial, and it's starting to look much better. Now I need to start thinking about actual gameplay!

I also realised that my last two screenshots were almost entirely black on certain monitors. Using OpenGL's SRGBA texture format seems to have improved that a great deal - as has adding lights, since the scenes were supposed to be fairly dark anyway.

UPDATE TWO: August 6

I hoped I would have more to show off by now. I had little time to work over the last few days, but I wrote some basic camera movement so I could examine my environment in-game, and added fog to my basic geometry shader.

The first room in the game, complete with texture artefacts because of my unwrapping

Today I spent 3(!) hours creating a basic space to play around in. Most of that time was spent unwrapping the level onto my texture atlas. It's completely unscalable - I will hardly be able to finish one floor at this rate, let alone my planned 5. It's frustrating because I have a ton of cool ideas for content, and I need to move on to gameplay - but the environment is taking so long.

I think I need to write some code to split up my exported OBJ file by material, so I can rely more on UV wrapping instead of assigning each group of quads manually. Ditching the single-texture atlas (which I did because it's easier) would also improve the mip mapping.

A little further down the corridor

At this point my priorities are:

• Add lighting to vary up the level's appearance a little more and give it some shape
• Implement collision so I can walk around as a character, not a floating camera
• Sort out my asset pipeline issues

UPDATE ONE: August 3

It is Day Three and I have finally managed to render a wobbly corridor in OpenGL!

According to Toggl, it's taken me 6.5 hours to get this far. Hopefully the next 6 hours will be focusing on productive stuff, not wrangling OBJ files and framebuffers!

I decided that for this jam I wanted to learn how to use raw OpenGL. It's been eye-opening so far, but the feeling of control is pretty awesome. I wanted a language that was low-level but modern, so Go seemed like a good idea. Its go-gl bindings have been great; I can basically translate C/C++ OpenGL tutorials straight into my app with only minor edits.

The plan

CASTLEROOK will be an atmospheric walking simulator that may include gameplay, if I have enough time! I'm going for a dark-fantasy dungeon-world sort of vibe, but hopefully with a few surprises. My main inspirations are Arx Fatalis and Thief, and also the 3 hours I played of E.Y.E.: Divine Cybermancy. Killer pedigree, I know.

The to-do list for the next week is:

• Sort out the visual style, especially the colour palette. Shaders should be pretty simple
• Learn how to handle input, and work out some sort of physics engine
• Design 5 or so floors' worth of geometry (yes, you'll be venturing downwards, roguelike-style)
• Make a kickass logo

Looking again at the render above, the tiled floor now reminds me of this iconic shot from Stalker. Hmm...

UPDATE

Got some gameplay going. It is hack n slash. I'm planning to add some arrows and magic.

UPDATE

I just submitted Son of a Breach. My original goal was to create a tiny Multiplayer Online Battle Arena game, but unfortunately, I couldn't finish the online multiplayer in time for the game jam, so I submitted a single player demo version of Son of a Breach. I still plan to finish implementing all the original features down the road.

I exclusively develop text-based games with ASCII/ANSI graphics, and I'm usually a hater of Game Jams, but this one caught my attention. The reason I make ASCII games is to force myself to make something minimal and not rely on all of the tropes the video game industry has fallen into. This Game Jam takes all of that to the next level by forcing us to focus more on Game Play than Graphics.

So, since each ASCII character is already 8x8 pixels, the dimension of my project can only be 8x8 characters.

I tried making a room-based game. I went and made all of the art first, but no matter how hard I tried I could not think of a way to make a fun game out of it. I just ended up with a tiny apartment complete with TV, Toilet, Fish Tank, Bed, Stove, Sinks, and Fridge. Here's a screenshot.

I'd been making a run-and-jump game starring a horse the previous week and then I saw this Game Jam. I'll finish the Horse one eventually, but I shifted my focus to the jam. The horse was already 8x8 characters so I had to shrink it down. I ended up with a Capybara. I coded 6 hours straight until 5 in the morning, spent another 6 hours on it the next couple of days and ended up with this (excuse the size, I had to add the border for Twitter)..

It's called Capybara Capriole. I made a massive level for the main game, which I'm still trying to beat. Once you get bored with that though, there's a built-in level builder! I love the level builder because it only uses a single line of text.

I need to clean it up a little more, but it should be up by tomorrow (Saturday) night. I'm very excited to see what the rest of you come up with and what you'll all think of my title (and hopefully some of you will create and share your own level). This has been super super fun, and I'm happy the jam fell on my 3-day weekend.

===> Day 14 (14/08/2017):

It's been 14 days of work and, despite not having the time I was hoping for, I still made a decent demo.
On this last iteration, I added the death animation, modified the Enemy Wave loop (no longer dependent on time), balanced the Stars (Players' projectile), added multiple Weapons where appropriate (with configurable directions), added Glow animation when at maximum Charge, added an Expand button to the menu to toggle the screen stretching, added a Game Over screen and made Pickups "phase" in and out.
I also colored the sprites but kept it simple and random.

It's been 14 days of work and, despite not having the time I was hoping for, I still made a decent demo. The lack of Sound is devastating when I look at the array of explosions that the "Star" can do. But, I really can't dedicate more time to this project.

===> Day 13 (13/08/2017):

Finish the Migrations to XML Atlas,
Added the (Players) Star weapon which can be charged, circles in front of where it was shot and can be caught to recover its energy.
Fixed several issues with the Enemies, with the game now properly sending growing waves against the player. Also added the "Boss" enemies.
Time was truly of the essence here, I can't believe how many events (game-unrelated) kept popping up.

===> Day 12 (12/08/2017):

I've been quite busy, using whatever time I've had to work on the project.
Migrated most assets to XML Atlas (for proper collision bodies). Things got weird when I made one for the Gauge. It now shows a red background when the Shield is low.
Made a Group that is always on top for the UI and made the Score Counter translucent.
Added a simple Menu to get ready to add options.

===> Day 10 (10/08/2017):

Merged several Sprites (still have to figure out how to use different frames in bullets), Added new pickups (there are now +2, +4 and +6 variants). Created and used a custom "Micro" Bitmap Font.
Adjusted some Sprites and made the missing ones, there are now 6 types of enemies with 3 levels each. Of course, the Asteroids are the only ones that don't fire bullets.

===> Day 09 (09/08/2017):

Added Weapons to enemies and got them to switch Sprites. We can see from their collision Bodies (green square) they all have a big hit-area for now.
Players now get points for getting Pickups and shooting Enemies. I haven't used a Bitmap font because they gave me some issues but soon enough.

===> Day 08 (08/08/2017):

Made several Updates to get ready to track the Score. As usual, I updated the Sprites:

Improved the (Energy/Shield) Gauge, edited some Sprites and added smaller pickups (the small ones add 2 while the big ones add 6).
Both Energy and Shield are regenerated slowly.
Several Enemies now randomly cross the screen, allowing the Player to shoot or collide with them. I also defined the types/levels of those Enemies and what they shoot.

===> Day 07 (07/08/2017):

Sorted the Sprites, replaced and merged some of them.

Added some Sprites to the game, allowing the Player to shoot them.
Energy can be collected and will recover after some time. It allows the Player to shoot.

===> Day 06 (06/08/2017): New Sprites

Worked on several Sprites.

===> Day 05 (05/08/2017): Health

Implemented Health and Energy (as a single Gauge), making a little bar on the bottom.
The Player has up to 10 health and 3 energy, which can be tested by touching Enemies/Pickups
Uploaded the gifs I started making.

===> Day 04 (04/08/2017): Enemies and Pickups

Added the Pickup and Enemy classes/objects and added a few to the game.
Made a little game where touching Enemies hides the Player and touching Pickups makes them jump to another location. I also gave Enemies some basic AI.
I enabled Phasers body debugger to see each Sprites body (the green squares).
Learned how to render proper pixel art with Phaser. I was close but this stops Phaser from using half-pixels.

===> Day 03 (03/08/2017): Player

Started by splitting the Mockup into several Sprites, loaded the Assets and showed a Player ship on screen.
It gets blurry since the anchor is at its middle but maintains the expected result.

Also added mouse movement and, if you hold the mouse button down, the speed increases.
Not quite as Arcade-ish as I expected but it's a good result.

===> Day 02 (01-02/08/2017): Setup

(I saw other DevLogs keeping to a single entry so I'll do the same)

Surprise! Phaser is in version 2.8.3. I thought it would skip to 3 but it turns out they made a Community Edition. How hard could it be to use it? Enough to waste a few hours, and cursing over requirements.
I set the (Gitlab) Project up and the (NPM) Package.
Then I made some prototype Sprites, but 64x64 is really small so I'll probably have to rethink how I use those pixels.

Lovely isn't it? I put it to good use by setting up my Game and using a simple Scaler.
These 1-2 hour segments already taught me "If it works, don't touch it." One thing I'm not very good at, be it for better or for worse.

===> Day 01 (31/07/2017): The Idea

Before the Jam starts, I sketched an idea. This gave me a direction and motivation.
I'll be using Javascript and PhaserJS as I've had good experiences with them.
Of course, the 64x64 size helps as my time is limited and I want to make the whole thing myself. It's a great learning experience!

Edit: Updated the Sketch to include the whole thing and made it sharper.

I wanted to make a dungeon crawler and I decided early on to make the small screen a major point in my game-design.

What I ended up with is "Kame-Ra" a game where you (a turtle) fight your way through a monster filled sewer to reach the ladder to the next level. Pretty standard stuff. 

Here's the twist: As we all know turtles are pretty sturdy creatures, that's why when you get hit by an enemy you don't feel the knockback... the camera does.

You move the camera with the arrow keys and the character with WASD (little confusing in the beginning but you get used to it pretty quick). If your character ever leaves the visible area it's GAME OVER. It doesn't matter if it was caused by the knockback of an enemy, or if you just didn't pay attention when moving.

Planned Features (completed, in progress, canceled):

• resolution 512x512 scaled x8 to 64x64
• dungeon generation
• minimap
• amazing programmer art
• multiple enemies
• scaling difficulty
• animations
• turtle attack
• preorder bonus
• 40$ DLC

Here is me breaking the game by wearing tons of armor. Fixed now :D

So for last few days, I was developing this small (or not) pico8 game, inspired by Pixel Dungeon. Here is what I got working already:

• Movement and collisions
• Procedurally generated dungeon (it took so long to make it look well!)
• A few enemies
• A lot of items (potions, weapons, etc)
• Cool lighting
• Simple menu and other ui
• Music and a few sfx
• Experience system

So next few days I will spend on adding more content to the game (more enemies and items) and balancing that all. I also need to make some sfx.
Pico8 is an amazing tool, and I really love, how my game looks so far.

On the first day, we decided on a theme and came up with a Pokemon style game where you have pets that fight for you but with a twist - if all your pets die, you die/restart. So you would have to look after your pets and feed them, give them water etc... and take a pet with you to go and fight to get an egg to hatch to get more pets and so on... and Jacob made lots of cute designs for pets! 

At the end of the first day, I started work on UI and stayed up till about 4 in the morning. I made a menu system that acts similar to the menu in Pokemon but acts more like an inventory/resource manager - I tried to make it feel as immersive as possible as if your character in the game is actually interacting with it. 

On the second day, Julien made a basic environment tileset which I tweaked while he made a daylight cycle and  Jacob made the movement, collisions, and animations for the little pets and made them follow the player while we decided on a name for the game. OwO is what we came up with because the pets are so gaddamn cute! I continued to polish the menu system until midnight when I started work on the main menu and continued working on it until about 4 am. 

On the third day, I worked on making the menus look better and more smooth, Jacob has started work on A* for the enemy detecting the player for a battle/fight system and Julien is making a town tileset!

On the fourth day, I made a visual for the attack system where you can provide parameters for a fight cutscene we now have another artist (Ingram) on board making attacks and improving sized up versions of the animals we had because Jacob who was making the small cute animals is busy with programming gameplay. The combat is similar to Pokemon but instead of going into a specific room to battle it's an overlay that's activated when you take your turn.

On the fifth day, me and Jacob have joined our projects together and the attack system and menu are implemented in the actual game! Ingram is making awesome animations and pixelart for the attack system! Julien is sick so he hasn't been able to do much.

Here are some gifs :D

The main menu:

The inventory/"Interactor" system:

The movement / Combat system :

(sorry the gif is a bit ew)

Submitted! You can download today! https://alexandershen.itch.io/aswg-live

Day 4? Day 5?

Have some UI polish left and some additional sound FX to put in. CPU is a little tough right now, so will have to dumb it down a little bit in terms of the mini-game. There's also a weird split-second bug that happens from the lunging animation and initiating the mini-game. Other than that, I think I'm about done! 

Oh, and some option menu stuff (SFX, show WASD instead of Arrows for Player 1). Also plan on doing a small instruction booklet PDF in the size and style of old Famicom games.

KICK OFF

I'm a big fan of professional wrestling, warts and all. Decided it would be fun to distill some of the action down to this 64 x 64 game jam.

The game play is pretty simple:

Players move left or right in the ring. If they collide, a mini-game where the players have to enter a 4-key combination appears at the top of the screen. The first wrestler to do that scores the hit. Wrestlers may also lunge to gain a free hit, but are only allowed to do 4 per match. Wrestlers may also time a counter to the lunge, but timing is difficult and missing the counter doubles the damage done to you.

I've never done a devlog before so I'm unsure of how all this works or how much I'm supposed to say but for the most part I'll just be posting gifs of what's going on so far. I also may change the name, but Epsilon is what I'm going with for now.

But anyway, I'm making a first person horror game called Epsilon.

The game starts with you waking up in a cold and dark place, the Epsilon. With your only way out being a locked door that you don't know the code to. You'll have to set out collecting a series of notes to figure out the combination and get back to the door without running into any of the monsters roaming the Epsilon.

A preview of the game world.

You'll be able to run, dodge, duck & hide to escape the monsters that await you in the dark.

One of the barrels you can choose to sit in for an overly long amount of time.

Walking with camera tilt & dashing.

Sorry about the gif resolutions being so different, I'll be keeping them the same from now on.

And that's pretty much all I have to show off so far, started working on this a tad late but I'll get it done, thanks for reading.

I'll try to keep this updated with things I'm adding, so check back every now and then if you're interested.

You've hit my devlog for this weird game thing of mine.  If you check below this paragraph, you should see links to a variety of devlog updates - eventually, at least.  As of writing this, it's only my first day participating.

Feel free to reply to this thread, by the way!  That's part of the reason I'm doing links to the various devlog updates...other than the fact that I write a lot because I like the sound of my own thoughts.

I have an Imgur album up for more frequent, screenshot-based minilogs: https://imgur.com/a/SZueo

Devlog Updates

Day One - Link
Day Two - Link
Day Three - Link
Day Four - Link
Day Five - Link
Day Six (Postmortem) - Link

Super Micro Mini Game Design Document Round Go!

• Title: Untitled
• Codename: "Unnamed Space Shooter"
• Objective: Avoid the things shooting at you and make it to hyperspace!
• Aesthetic: Minimal/retro.  I love playing with glitchy retro effects, and it makes it easier to get going on a project when the required art work is lower.  The caveat is that, especially at this resolution, enemy designs and actions taken against the player have to be more obvious.
• Modes: Just one - GTFO!
• Story?: You are part of a human convoy traveling the stars.  When an alien attack squadron finds your convoy, however, you and others deploy fighters to engage them while the civilians escape.  Your allies have all managed to jump out, except for you.  Survive long enough for your hyperdrive to charge and Get The Frell Out of there!

With this game, I intend on hitting the following Jam challenges:

• Pacifist (Guaranteed): The player will not shoot anything at all.  Instead, the player is trying to run away from / through a swarm of enemies in order to escape the conflict.
• Freak (Likely): I'm all about being an ass randomly inserting difficulty spikes.  Plus, I can tie in my Mitosis idea as seen below.  Other ideas include an environment with set pieces that are semi unpredictable (randomized); the hyperdrive suddenly taking twice as long to charge; perhaps an enemy the player for enough damage will cause the player to maneuver left/right/up/down slower, making it harder to miss being hit.
• Mitosis (Likely): Either the player, an enemy type, or both will be able to split into two.  If it is the player, then it will be for "bonus points" as that presents double the hitbox for enemies to hit, and it will be temporary.  If it is the enemy, then...well, more targets to be shot by.
• Eco-Friendly (Unlikely): I want to attempt to add this in somehow, but I'm unsure how I'd pull that off.

This is my first work in the game. SimaoOldWest is the name of my game. Here is the main gun.

Obs: the JPEG pic create artifacts in the image. Next time I will use PNG format.

And here a background.

Genre: Construction and management simulation
A farm building game, grow crops and harvest them before they go out of season, hire more farmers and expand your farm! Been developed primarily myself and additional work done by 2 friends.

Screenshots:

Aug 07 -

I figured now that I've got a basic game running although not loop complete, I could show off a couple of shots of the progress. Pixel Farmer is a game based around the idea of running an expanding farm. Hiring farmers to increase your efficiency and handle more crops. Right now you can choose and tell your farmers where to plant crops, they will walk over, till the soil, sow, then water the plants. Every day plants need watering and you've got a limit window to grow seasonal plants so its a bit of a balancing act of how you use your time.

Still got to implement structure building and selling your plants. If there is still enough time left we're going to add farm Animals and if there is even more time left, using your crops and resources to produce products such as carton of milk or canned goods.

Its been really fun working within the constraints of the 64x64 window, coming up with artwork that is easily understood while not covering the screen with UI elements.

How did I forget to tell story! Ok, here we go:

This is modern version of Satan's story. Stan is a hardworking bussinesman who loves his job. He does great and he is right hand of CEO. But one day, Ceo decides t make his son, Adam, his right hand and promotes him to Satan's positions from nothing.

This is day 4 of development and day 5 of Lowrezjam and MAGS but I finally found time to post a devlog.

Actually Monthly AGS competition and Lowrezjam entries would be different but working on 2 games is not a good thing. So I decided to do as a suggestion, do 1 entry that fits both! So I am making a 64x64 res game with The Bible theme. 

Day 1: I made bedroom backgrounds. 1st one  is hardworking guy Stan's bedroom and 2nd one is unemployed Stan's bedroom. Poor Stan.

Day 2: I made entrance of Heaven inc.'s office building. Very green, very heavenly, but lies on hell's red roads.

Day 3: Did nothing much. Made a gui phone and thats it. But my art partner, CassieBSG, worked hard! She made 3D model of Stan and walkcycle of him. Since it is downgraded 3D model, needs a little polishing which I plan to make it at the end f day 4!

For same post with pics: https://horusr.itch.io/got-fired/devlog/6740/day-4-backgrounds-and-walk-cycles

[DAY 5 UPDATE]

Today is great as much as yesterday!

Yesterday I made a walkcycle and made 2 character out of it. Today I added 3 more character and I only need to make Eve and Adam.

I also decided to make more rooms, because making all offices into one room is boring and unnecessarily big. I put offices into different floors (someone sugested this great idea) and made a elevator!

Here is elevator gif, not updated version but only difference is smiling lips: 

[DAY 6]

Well, today was a little hard. I decided to make an elevator cutscene and started to draw an elevator room. With lots of  feedback, I managed to draw this in 2 hours:

It is back side of elevator and a mirror reflects front of it. So When I put characters, I needed toreflect characters also. But guess what? I couldn't make EasyMirrors mdule to work. So I throw that drawing to trash and decided to make cutscene with the other elevator. 2 hours for drawing and animating elevator dor and 1 more hour to draw that shine on glass effect. I don't know why it took 1 hour, but it took anyway.

For LOWREZJAM I plan to create some kind of tactical dungeon crawler.

The player enters a dungeon with a group of four mages. Every mage represents one element (fire, water, wind and  earth). The monsters inside the dungeon also represent the same elements. Tee mages can only kill monsters that belong to their inferior element (eg. The water mage can kill fire monsters) but they get massive hurt if they are attacked by a monster of their superior element. The player has to use the four mages wisely in order to recover the magic artefact that is hidden somewhere deep inside the dungeon.

Edit: As a little extra challenge I decided to use only 16 colors for the game art. (I use the beautiful Dawnbringer16 palette.)

Here is a first impression of the game. The video was taken today in the morning. The player sprite is a still a placeholder.

DAY 3:

Today I've  added a 'Mage selection menu' and changed a few tiles. Furthermore I manged to create a git-repo for the game. (Code:GPL3+ Assets:CC0).

Here is a new teaser:



Day 4:

Nothing to show for today. But I added some stuff behind the scenes. ;-)
Tomorrow I hope that I will able to add a UI.

Day 5:

Finally I made some significant progress today. I added a small UI with players LP, number of collected keys and total score.
Furthermore I've made some new dungeon features. Just look an enjoy. ;-)


Tomorrow I will try to add bad guys to fight against and maybe a save/load function.

Day 6:

Not much to show today. I only got half way done with the monsters. But hey, the life is about more then game development and my wife needs some atention too. ;-)
So far, I've done the pixelart and can spawn monsters on the level map. Tomorrow I will try to get the rest done.

Good night together.

P.S.: A little example of the monster sprites is here:

Day 8:

Today my monsters learned how to walk. Pathfinding isn't perfect right now, but good enough for now.
Here is a little example:


Tomorrow, I will try to add the battle system.

DAY 10:
I had no time to make another gif today.
But I made good progress during the past two days. The battle system is done and seems to work well. Now I only have to add a few more things (like a title screen) to finish my engine. I hope that I will be done until Sunday, so I will have enough time to create a few levels. I plan to add 3-5 levels with 5-10 rooms. The total play time should be something like ~15min.

DAY 12:

Today I was able to add several things to the game.
I made a little menu that comes up if the player press ESC.


Furthermore win and loose conditions have been added.


Last but not least I was able to add a few more dungeon features like teleporters and checkpoints.

Tomorrow I will try to finish the basic game by adding a few nice 8bit sound effects I've found on opengameart.org and by creating a tittle screen. The time that remains until the end of this jam after this I will use to add more levels to the game.

Day 13:
The basic gameplay is done now. I made a nice title screen and added some 8bit sounds. Now I have still 3 days left to create more rooms.
Tomorrow I will try to release a first test build.

Oh my, the codebase is a mess, but I'm getting stuff done wich is all that matter and it work just fine ;)

What's new:

• You can now enter the train and ride away with it
•  New carts behind the train
• the railway scales to infinity

HELLO!

Introduction:

For some reason I got really excited to work with fake 3d in a pure 2d world,
here's a gif of a test I did:

Pretty cool huh! ( Dinosaur and deer is from the voxel editor I'm using MagicaVoxel, I don't intend to use them)

Okay, so I need an idea... hmm, let me just make random models and see what idea's will spark after...
I have a Train, Deer, Dinasour, Tree, Flower and a Pig...
The train looks pretty cool...
Animal Express!

Gameplay:
Right now the basic idea is to capture animals in the wild,
bring them back to the train, then go somewhere.

yeah, it's not a complete idea yet, but it's a start...
Let's see what it evolves into!

Here is a gif of the current state:

Introduction

Hi.

My name is Callum, and I'm making a  game called Soluna's Secret. It's a first person mystery puzzler about light and darkness being developed in Unity with C#. Each day, I try my very best to update this post with the most intreguing news about my project. All in the hope that I have something to show before the deadline. Here goes nothing!

Day 1

So I'll be honest: I'm technically starting this jam three days late. I feel that this puts me at a disadvantage when it comes to the other participants, but here goes nothing. When it came to choosing the technology, I originally wanted to go with PICO-8 for the sake of variety, but after getting a more solid grasp on my idea, I felt that it would be much more economical do to it in Unity.

Are you ready?

Bam. After a whole day of work, here's where I'm at. Two cubes on some giant chessboard. Though this doesn't look very exciting, there's a little going on here than meets the eye. Most of it is framework and setting up project management tools to help speed things along, but some of it is in fact visual:

By looking at and clicking on the cubes, you can get them to display text on the screen. Sure the text doesn't display within the pixel grid as much as I'd like, and there are some other quirks with input I haven't worked out yet, but hey. It looks OK so far. Baby steps.

I hope for this to eventually give puzzle hints and small amounts of exposition.

There are also some interactable cubes as a different class, and graphics for a hand used to indicate such objects. These things all work but don't do anything visually interesting enough to warrant showing off just yet.

Day 2

I'm writing this segment prematurely, because I have matters to attend to that may prevent me on working on this at that time. Sorry.

                                                                                                                                                    ***

So yes, my entry has a devblog now. I'm very glad to have finally got this out for you to keep an eye on. New posts will be sent as edits to this initial post, as suggested by Jack. Be sure to let me know what you think. My sincere apologies if this has so far been rather awkward and self-depricating. I'll fix that at some point.

Bye.

Day 3

Third day in, and I'm just starting to get into the really interesting stuff. Most of my progress can be summed up in the following image:

Most of what I've done has involved improving the 'inscription' system and adding the really important thing: the Pilgrim's Lantern (working name). Represented by this lovely yellow cylinder.

I hope for the Pilgrim's Lantern to drive many of the different puzzles in Soluna's Secret. It's a magical artefact that burns without fuel, and it's light may have some interesting effects that I'm not willing to spoil. I've added a pickup for this item, which adds the lantern to the player's inventory when looked at and clicked. Right now, this exchange is one way, but I may consider letting you drop the lantern on the ground as well as toggle it on and off.

Any appearance that you can drop the thing from the provided image is just editing trickery.

Much of the code has also been cleaned up, but I'm sure you care little about something you won't see when it's done.

Finally for today, I want to mention a feature I tried to add, but didn't yet have time for:

Doors. What puzzle game, or game in general would be complete without doors? They're everywhere! Though I must admit: building them out of solid stone was a stupid idea. One that I'm kind of regretting, but hopefully will look much better once it's done. Until next time!

Day 4

You know... I learned something today. And that thing is that 3D modelling is much much  harder than it looks.

I'm, uh, getting there slowly. And no. I have no idea how this happened. It's supposed to be a lever, by the way.

Regardless, other improvements include better animations for doors, as well as the associated framework behind them to be expanded upon later. All in all, kind of a slow day, I must admit, but even though some of the assets aren't done, the individual parts - such as the tiles you see above -  are complete and saved, so I can always use them later.

This means that, fingers crossed, tomorrow will be more productive. Now before this update begins to look like an apology, according to this here hit counter, this thread just hit 100 views! Thank you so much. Hopefully I can give more exciting updates for you all in the future. Until next time!

Day 5

A much, much  better effort all around today, though I must admit that the ending was a little rubbish. Kind of like the film adaptation of Life of Pi, actually. Doors are almost finished, and I have added support for unlocked doors that can be opened and shut just by looking at them and pushing the 'Use' key to pry them open and shut. Complete with pretty animations! (Not at all diminished by the strict resolution.)

But enough of my perculiar fetish for increasingly functionable gateways, here's the thing you've all been waiting for:

The lantern finally has a purpose! Other than lighting your way through the dangerous depths of the tomb, the lantern's light can reveal hidden objects and make them tangable, or do the opposite, as in this example.

With this knowledge in hand, I hope this will lead to some very interesting puzzles in the near future, as very soon, this won't just be bound to how far away the lantern's light is, but also if it's on or off. Though unfortunately a few hiccups in the workflow pipline (or a flipping annoying bug to you non-marketing folk) meant that I couldn't get that done today. Something for tommorrow, one would hope!

Any feedback is most welcome. Until next time!

Day 6

I'm nearing the end of the first week, and I'm starting to feel the crunch. A lot of progress was both made and lost today, paradoxically.

Part of this comes from the fact that, while I have improved Soluna's Secret in a few rather significant ways, I have just come to the most startling realisation; I don't know how to texture models properly. And yet, somehow, I have made this:

That's the work-in-progress model for the Pilgrim's Lantern, sans handle. Would you like to know what it looks like in game?

Are you sure? Because this one's a doozy...

...That. 

It looks like someone vandalised the top of the TARDIS. I have done as much research as I can on this, and it turns out that making models for video games is not as simple as slapping the model together in the modelling program, saving the file, then dragging it into Unity. Oh no, that would be far too easy, and who doesn't love a challenge? Definitely not. Rather Blender (the program that I use for this sort of thing) has a materials system that was developed on the opposite side of the universe to Unity. They're 100% incompatible. 

Not to worry though, after you've swallowed your tears (and your pride) you learn that there is a solution. And that solution is done via the process of Baking and UV Unwrapping. Anyone reading this that actually does this sort of thing for a living probably just let out an uncontrollable shudder... Or not. I wouldn't know. I've never done it before. But the long and short of it is this: If I wanted to make a texture for a cube, I wouldn't draw like this...

I'd instead draw it like this:

That's because the computer needs to know what each side of the cube looks like laid flat, so it can do some maths in order to wrap it up again and draw it to the screen correctly. Now you can imagine that as models get more complex, the net of the shape will too, and very quickly it becomes unfeasable, so we need to turn to the computer once again to do it for us. A lot of software simplifies this whole process by allowing for texture painting. Literally, you can paint texture directly on the thing - kind of like airfix - which is pretty much what I've ended up doing.

The problem is when you have your model all painted up and ready to go, you need to blast it back to its basic bits for anything else to use it. This is where I am right now. Nearly halfway into the jam and I've found something I don't understand at all. Yet. Tommorrow will almost certainly be a crash course in this sort of thing so I can fart out all of the necessary assets as quickly as I can. and get on with building the rest of the game.

But enough of that, let's have a look on the lighter side. The lantern itself has seen some noticable improvement:

The lantern's light is now much more even; it's much easier to tell where it's influence stops. Initially, I fretted over this problem, and tried many half-hearted solutions, until someone pointed out that spot lights give off a much more even glow than other kinds of Unity light. This gave me an idea:

Instead of having the light come from the lantern, have the light come from the light. It's a cheap hack, but one I find amusing. Sure, it's nowhere near as drastic as flipping the whole game horizontally , but I thought it was cool.

In addition to this, switching the lantern on and off affects both Lunar and Solar objects. If I ever get this UV unwrapping problem sorted in time, I'm sure I'll have a better way to show this off soon.

Until next time!

Days 7, 8, 9 and... 10?!

It's been a long time. How have you been?

I've been just fine. You know, after I spent two days learning UV Mapping. I've been working my socks off to get as many art assets as possible finished  before the deadline in the hopes that I can go on to making some nice environments to walk through, if not a whole game.

I'm going to be honest with you and say that the odds of me finishing this within the deadline are starting to look slim. Never fear however, because even if I miss the deadline, I hope to continue on with this project until it becomes some form of  small prototype, at the very least. It's funny how something that seems simple can suddenly slip away from you into reams of complexity that you can never fully realise. Throughout this whole process I've been buzzing with ideas, many of which will have to be cut from the final product. Especially ones that require more art assets (I enjoy the process, but it's very time consuming).

Additional features thus far have been slow, achingly so in my opinion. To the point where this latest update doesn't really have that many improvements over the previous version in terms of mechanical content. This is entirely my fault for not finding my minimum viable product early, something I am usually diligent about, and also because this puzzle game about light, darkness, and a helluva lot of doors actually started as a Tomb Raider demake. I might write about this more in my planed postmortem after the jam, so stick around for that.

In that regard, I'm happy how much I've managed to do, and how far I've come. I could have given up much sooner, but I didn't. This fact comforts me, and looking around and witnessing the honest efforts of others really helps.

Now let's get down to specifics:

The lantern's light now flickers at the edges. Mostly an aesthetic detail, but the script is more than recyclable, so you should be able to see this elsewhere in the project. The rest, as previously mentioned are art assets. I have two planned features in the work to round out the core gameplay that I hope to have done soon.

The only really bad news is that I have more personal matters to attend to that will prevent me from 'jamming' tommorow.

My humblest apologies for the absence, and stay tuned!

Final Words and Release - Day Whatever

OK, so it's been a whopping 5 days or so since the last update, and a lot has happened since then. Soluna's Secret is now done, submitted to the jam and the response has been so far overwhelmingly positive. The game has received multiple comments, ratings, over 150 downloads, and has been featured on the front page alongside a bunch of different projects both big and small. Even though I only made a prototype of what could potentially be huge, this is a better turnaround than I could ever have dreamed of.

So this final post is mainly to announce that as of this day forward, this devlog is dead. Sorry.

I'll be sure to archive this somehow in the future, but for now, you can find all future updates over on the official Soluna's Secret page:

https://seajay.itch.io/solunas-secret

I want to give a warm thanks to anyone who read this development log, and I'll see you all real soon.

Day 1:

It was an otherwise busy day today, but I've had plenty of time to think on and talk about my idea with others and it's got enough shape I think. I've been playing with the art, which is generally where I start these days. And I'm happy with the look and style, and even managed to squeeze a full UI into the 64x64 space.

The game will be a mix of world building and town building. The player is periodically given a tile to place down in the world, these must conform to neighbor tiles but can otherwise be placed in any order. Tiles will slowly produce resources for you, which you can collect in your inventory. You can use the resources to create buildings (by dragging them onto a tile), or upgrade existing buildings (by dragging them onto a building). The most basic type of building is a house, and it is the base for most other buildings. Houses home a worker who will walk along roads to other buildings and help boost their resource productivity. And produced resources can be placed on tiles and buildings to discover new buildings. The aim is to allow free growth and a lot of experimentation.

As for code, I still haven't started a project yet. I fixed up some older code and fixed an issue I had in my last jam game where the keyboard didn't work due to the game being run in an iFrame (finally discovered window.focus()).

Anyway, here's my tiles and mockups:

Day 2:

I haven't got much to show for day 2. My GF has her first car so I've been out with her so she doesn't panic so much, and today we went to the zoo and I finally saw the bears there! Enough excuses. I have been working on the engine, seeing as I'm working in JavaScript without any libraries I'm having to write everything myself. Most of it is derived from previous jam games, though I've changed a lot so it's all consistent. All the basics should be in there now; game update/render loop, sprite and tile systems, audio, input, etc, so I can start putting the game together tomorrow. The goal is to keep the actual game code as simple as possible, my last jam game had about 3500 lines of code and I spent way to long just scrolling and looking for stuff. Ever since I first used Love2D, I've loved it's system of just creating/overriding the update and render functions, and they're executed automatically behind the scene, so my engine follows this system as well. Yes, I named the engine TOAST for the lack of any logical name for it. :)

Day 3:

I was out for ages again today, but managed to get some decent progress done. I started actually implementing parts of the game, rather than all engine work like yesterday. I included all the existing tiles and UI graphics, which I have to define manually from the texture sheet, as I have no system for doing that easily yet. So you can select the tile from the UI and place it into the world, and then shortly after a new tile becomes available:

And this next image is just to show how much of the project has been writing the engine versus the game. Hence why it might seem slow off the mark compared to my previous jam games! :) But I don't think it's going to be a complex game so it shouldn't get much more extensive than this.

Day 4:

Out all day again, urg. So I've only managed to create a camera/view system in the engine and apply that to moving around in the game. I don't plan to go out for long tomorrow (today was a 6+ hour thing), so the mission tomorrow is to implement natural resource spawning and building creation! That should start to make it feel gamey.

Day 5:

Brought some Steam games on sale today... So that was half the day gone. But I did complete my mission for today, which was to add in buildings. This meant some new engine stuff, such as high-level handling of grids (2d arrays) & adding layers to my tile system. It's set up so that you can only place buildings on the "dead-end" road tiles, this means that you have to more carefully think ahead when placing your road systems and other world tiles. My goal tomorrow is to add natural item spawning, such as wood, stone, wheat and metal, that will give the game some self-sustainability.

Day 6:

Still mostly gaming! >.< But I got resource spawning in. Works well, the only issue is that picking up a resource in the world is not the same as picking it up from the inventory, you have to place it in the inventory first to place it in the world... So I need to make them the same. And make it work for things other than trees. Then it should be all good. The plan tomorrow is to make buildings upgradable, should be easy enough so will likely get a few things done tomorrow, I hope!

Day 7:

OK, so I failed my plan today! I did fix a few things but was otherwise getting distracted (had to go shopping, and we ended up with kids round (and there's a drumset in my GF's sister's room right above my head, fun. + general girly screeching)). I have written up a to-do list however, and plan to get through that, there's some front end stuff in there so that should make a nice change at least!

Day 8, 9, 10:

I forgot to log a couple days because I was having to get up early. But I've made a fair bit of progress. I've now got a working main menu, created a font and the systems for drawing it, new buildings and resources, improved system for upgrading buildings, some animation (I didn't build this into my sprite system from the start, so I'm kinda hacking it atm.) While there's not really an objective to the game it's starting to feel fun, I personally am a fan of peace games, where you can just build and grow and experiment with no end. Anyway, here's my progress in a picture:

Day 1.5: I have a little teaser:

Possibly an homage to a film I grew up with. Also, I haven't done anything like this in years, so bear with me if this log is a bit unstructured.

Day 3:  Lots of behind the scenes work to make some actual game mechanics work and pave the way for more content. I do have a .gif to show off though!

Day 4: After much struggling with code, art and sound I have only a little to show for it. Pixel art is hard, man.

Link: https://github.com/Sindiewen/Lumi-The-Fairy-Witch---LOWREZGAMEJAM-2017

Trello Board: https://trello.com/b/oFmrEW4B/lumi-the-fairy-witch-lowrezgamejam-2017

Day 15 + 16: Crunch crunch crunch (8/14/17 - 8 /15/17)

Making games are hard. I've spend pretty much the past 14 days building the whole game logic, control and programming the game that I haven't done much with art, and building a level. I'm happy where my project is taking me because it's just a HUGE learning experience for me, and my future programming games.

I truthfully don't have much to update right now, but, tomorrow, Wednesday the 16, the project's due date, so i'm going to finish up what I got, make sure there is a way to replay the level when the player dies, and has an end screen. I'll also try to work in a title screen but no promises there.

After the game is posted, i'm going to start writing a small postmortem to this talking about my experience with this project, what i've learned, what I should improve next time and everything.

Day 13 + 14: Infinite loops and redoing of the art (8/12/17 - 8/13/17)

Infinite loops are painful. When you least expect it, they might pop up, and make unity crash and have you pull your hair out until you spend 15 minutes in the debugger isolating the issue. I was stuck with this for a bit. Mainly because when I created my brand new enemy type, a turret, it uses a co-routine to loop infinitely to check if the player is nearby. I forgot to add an else statement when the player is not found, yield return null. I added it and suddenly it worked! With that out of the way, object pooling is working, new enemy is working, and now, it's time to build a level. I'm not confident about this truth be told.

Remember the "Metroid 2" Issue I've talked about the last couple posts? It's really hitting hard here. I can't have enemies that come off screen to attack the player. That's not fair and cheap so I need to rethink this. Increase the camera ortho size from 4 to 8? Great! But my art lost all of it's detail and it's a blurry mess. I hate to say this, but I had to do 1 more revision of my character art. From it's original 16x16 art, I went down to 8x8. It's not too bad actually! This is a first, and it's kinda fun thinking your character in such a low resolution. The imagination that goes into art like this is amazing.

I added a new set of 8x8 sprites next to the 16x16 sprites. I've already implemented the new sprites into a new character prefab. I'm not getting rid of the current character prefab. I'll keep it for legacy sake. 

Tomorrow, i'm going to start building a level to play in with this new camera and sprites for the character.

Day 12: Enemy hit detection successfully works! The tweaking of the player camera and the basis of Object Pooling (8/11/17)

I'll start with the camera. Yesterday, the 11th, I've spent some time tweaking the camera system following the player. I have "Metroid 2" camera issue where it feels like the game is too zoomed in, thus making it hard to actually play because you can't see that far. I've done what I can without remaking assets to fit the resolution better. If I was given more time, i would remake the assets, but the project it due in less than a week, so I need to make due with what I got. I think i'll increase the Y boundary value so the camera doesn't totally shoot upwards when jumping. So far, i'm pretty happy with these results!

Next off, this took way to long to troubleshoot. Dealing damage to an enemy should have been an easy task, yet it has caused me the most trouble thus far. I can't have the enemy calculate the damage because the projectiles would multi-hit. It would hit 1 time per frame, thus creating the issue that the enemy would die instantly. Using an invulnerability timer didn't work well too. Long story short, i'm happy with these resullts! I have 3 enemy classes. EnemyBase.cs, which controls the enemy stats like health and damage. EnemyInputManager.cs controls the enemy's input manager, which uses the player's 2D controller as a base. Reusing this code makes this much easier to manage because the enemy AI class such as Goblin.cs will control the EnemyInputManager controling it's movement. The enemy will check if the player is in range and pass a value into the EnemyInputManager class and move the enemy. This works beautifuly. I need to start creating more enemies to fight now.

Lastly, i've been working on Object pooling. I want to avoid the Instantiation stutters when instantiating objects, so If I pool them in the beginning I can mitigate this issue. Everything that will shoot a projectile will be pooled.

TODO: today the 12th, I need to start creating more enemy types and start the groundwork for a level.

Day 10 + Day 11: Camera Trickery, raycast issues and wonky enemy AI (8/9/17) + (8/10/17)

Not much to update truth be told. I've bunched yesterday's and todays update into 1 because i've been doing the same thing these days. I've been slowly working on getting the player camera to be better to enjoy while playing. I've noticed my game suffers from what I like to call "Metroid 2 camera" where the sprites and the environments are huge compared to the screen real estate, thus giving off this "zoomed in" feeling the game has. I'm not happy with it, and I can't really fix it right now because that wold require redoing the art, and I don't have time for that. So to get around this is by making a more "dynamic camera system".When the player jumps, the camera is moving upwards gently. When falling and gliding, camera moves downwards. When standing still, You can look up and down around you. It's not much, but it works.

Raycasting and enemy AI has been the biggest hurdle here. I'm still working on a basic enemy that, if I can get working, the basis of all other enemies will be built too. All I would need to do is edit a script to give the enemy a different AI depending on what they do. Although, that's not even a huge problem. Thats alot of work, but this is where the fun starts.

Checking if the player projectile has hit an enemy and causing damage to the enemy has been stupidly finicky lately. Either, the enemy refuses to acknowledged that a projectile hit them, or the projectile hit them too many times in x number of frames to kill them instantly.  This is done using raycasts becuase this is just more efficient so far. I'm not happy with this, so I need sleep to think this over. Maybe i'm just missing something. If I can figure out how to "disable" the raycast for a frame, that would be nice. Maybe an invulnerability toggle?

Day 9: Animations (8/8/17)

I just added the ability to regenerate mana after shooting your magic, works like an ammo counter, you can't spam your magic. Although, Once i start implementing enemies into the game, I can figure out how to balance  the game specifically.

I also tweaked the animations a bit to make them a bit more smother. I'm quite happy how they turned out too! I also added firing animations so it looks more natural.

As of tomorrow, I'll have 1 more week before the game submission date. I'm falling a little behind regarding basic gameplay mechanics. I need to get enemy AI done tomorrow. I have an idea how to approach it too. If I reuse the current 2d controller, and replace the player input class with with a basic AI controller with raycasting to see if the player is within range to attack.

Day 8: Organization (8/7/16)

I didn't work on the project today. I needed to organize what to do next. I have a basic character, I have basic shooting mechanics, I have a way to deal and receive damage to the player and the 2D controller works wonders!

Today I decided to undertake life errands, then work on building a public trello board so I can truly get the ball rolling on what to do next, Linked here. I will put in priority what to do next for the state of the game progress.

Tomorrow, time to work on regenerating the mana bar and create basic enemy AI.

Day 7: Break day and a small bug fix. (8/6/17)

Late post, but I didn't do much work mainly as I needed to take a small break, but I managed to fix a bug that broke moving platforms. The reason why it broke is because i remade the player prefab and forgot to set the layer and the tag. The moving platform then didn't recognize the player just breaking it. Fixed though!

Tomorrow, Monday the 7th will be a dedicated break day to work on errands and to think about my next step in this project. I should really do a trello or github projects board for this so I can organize each step of the project.

Day 6: Lumi, The Fairy-Witch (8/5/17)

Her name is Lumi, she is half witch, and half fairy. She can use the magic from both sides of the magical realm of Faries and Witches. Her parents are from either side whom fell into a forbidden love, Lumi was their child. Because of this birth, both the Fairies and the Witches are becoming very hostile towards each other trying to claim her as their own.

She can control both magic from faries and witches, but she's lacking the proficiency in either. Her wand on her left hand and her hat act as a catalyst to control the witch magic, where as her wings and her bracelet on her right wrist allow her to control fairy magic by pulling the power from the land. Even though she has wings, she can't fly with them because of the lack of full control over them, yet she can flutter with her wings to glide down to the land slowly. 

I've though this idea as a way to think "How can I combine two different kinds of magic types together?" So I thought fairies and witches could go together kinda nicely! I spend about 3 hours working on her design above. I'm pretty happy with it considering I don't have much at all any formal art background. I really like how her design turned out. I can feel the cuteness of the fairies and the bright pastel colors, yet a darker side with her attire.

Heres a rough go at the sprite sheet. I need a good way to organize the sprites better. I'm not a big fan how it's organized. I'll work on that in the near future though. I have to thank Aesprite for being amazing spriting software, even for someone who isn't the best with art like me.

Heres some footage implementing a small 16x16 version of Lumi into the project. She looks pretty adorable like this.  And I love how she animates in 2d too! I'm pretty happy so far with my progress!

Tomorrow I might not get too much work done since i'm going with a few friends to see a movie or two. Best I get out of the house and get some fresh air. ALthough I'll try and update with a new feature at least

Known bugs: 1) When standing on a platform the player can sometimes fall through. I have a feeling this is relating to the gliding mechanics I added. 2) Animations needs fixing.

TODO for Monday: Implement a basic enemy for Lumi to fight with some rudimentary AI.

Day 5: Life errands and getting projectiles to move is hard. (8/4/17)

Errand day today! So not much done in terms of my project. Tomorrow though i'll work hard on the project.

I did though on my off time start working on the projectile controller for shooting projectiles. I can't seem to figure out how to after the projectile is instantiated, to push the projectile forward. I'll figure that out tomorrow though.

TODO: when projectile is instantiated, flip the sprite in the proper direction, and fire the projectile in that direction

Day 4:  2 Features that took too long to implement (8/3/17)

1 AM, and I didn't finish my todo list that I promised myself the other day. No basic character art, only a rough framework on implementing shooting projectiles, implementing a working health bar, and gliding. 

Gliding took way too long to implement as it would create issues with wall jumping. So after 2 hours of debugging, I just had to ensure that to initiate gliding, the player was touching nothing at all, which probably should have been the first thing I tried instead of creating bool after bool to ensure they can glide.

Getting the health bar to work took way too long too. I've never used raycasts this much before, so writing my own raycast controller to control player collisions with hazardous objects was tricky. Using a boxcast2d, I needed to create a collider box around the player that will only collide with a specific set of layers, and when it collides with a specific tag, I can use an if statement to chose what happens. Not elegant, but works well enough after I spent a full hour dealing with null reference exceptions with how raycasting works. I learned to always check if it has hit something, then check if it has hit whatever it needs to check.

Im happy though. It works. A working health bar, and a working glide. Maybe tomorrow (friday) I can implement shooting with the mana bar and a basic character to use. 

Time for bed!

Day 3: Programmer Art (8/2/17)

I got some basic art inside the game! At last, I can finally show off my programmer art skills in Aseprite! Jokes aside though, i'm happy to finally get some assets into the game so far. One small asset can do so much for morale! I'm supprised that even my basic of programmer art really helps out. I even started making some basic UI elements and projectiles the player will shoot. Even though I didn't touch any code today, the art helps alot.

Background - Tiles horizontally

Basic Projectiles for both types of shots the player will do. I'll elaborate in a very near future post on what this game will be!

So far, I'm happy with my art, but I'll work my hardest to get something that's much more prettier by the project's end. 

TODO for 8/3/17:

Tonight, start roughly drawing a base idea for the main character, implement the side scrolling 2D shooting mechanics, with a basic enemy to shoot at and kill, and can attack back. Implement the health and mana bar. Mana bar will deplete when firing your projectiles, but will replenish over a short amount of time.

Day 2:  2D Controller made, Now how do I render 64x64 good? (8/1/17)

My 2d controller works really, really well! I'm happy how well it works. All that needs to be done is to tweak the physics when that time comes.

So with my 2D controller made, I  suppose it's about time I figure out how to get the game to render at the 64x64 resolution that way when I start building my game, I can figure out how to approach the design and build it around the resolution. I have two options:

Option 1:  Using 2 cameras, main pointing at a quad with a render texture pointing to the game world rendering at a 64x64 resolution scaled up to a window/monitor resolution. Looks terrible, but it's technically authentic? Just though it's a blurry mess.

I don't like this option. It will work if I can't get anything else to work, but I'll do my best to avoid that.

Option 2: Force render the game to 64x64 and have you play in either a tiny window and use the windows magnification to play it at all, or scale up to your monitor resolution. This is a screenshot taken from the unity editor scaled up to 13x.

I think this looks great! Each pixel is exaggerated and looks authentic and retro. You could touch each individual pixel. Now the question is, how do I approach this look and so the player can increase the window size and still have it playable? 64x64 is such a tiny resolution, especially for our modern displays.

This is surely an interesting problem that i'll take a look at tackling tomorrow.  I wonder if I can find a shader to emulate the 64x64 resolution so the player can run at a usable resolution, but still have is look 64x64. Although I can see a problem with that already as many modern and widely used resolutions X and Y values do not divide evenly when divided by 64. I could just truncate the decimal, but then the resolution isn't right.

Either way, most importantly I'm taking care of this as early as possible. I feel this will be the hardest part of the project, so once I overcome it, the rest of the game will start layering itself onto each other! Well, Until I get to making art.

 I

Day 1: 64x64 is tiny (7/31/2017)

I opened up unity and set the render resolution to 64x64 to see what i'm dealing with here.

Wow, 64x64 is tiny. On my nice 3440x1440 display, it's just a tiny window. Scaling the window up is not hard, but that also brings in many other problems too. Scaling up you see lots of artifacting on objects where your square might have a extra "shaded" part of it on another pixel while the res of it is fine. And considering how small the window will be, I wonder how far I can go in terms of rendering the game before the game looks too small, or the character looks to big. 

I've decided to forgo physics based 2D movement and build from scratch raycast based 2D movement using Sebastiian Lague's 2D platformer series as a guide.  This will be much more precise and feel much better than dealing with the physics engine and it's quirks.

Today, i'm going to finish up my raycast based movement and start drawing up building up what the game is going to be.