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:
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.
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.
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.
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.
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.
Doing another game jam so didn't make huge progress, but I fixed a bug and started on the healthbar UI.
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.
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.
Set up a system for animations and sound. Made the movement a lot more smooth, added a walk animation, and footstep sounds.
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:
Mostly design work and some boilerplate code, but at least it was something. Also drew a snazzy totem.
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.
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.