Started 4 years ago (2015-01-25T08:00:00Z).
Ended 3 years ago (2016-01-25T08:00:00Z).

Trying to stick with a project?

Just post an image or overview of something you worked on, be it a:

-bugfix

-sprite

-feature

-polish

-anything

Showing that you in some way moved your project forward.

Do this, best case every day, but strive for at least 5 days a week.

Recent submissions (994 total)

A submission for Make games. 278

May try procjam this year, mostly just to give me something else to work on when I get tired of working on my nano. Getting set up with luxe. @Nico - any good tutorials? I did the first one and got a sprite on the screen, but other than the api the documentation seems pretty sparse after that.

Probably going to make some crappy roguelike.

I got halfway through #10, so created a water gun that shoots no damage. Started working on making the water drops explode when shot with the other gun, but ran into a bug where the water exploded instantly as it was shot out. So I just ran around with a self AOE explosion. Maybe good idea for something else but not this one.

I will keep trying to fix that bug tomorrow, hopefully finish #10 and move to #11 if I feel up to it.


A submission for Make games. 277

No one is safe.

A submission for Make games. 275

I've realized a slight downside to the gradiation in eavesdropping - I can't really rely on the game remembering what info the player has learned. It wouldn't be fair if you see a word like m_rd_r; and then are not given the option to inform your superior about the murder plot when it's obvious to the player what that word is. Similarly, if you only saw ___d__ and then WERE given that option, you would wonder why. That may be OK for the game I'm making, but another example of something that is really simple to build initially but increases complexity by several factors.

Being able to move around during conversation is another one of these "features". It's actually easier to allow the player to move during dialog than not. But those constraints are a standard in most games for a reason. They cut down on bugs and the possibilities for the player to attempt to do things that the designer did not factor into their creation.

Older games often had less well-defined restrictions for the player. Sometimes this made for some very cruel situations. There are many situations in the King's Quest games where the player can do something wrong, or miss something that they need and cross over to a new area they cannot escape from, and be stuck with no way to find a solution anymore. One example is in King's Quest 5, you get a pie very early on, that you are allowed to eat. But you need this pie later, so if you eat it, you cannot complete the game. Most modern games attempt to make these sorts of things impossible.

I want to allow them as much as possible - but without allowing the players early decisions to prevent the game from being completed. It just may not be the most satisfactory ending.

But in loosening constraints, even just a little, the potential for bugs, confusing situations, and players getting frustrated because they try something that SHOULD work but does not, increases. As I take a second look at this project I may want to add some constraints back in. It's a difficult balance indeed.

Oh, I should write an actual dev update... I added the fading back to dialog so that once you are outside of even eavesdropping range the text actually goes away.

A submission for Make games. 275

Targeting, abilities, all that jazz.

A submission for Make games. 274

I worked on the conversation system a bit. I'm not really happy with it both in concept or code - I might redesign how it works. Until then, alongside fixing some bugs where the npc ai would take over in the middle of a conversation; I've modified how eavesdropping works. Before, I was modifying the opacity of the textbox as you got further away from the center of the conversation. It worked well enough, but I felt like fading it out wasn't quite appropriate.

First, it's not always that clear whether it's fading as part of the normal animation of the textbox, or whether it's because you are too far away. Second, even if the text has faded a lot, as a player it is still possible to read the complete content of the dialog! That's not quite what I want. I would like there to be situations where either for stealth reasons, or because of the way the environment is situated, as a player you can pick up some of the dialog but not all of it.

So I've switched it to a letter replacement system. As you get further away from the conversation, more of the letters are replaced. At a certain distance, you will see no letters at all. You had better sneak a little closer if you want to pick up that important bit of information...

I've been on a cruise and focusing on other things for a bit, but came back for at least a day to poke around!

I managed to complete some small infrastructure refactoring. My map loading code is pretty crufty so I am working on cleaning that up. There was a small design flaw in that npcs had a hard coded layer on which they were rendered. I ran into the bug when I was adding some detail to the map and wanted to add a few more ground layers. With the hard coded player layer (say that three times fast!), these new layers were being displayed on top of the player instead of underneath. I'm now assigning the layer assigned in the tiled map file - whatever layer the player spawn object is on is the layer the player will be set to; and when using a map transition, the player will be set to the layer the map destination object is on.

A submission for Make games. 271

This submission is empty

A submission for Make games. 268

Added enemies and some basic combat. Also added a timeline editor. This lets me do a bunch of things that are helpful when designing new sets of waves, like seeing when enemies spawn, adding new enemy spawns by clicking, jumping around in the game timeline, etc. The totems (fire at enemies) and mushrooms (heal you and give you "mana") are working too.

A submission for Make games. 258

Doing another game jam so didn't make huge progress, but I fixed a bug and started on the healthbar UI.

A submission for Make games. 256

Refactored all the things.

A submission for Make games. 254

Added smooth texture transitions, which lets us supply two textures and an alpha channel to blend them with. It should make the environment more interesting. Also did the necessary work to support arbitrary resolutions and fullscreen mode, so there's that. Also added the capability to group things in the editor, which is going to be helpful as we add more properties to edit.

There was also a cool improvement to the editor: in the event that you put in a bad value (like the string 'SUPERFAST' for speed), it will revert it back to the original instead of crashing the whole game. It does this by immediately running the update loop inside a pcall with your supplied input. If the pcall barfs then it reverts the value you entered and flashes red.

On the gameplay side of things started on the shapeshifting ability. Mostly just getting the cooldowns/ability system set up, importing all of the minion animations, and making a simple UI for it. More to come on this later.

Also been violating a bit of the FRP stuff recently so I'll try to get that cleaned up and more organized over the next few days.

A submission for Make games. 251

Finally got around to putting in some placeholder art. Also changed the walk animation into something more limpy and added a stop animation. The stop animation makes things feel a lot better! Also added collision to objects. Basically objects push each other out of the way and gradually return back to their original position.

A submission for Make games. 249

Made a small panel that allows me to dynamically edit properties of objects in the game. It's pretty simple right now but it makes fiddling with numbers a lot easier. Either way it should come in handy.

A submission for Make games. 247

Ported over some of the old UI code to the new engine. The plan is to use this to make a small interface to edit levels or dynamically change the properties of objects during runtime.

A submission for Make games. 244

Set up a system for animations and sound. Made the movement a lot more smooth, added a walk animation, and footstep sounds.

A submission for Make games. 242

Progress on the new FRP stuff. Things are now organized into components that bind and unbind observable subscriptions to love2d events when they are created or destroyed. Additionally, each component has a 'state' variable which is an observable representing all of its state that changes over time and a 'props' variable which is just static data that doesn't change (somewhat inspired by the ReactJS framework). This is cool for a few reasons:

  • It lets us do functional programming on love events, which makes processing keyboard and mouse input really nice.
  • It lets us do some neat stuff related to object states. For example, a pattern we frequently use to render objects is to interpolate between its position in the previous frame and its current position to get a smooth transition. Normally we could set up two variables, one for the current position and another for the previous position, set the previous to equal the current at the beginning of the frame, and perform our updates. Using our new system we can express this more elegantly by just saying `object.state:pluck('position'):window(2)`, which will give us the position at the previous frame and the next frame without having to deal with any extra variables.
  • It also lets us better reason about values that change and values that do not change. This may come in handy later on, we'll see.

Art

A submission for Make games. 241

Worked on some totem art, we'll have different skins for all of the different totems in game.

A submission for Make games. 240

Mostly design work and some boilerplate code, but at least it was something. Also drew a snazzy totem.

A submission for Make games. 237

Did a bunch of sloppy prototyping for an MVP. Did some work to allow multiple people to play the game at once, each with their own controller. This should pave the way for local co-op. It also allows people to control our individual minions which is pretty neat. Another change I made was to heavily alter the perspective of the map to increase its depth, so now you can move up/down/left/right instead of just left/right. Also added a system for buildings and added a totem building that shoots nearby enemies.

Going to flesh all of this out more and see what's fun and what isn't.

Art

A submission for Make games. 235

Since we are adding depth to the game allowing for movement toward and away from the screen/camera rather than just side to side I need to adjust a lot of the art. We need to see all our characters from the back when they are walking away from the screen so I made the back perspective art today.

A submission for Make games. 232

Finished this effect animation and tried it out for Muju's blink ability but I'm not sold on it yet. It's supposed to be him disappearing into a cloud of smoke but since the blink is instant and moves him sideways I think I'm going to try creating an effect that has more of a horizontal motion like a dash.

Worked on an effect animation today, something I don't have a lot of experience in but I'm giving it a try. It's far from done, but I'm finished working on it for today. I'll clean it up, add more frames to complete the animation, and we will probably add particles and what not.

Loading more