phill
-
Content count
219 -
Joined
-
Last visited
Posts posted by phill
-
-
Yay, glad to see this one getting some love, I remember really enjoying it when I played through them all. Good luck with the remaining dev, myth!
-
01/04 to 07/04
Hello! I'm back for another short week as I'm heading back to my home town for a much-needed holiday for most of my off-time this shift. Also I've moved into my new house, so there's going to be a lot of time spent organising things and determining just where everything should go. I think I may have three, possibly four days to work on this before I jet off, so my goals will be correspondingly modest. Also by gosh it's bloody hard to get back into this project after a couple of weeks of not touching it. :/
My one and only goal for this period will be to put a basic structure of the outer loop into the game, including a win/lose condition so that I can really begin knowing the boundaries of the game and working to expand them. It'll be something like what I wrote up in my last review post, but obviously much more simplified to just get it in there and working to be able to test it. With the short amount of time I have I think that's more than enough!
-
10 hours ago, Dewar said:When I load the puzzle I'm actually switching the buttons into reverse and the computer is pressing a bunch of random buttons, more if the difficulty is higher. This ensures that whenever I add a feature, the puzzle is consistently solvable as long as I add a reverse step.
Nice, that's really smart. And also why I'm totally disqualified to make puzzle games if I didn't even see that as a solution!
-
Hey, I've been meaning to comment on this as I've been following along. I was wondering how you're making sure that each puzzle has a complete solution, especially with the broken/shorted keys? Or is it intrinsic to this particular puzzle type that there's always a solution, it's just how long it takes you?
Anyway, looking good, and your productivity kicks my butt!
-
11 hours ago, Dewar said:So, when you bet a certain number of buildings, that number of foundations are instantly built and, if you can't finish them, you get penalized. What happens if you under-bet? You simply can't build any more that day because there are no foundations left?
Hey, it's my chemistry bud! I think that would make sense, yeah. I'm also aiming create an exponential (or maybe not exponential, but certainly accelerating) destruct-o-meter for how badly the drunken mob will kick your buildings' butts/structural integrity. So while under-betting is safe in the short term, in the long term you'll be undercutting your ability to deal with the damage that the mob is putting out. That's kind of where the rogue-like element will shift into gear; players that aren't able to use their waves effectively will be able to prop that up with buffs that carry over between jobs, they'll just take longer to get to the end game than someone who is good at betting and being efficient in combat.
-
1 hour ago, Rilen said:Nice! Very "Cart Life".
I (somehow) hadn't heard of Cart Life, and now I know what I'm going to play next week.
-
23 hours ago, Rilen said:phill, have you considered making the drunkenness another thing the player has to make a decision about? Ie you somehow affect the drunken mob, either through pay or placement. Like, you could choose to put out a keg/kegs at the end of the night for worker satisfaction, and that would give you a higher percentage chance of the mob starting at that building, or of spawning different building effects than a mob spawned by unsanctioned alcohol.
Yeah for sure! I'm glad you went there (and it means a lot that you spent time thinking about it and typing it!), because part of the interaction between the middle/outer loop is that I really want there to be a lot of itemisation/upgrades/things the player can use their cash to buy. Ultimately I want to ride that tension between making things easier (or possible at all) in the short term versus easier in the long term (through persistent upgrades). It'll hopefully suit the looped narrative too; I have a vision of the 'between jobs' section (i.e. you failed and the minesite got destroyed) being our hero sitting on the couch and drinking beer and the pile of upgrades in the form of terrible bogan shit, slowly stop-motion-disappearing as he has to pawn it off.
-
11/03 to 15/03 Review
1. At least one new enemy as per the two designs I mentioned in previous posts.
I didn't do this, but it's okay! So it turns out I'm bad at not getting sucked into high level thinking about how my game will operate. With enough-for-a-vertical-slice bits done for my inner and middle loop, I kind of got stuck into thinking about how my outer loop would operate. The more I thought about it the more I realised that the outer loop will affect how I implement enemies, so I decided to do more of that.
2. Map out how to structure the outer loop of the game, i.e. bonuses, worker scaling, building and destruction loop, etc.
I thought a lot about this! I spent a lot of time sketching out various systems that I could use for the outer loop. Eventually I came to one that I think might work as a first draft, I'll give an overview here (in spoiler tags because it's long):
SpoilerDAY
Before day starts:
- Player receives per-day salary based on number of buildings that were completed and not completely destroyed overnight.
- Player bets on how many buildings they can complete extra to the schedule (i.e. 1 building required, player bets 3 extra buildings) before day starts.
During day:
- Player uses the number of waves they have to try and complete as many buildings that they’ve bet on as possible.
- If you perfectly use a wave (TBD what this means) then you get a refund on that wave.
- If the player has waves left over, then they keep some fraction of them for next time (is this enough punishment for not playing optimally?)
When day is complete:
- Player gets completion bonus for any buildings they completed.
- Player gets penalised for any buildings they didn’t complete.
- Player gets extra penalised for any buildings that have remained incomplete for X days, increasing daily.
- Player also kind of gets penalised for overbetting, as all buildings are able to be affected by mob.
NIGHT
Before night starts:
- Player decides which building they (and, later, their hired help) will sleep in.
During night:
- Buildings are affected by drunken mob.
- Player’s building (and, later, player + hired help buildings) is immune to mob.
-
Mob can do a bunch of random things to buildings.
- Deal damage;
- Place environmental hazards in it;
- Add enemies that are not workers and can’t be used to build;
- Increase level of workers;
- Mob additions stay until the building is completed.
- If a building is destroyed, player loses income for that building the following day.
- If a building is affected by the mob in any way, it automatically gets added to the must-do schedule.
The aim for this is to feel a little bit like a worker placement board game in between rounds in the arena. Anyway! I'm going on to shift tomorrow so I'll be taking a break until the end of the month (and possibly beyond as I have recently bought a house and need to do IRL stuff there).
-
10 hours ago, infamous space turtle said:Lol what if the mini bosses were workers union representatives/osha inspectors.. a game about workplace standards violation. For real though nice progress thus far
. I think finding a way to motivate yourself is crucial and it seems like you've cracked it. Looking forward to see where you take this.
You're pretty close to the main theme actually! I want to theme it around a series of mine sites/construction yards whereby the workers are used to build the different buildings. Then they get drunk and smash things up overnight! So an inspector type worker is definitely something I've considered and actually have some mechanics written down for it.
Thanks for the support mate, I really appreciate it! As I said in the post up there, my town (Darwin) does not have a lot of gamedevs in it (none other than me, afaik) so this is basically my community atm. <3
-
On 06/03/2017 at 11:36 AM, Korax said:I've done so much side stuff that the main quest branches open to me now are level 14 and 15, and I'm level 41.
I'm well on my way to doing the exact same thing. The quests available to me at the moment are level 15 and 18, and I'm level 30 or so. The main storyline is actually quite well-written and revealed; some of the threads that I thought were going to be obvious reveals turned out to go in a completely different direction. Refreshing to be surprised by the story. The side quests remind me a lot of the way that Witcher 3 gave you a lot of 'grey' situations. Even if there are no real choices in the side missions, they tend to twist a little.
-
11/03 to 15/03
Shorter period as I'm going back to work, so my gamedev will go back on pause while I'm on shift.
Goals:
- At least one new enemy as per the two designs I mentioned in previous posts.
- Map out how to structure the outer loop of the game, i.e. bonuses, worker scaling, building and destruction loop, etc.
-
What are you using for your animation recording? It looks like there's some weird scan lines coming through which I would assume aren't intentional? If you're looking for a program to record your screen, try either gifcam or ShareX. They're lightweight programs that can record regions of your screen really easily.
Other than that, looking good! My partner (who can art) says values are hard and that it takes a lot of practise to get pencils right, but you're off to a good start.
-
Sounds cool and creepy! Love a good C'thulhulian tale.
-
On 03/03/2017 at 3:54 PM, Travis said:Sorry to hear you were having a rough time, but it seems like you chilled out and have recovered, which is good. Making more progress!
On 08/03/2017 at 8:43 AM, theschap said:There is a lot of depth mentioned above and I am very curious to see things come together. I am enjoying watching things progress thus far. I hope you are feeling good and that things are working out.
Thanks guys <3. I really appreciate the comments and support, means a lot when I really have zero people in my town that do this stuff. This and the slack are my gamedev community, as cheesy as that sounds!
Review 04/03 to 11/03
Goals
1. Finish up the arena select/arena creation/arena stats tracking system. This may take a while as I try and find the best way to at least attempt to future-proof it.
I did this! Here's a video the day that I finally cracked the code on the system:
And here's one where I implemented it back into my main project file so that I could use a player rather than the power of imagination:
I was going to take that first video out, but I kind of like how it shows the before and after of a framework and then that framework as put back into the actual game. I think it's a valuable lesson/thing to keep in mind for me as a fledgling gamedev.
2. Work on at least one new enemy as described above.
I didn't do this! This is now priority number one for my next few days before I go back to work. It'll actually be nice to go back to trying to program behaviour after the more database-y stuff I've done over the past couple of weeks.
-
Review 23/02 - 03/03
This wasn't the best week in the world. I went through some serious self-doubt and general depression, so ended up spending a lot more time watching Netflix and playing non-competitive games than I did actually coding. Anyway, I'm feeling a bit better this week, so hopefully I can turn some of these yellows and reds into greens.
Goals
1. Develop a state machine for a new mini boss-type enemy that takes a couple of hits to become able to be thrown.
I didn't do this! I came up with the pseudo code, but then I kind of got lost in the other goals, so I didn't end up coding him up. I'm going to make this the first priority after I finish off the next two things, since I'm kind of deep into them.
2. Work on the player-driven spawning system as described in my previous post. This will probably take a bit of mucking about to make it future proof (e.g. handling the addition of enemies to the pool of possible enemies, scaling, etc.).
I sort of did this! I have implemented a system that the player can use to spawn waves, and those waves are made up of a pool that can be accessed and changed by other systems. But it definitely doesn't feel complete without the outer loop to make it more interesting. So I'm claiming a half-victory on this one.
3. Work on outer loop by creating an arena select, and putting together a few slightly different arena layouts.
I sort of did this! Goodness but did I get stuck on this. I pretty quickly complete the arena select, but then I got stuck thinking about the future in terms of how the arenas would retain their attributes. I don't know why it stumped me so badly, but I still haven't fully sorted out everything. I think it's because I got a particular idea of how to do it, which wasn't the most ideal, and I kept trying to hammer that instead of backing up and retrying with something different. So that's my main goal for the next week.04/03 to 11/03
Goals:
- Finish up the arena select/arena creation/arena stats tracking system. This may take a while as I try and find the best way to at least attempt to future-proof it.
- Work on at least one new enemy as described above.
Goals scratch:
-
-
-
Looking great bigjko! Puffinw as definitely one of the stand out games as far as visual impact went. I couldn't believe how good it looked when I played through it! Really pumped that you're going to put some substance into the game, I think it has legs!
-
23/02 to 3/03
Goals:- Develop a state machine for a new mini boss-type enemy that takes a couple of hits to become able to be thrown.
- Work on the player-driven spawning system as described in my previous post. This will probably take a bit of mucking about to make it future proof (e.g. handling the addition of enemies to the pool of possible enemies, scaling, etc.).
- Work on outer loop by creating an arena select, and putting together a few slightly different arena layouts.
Goals scratch:
Mini boss:- When hit by other workers, does not lose momentum, just adds emote (of some sort) above head.
- Has a number of hits before becoming stunned.
- When stunned, player can pick mini boss up (can't be combined).
- Maybe the type of enemy that player uses to stun can influence end result of mini boss damage? e.g. if mini boss has 3 hp before being stunned, 3 different enemies gives him more overall BP damage than if 2 different types of enemies used.
- Slow move + full-screen cross as an attack hitbox.
Spawning system:
In idle state:
- Start with a static pool of points that can be spent on spawning.
- Check if there are enemies in the room.
- If there's not, when the player presses spawn button, move to spawn state.
In spawn state:
- Empty pool points by spending them on enemies and putting them in a 'to spawn' list.
- Run through the list and spawn the enemies in the level.
- Decrease the player's number of waves to generate by one.
- Go back to idle state.
Arenas:
Create level select map where the player selects which building they want to enter and try and build (thinking something like the overworld maps from Mario/shovel knight).
In level select, show BP required for building to be complete, enemies that spawn there, and any other relevant stats.
- How to do this though?
- Overall controller object that is persistent through rooms, keeps track of stats.
-
Review 09/02 - 23/02
Goals
1. Come up with a new enemy
I did this! I've got some pseudo-code for a new enemy that moves based on triangular movement paths, and moves differently if the player is dashing or just walking towards them.
2. Figure out the building system
I did this! I figured that I want to have enemy (worker) waves be one of the currencies of the game. The player will be incentivised to use the fewest waves of workers to complete a building so that they can use any saved waves to complete other buildings. This has had implications on a few other mechanics (which I'll detail in my next post), but I think it's a fairly elegant solution to the problem of how to get players to focus on combining enemies and using the mechanics of the worker/building system without feeling rushed by something like a time limit.
- Worker waves are one of the primary currencies of the game.
- Players have X worker waves per 'day' to build up as many buildings as possible.
- Each building is its own arena that the player selects to enter and build up.
- When a player enters a building arena, a set of workers are spawned on a button press.
- The player can pick up and throw workers at the building to build it.
- Each worker is worth a certain number of building points (BP) scaled to their base difficulty.
- Combining workers by throwing them into each other is the way to build up scaling amounts of 'building points' or BP.
- Need to introduce a stun system to help facilitate this.
- Can also have a bonus combination of workers that represents a large number of BP but is difficult to pull off.
- Either can have this be lock and key (a bonus requirement that is guaranteed to be in each worker wave) or be free form/procedural.
- Also need to consider what the motivation for buildings will be.
- Perhaps there's events that occur between each shift (a horde) that come and destroy things or don't based on what has been built, and the ultimate goal is to get to some goal of completing all buildings and repelling the horde entirely.
-
This could be the workers getting drunk and rowdy during the night and wrecking everything.
-
Progression could be that you start at a really small mine site, and they don't break that much. So the player only has to be a little efficient to get the mine complete.
-
Work your way up to a massive minesite that has heaps of different guys where you can't waste a single worker, must combine everyone to survive.
-
Roguelike elements where your BP damage can go up for certain workers, or you go through 'training courses' that allow you to combine certain enemies together that you couldn't before.
-
Balancing this so that the slip into it being out of control and nigh on impossible to fix everything (and maybe being impossible, but the player is able to build up over roguedeaths) will be really interesting.
Now I just need to figure out how player health/death fits into all this. I'll be making that a goal for the next week.
-
Hey Trav, this is looking really great. To me the bug glint definitely suggests movement of a tiny thing more than your item glint, so I think you've nailed that one there. I'm really looking forward to seeing where you go with this, especially with the little exposure to the story with the chess piece up there. Great stuff!
-
09/02 - 23/02
This is a longer period, as I'm going back on shift at work. I work pretty long days so afterwards I'm usually knackered so won't have much in the way of energy to work on gamedev stuff. So I'm going to set myself some more manageable/idea-driven goals rather than coding. Then hopefully when I'm off shift again I'll have some pseudo code straight in my head to just jam out.
Goals
1. Come up with a new enemy. At the moment I'm thinking about a guy that avoids your dash by zigzagging when you try to dash at him, with a cooldown on the zigzag. It'd be a neat little thing to try and calculate when a player was dashing near him.
2. Figure out the building system. I want to try and figure out exactly how I want to incentivise the player to be efficient. Whether it's by bonuses for throwing multiple enemies into the building at once, or by doing it in a certain order. I don't just want the player to be able to throw each enemy one by one into the building without any requirements if they want to get the best result.
-
Review 04/02 - 09/02
Goals:
1. Improve jumping enemy
I did this! I ended up going with the idea of making the jumping enemy not collide with any obstacles during the jump. I'll have to make sure that I keep an eye out on any mechanics that I add that can mess with this. At the moment it's fine because he will be jumping to a player position every time, and the player can't be anywhere 'illegal' (e.g. inside a wall). But if I start doing something like spawning in obstacles, I'll need to do a check on landing in the case that between starting the jump and landing, an obstacle is spawned at his landing point. Overall though, happy with the behaviour and the dynamic that it introduces to the player movement:
I do still need to work on their behaviours a little bit to try and catch situations where they are all jumping at the same time and/or landing on the same point. Otherwise with my current position handling you end up with weird-looking behaviour like this:
---
2. Enemy spawning layers and timings
I did this, sort of! I've got a fairly simple system going wherein I have a pool of points and spawn enemies at set locations. But it seems a little too specific. I'm going to have a think about how to properly structure the pool of points so that the player isn't seeing the same enemies each time, like different ways of weighting enemies when they haven't made an appearance for a while, how to ensure certain enemies are included after wave X, and all that jazz. It's a strangely fun thing to think about. Anyway, here's me resetting the game to see what results I get:
-
04/02 - 09/02Shorter period this time as I go back on shift next week, so I'll be completely unable to work on anything for two weeks from Thursday the 9th. I'm going to adjust my goals accordingly!
Goals:
- Improve jumping enemy to deal with obstacles between start and end points, and also give him an AoE effect on landing to make it a bit more tricky to dodge.
- Enemy spawning layers and timings.
Goals Scratch:
Jumping enemy:
AoE attack is fairly easy, I'll just check if the player is within a radius of the landing point and switch the player to their 'hit' state if they are. At the moment, the jumping enemy can collide with obstacles if they are in the way of the direct line between the enemy and the player. It looks really weird because even if the obstacle is, say, 32x32px (e.g. not apparently 'tall' enough to stop the enemy jump) and the enemy is halfway through the jumping animation, it'll collide and slide off in either the x or y directions. This also mucks up the calculation of the ending of jump animation, making it so it does not line up with the actual hitbox: http://imgur.com/OY6oyAg. So either I have to basically just say that it'll never collide with obstacles during its jump (which may end up looking weird, I'm going to have to test it) or I have to figure out a way of sorting out which obstacles it should be allowed to jump over. The latter will probably be pretty tricky and involve some depth calculations, which should be interesting.
Enemy spawning:
The basis of the game will be throwing enemies into buildings, within mini-arenas. So I need to make sure that enemies spawn in a reasonable way, so as not to completely overwhelm the player, and to make the gameplay a bit more interesting and varied. I think the best way to do this would have a pool of enemies that the arena can pull from, each worth a certain number of points depending on their difficulty. Then for each wave, the arena makes up a new squad of enemies with a max number of points dependent on a difficulty modifier (TBD how that would be calculated). So I'm going to make a start on that kind of system.
Building System:
I'm thinking a bit forward on this one, as when I was writing out my system on the enemy spawning I started thinking about what kind of spawning I actually needed? In terms of player incentives and how to make combat something that can be nuanced, rather than just kill all the things. So here are some scratch thoughts on a system so that I can ask people's opinion at a later date:
General building/arena system:
- Each arena will have one building(/objective.)
- This building can be made up of different sections, but a basic version would be an object that takes up the entirety of the North side of an arena. More advanced/interesting versions could be buildings that occupy different sides of the arena as a function of time, or weak points that open after fulfilling a requirement.
- The arena's Building has a HP that needs to be filled.
- The player fills this by throwing stunned enemies into it.
- Each enemy is worth a certain amount of HP, dependent on their difficulty.
- Enemies spawn in waves.
- There is no time limit, but there is a meta variable that determines how many waves the player can face per overall day (day/night progression cycle is the outer loop). So the player is incentivised to be efficient with their combat and not kill too many enemies, but use all of them to throw into the building.
phill makes a game
in Game Development
Posted
01/04 to 07/04 Revision
Quick revision time! I ended up not being able to do basically any coding since I left my laptop charger at home and in general I don't spend my holidays holed up coding. I spend them holed up playing my new Switch with Zelda. Since everyone I know is working up until the Easter holidays, I have instead been able to do quite a bit of Deep Thinking about how I want my moment-to-moment and outer loop to interact to produce meaningful decisions for the player. This will be the last wordy post before I actually start diving back into the code to render some of this as gameplay mechanics, so hopefully this time next month I'll have some interesting gifs/vids to show. I'll spoiler it too, so there's one more barrier between my shoddily thought through mechanics and people's eyeballs.
So after a lot of thought and a bit of play testing, I decided that I needed a mechanic that would give the player a bit more space and time to be tactical, while still providing an action-based system. To achieve this, I'm going to be introducing an extra state for the enemy to be in: the stun state. Here's the scoop:
Introducing this mechanic also means that I now have the...means to provide another source of tension to the player in the form of how they 'spend' each enemies' stun HP.
I do not expect this to make sense to anyone else, since it's kind of impossible to explain all this without moving pictures. So that's what I'll try and get done for next time which will be around the start of May. See you guys then!