I found a thing someone had written about how NES Dr. Mario generates the game board and an idea for a better way to do it, which was useful. I did end up with a board generation method that could make a board that is completely missing a color, so I just made it make a new board if it does that.
Timely 😣
Also, that looks really good! Did you do the sprites yourself?
Yes, I did the sprites myself, though this is close to the extent of my artistic ability.
Fun fact: The white highlight on the pills is a separate sprite. The sprites are white and multiplied by a color. Since that method wouldn't allow bright highlights I did them as a separate row in my sprite sheet and just draw them on top of each other.
Listen, none of this stuff is as important as diagrams with lots of arrows that definitely make sense and are accurate.
But perhaps it needs... more arrows??
The first prototype is done; it's starting to feel kind of like what I want I think? It only works with a controller so far, because why would you use anything else, and there's only a sort of very rare accidental collision with the obstacles. They're just there to show movement for now.
I managed to use a Perlin noise map to edit meshes and create procedurally generated terrain, and then started messing everything up when I tried to use Unity's physics engine to smooth things out instead of just raycasting a bunch to move things. I might revisit this at some point, but for now it gave me a couple of ideas for my main game.
(Did you know that Perlin noise produces a perfectly mirrored result for negative sampling values? I didn't, and that was a fun couple of hours while I tried to figure out why my tiles were lining up weird.)
In order to try and get my gears going, I'm writing up descriptions of what my various classes currently do, and what they should probably be doing. I'm hoping this will help organize things in my head a bit.
Currently:
Expression and Term
These are in a pretty good spot, I think. They contain the structures for the expressions and their building blocks (terms) and perform the various operations and checks.
Draggable
Each "tile" on the game board is a draggable, and because thus far I've just been Going For It this thing does way too much. It stores the tile's Expression, the working Expression that results from dragging the tile through operators and stuff, it deals with the "flick" movement, it tracks/deactivates/destroys other tiles have been used, adjusts the brightness of things it gets dragged into, takes drop events and handles all the checks and operations resulting from them, sends energy changes to the GameRun class, tracks all the energy involved in the current operations, AND deals with all the changes to the target expression.
DropZone
Despite the name, this handles all the locations that need to do something when a tile is dragged into or through them. Right now they exclusively talk to Draggable on pointer events, and have functions to "glow" and "dim." They also have Expressions because... the target has one?
GameRun
This was where I started to get more reasonable about what should be doing what instead of having Draggable do everything. This thing manages drawing new tiles into your hand, generating target expressions and checking if they've been cleared, taking energy updates from Draggables, and managing the score/energy text and various alerts.
Should probably be more like:
Expression
I want to expand the GenerateRandom feature to take more parameters and have options for more intelligent creation instead of just adding a bunch of random Terms together; right now GameRun does some of the actual "generation" by creating smaller expressions and combining them.
Draggable
The game manager should be tracking all the other tiles/operations used and the working expression, do the bulk of the energy tracking, take care of what happens after the Draggable is dropped, and deal with the changes to the target expression. This should be sending all that stuff to the game manager and only deal with its movement and triggering events.
DropZone
The game manager should store the target expression and just tell the target zone what to display. They should also talk to the game manager on event triggers instead of Draggable.
GameRun
I think I want to split this into two things for future plans. A GameManager that deals with things like initializing the board (and eventually menus, level select, etc.) and a GameRun that deals with all the bits of actually playing (dealing with drops, the target, energy, etc.).
Hurgggh now to force myself to tear it all down and rebuild.
<french>a few days later</french>
Okay, I have ripped pretty much everything out of Draggable, and have created a bunch of function stubs in GameRun that get stuff sent to them from Draggable and DropZone (which really needs to be renamed since it's any mouseover type thing). I've started breaking out more things into their own scripts; for example, instead of having GameRun modify the text stuff to have alerts pop up/change colors, GameRun now just sends parameters about the alert to a TextAlert script attached to the Text objects, and then that script deals with all the timers and updating colors and so on.
I've also started reworking the underlying structure of how the game actually runs; instead of being GameObject based, where new tiles are instantiated as needed and otherwise do not exist, I've created a Card class and have lists for deck, hand, discard, etc. with a GameObject being instantiated and stored in the Card when it's "drawn" and destroyed when it goes into the deck or discard. Surprisingly, this all... just works, so far.
~a few days later, still~
Ran into some issues resulting from having one thing tracking stuff instead of each tile tracking all the stuff it's done, but luckily moving the relevant stuff into the Card class was relatively painless. It also means that a lot of the stuff dealing with stuff being dragged around and performing operations doesn't need to be "in" GameRun since all the functions are being passed everything they need, so I might try moving them to a separate file to try and keep things manageable.
Still gotta tie all the text alert and energy stuff back in, but after that I think it's functionally back to where it was before the rework, just with hugely more extensibility when it comes to having a deck of cards (it'll be easy to create more types and add triggers for them being played, discarded, etc.).
Instead of doing any of that, tho, I'm looking at particle systems.
A couple of days, again:
Aaaaand back to where we started, I think! Some major improvements that should be practically unnoticeable:
- lists! Instead of tiles being their own isolated objects, GameRun has lists of cards, allowing for a deck, a hand, and so on, which makes all kinds of things work more nicely instead of being kludged together out of counters and whatnot.
- cards track the things that make sense for them to track: their expressions, their current operation, the other cards they've "touched," the energy cost of all the operations, etc. and GameRun is acting much more like a central hub.
- the text alerts for energy gain/loss, score increase, etc. are now handled by a TextAlert class, which lets me send alerts to it and it will just deal with updating the text and getting rid of "expired" ones.
Let's see what we managed to accomplish from the to-do list from two weeks ago!
Still on the to do list:
- enable dropping tiles with an operation into a full bay instead of requiring that they be dragged onto the tile in the bay
- make the intelligent target generation more intelligenter
- add a term limit to bays (to prevent overly long expressions; I think this is gonna be better than text scaling or whatever)
- add energy that drains with operations so that stuff doesn't just go on forever
- add a deck of tiles instead of generating random ones (the inspiration for this game is Solitairica, btw)
- enable trashing of targets
- make sure that flicking takes into account screen size since I just discovered that resolutions were having a large impact
new to-do items for the near future:
- fix energy not being readjusted when a tile is dragged into and then flicked out of it
- shuffling the deck
- more sophisticated energy costs?
way in the future:
- adding more features to the cards like upgrades or special effects
- get started on levels, with upgrades and deck modifications and such like that persist between them
- more target features; the target will eventually represent, like, an enemy shield, and should do more stuff (drain energy unless you "attack" it with a certain type of expression, reinforce itself, etc.)
- think about ways to make the controls better; radial menu of operations that pop up when a tile is dragged to a spot and held there for a second?
I think I might spend the next few coding sessions cleaning up the fresh mess I made before I try to work on any new stuff, though.
Instead of doing anything "important," I created a radial menu! I think it's gonna be fairly reusable/extensible, so that's neat. This very pleasant write-up had everything I needed to get started; it works by editing a mesh inside a UI element. https://www.hallgrimgames.com/blog/2018/11/25/custom-unity-ui-meshes
This was also a big mood as I was finishing this up:
My job had me getting out of bed two hours early every day this week, so I have been grumpy and tired and mostly just wanted to deliver packages in Death Stranding during the evenings. So I will not be repeating last week's small novel, but I did get some dev work done.
Not knowing exactly where to start, I decided to just start with the top item on my list of things I'd ever proposed doing that hasn't yet been done, which is standardizing the way I handle player inputs and writing a system for recording them. There are two reasons for wanting to record and play back player inputs: the main one is to be able to more easily reproduce spontaneously-observed bugs; if I'm ever doing a test session and go "wait, why did that character bounce up the wall?" it would be nice to just slap a system key and throw that session's inputs into a file; since the rest of the engine is designed to produce identical results every time it executes, if you play back recorded inputs you should get exactly the result you had last time. The other, more stretch-goaly concept is speedrun verification; it would be cool if a hypothetical speedrun mode (and remember, my target is a Sonic-like, so "speedrun mode" is totally a thing) could store and then export the player's inputs so you can prove that you actually got that time. (Alternatively, it might invalidate every speedrun because who can prove that you didn't just TAS your inputs...)
Anyway, as with a lot of my engine design, I've sort of reflexively copied Unity's model until I have better ideas. Hovering off in static space is a set of "Commands" whose meaning varies with the game. A Command is really just a floating-point value in the range of -1 to 1, named with an integer value (this is the index of the command value in the Commands class's internal array). You can read the raw value of the Command or configure a threshold value that determines whether it's on or off. (That makes button press checks look something like "Commands.Active(CommandNames.Jump)".)
At the next layer down, there's a CommandSource abstract class that allows the Command values to be set by different methods according to the implementation. The two so far are a ControlMappingCommandSource, which turns controller or PC inputs into command values, and a RecordedControlCommandSource, which sets the command values to the values it has recorded. Both do a little extra work to make sure that the recording files don't get too huge by tracking only Controls that actually changed each frame, but the methods by which they do so are uninteresting.
There's one design issue that I haven't fully addressed yet, which is the role of load times on control recording. Obviously, if the game takes different amounts of time to fully load a level, the control recording is going to get out of sync with the actual gameplay. The solution to that, as I see it, is to detect when the game is fully blocked on content loading and stop issuing Commands out of the recording. But that's future work from where I am now; right now I still don't have it playing back a recording from a simple session, so my next goal is to get that written.
My favorite musical instrument is the air-raid siren.
Don't forget to keep the values from the previous frame so you can check if the button was just pressed. You usually only want to jump once, even if the player keeps holding the button.
Or I guess if you want to do an input buffer you might want to outright track how long a button has been pressed.
Good luck with your replay system. It's always nice when a game has one of those.
Just a check in. I’ve played around in a few free game making apps, and am slowly making squares do things, at least until the screen inevitably devours itself in impossible angles like a cosmic horror. So that’s basically coding, right?
My game idea (collectible monsters do coffee break rogue-like) is slowly leaning towards have a base building section between runs, to give it that constant progress some earlier rogue-like / mystery dungeons lack. I’m considering the sense in having monsters not taken on the run gain experience by being left to defend the base, whether that actually happens or is just how it’s worded to the player. Plus potentially experience could be knocked out of defeated foes as a physical object, to be kept and ‘spent’ on / ‘fed’ to whatever monster you want. That seems nice for a party based game.
I have found out today that Pokémon has, because of course it has, actually already done this idea, but looking into it the game series doesn’t appear to be that satisfying, so I’ve not been deterred.
I've been blowing off the game coding in order to focus on blocking out the environments. A common trick to distinguish areas is to use a different color palette in each area. Here are the "Verdant" and "Timberline" areas. Next I need to add a trail where giant monsters can walk around similar to the Tallnecks in HZD.
To brain dump before I start with a side project where I'm going to learn about Unity's Timeline and Playables and how to use them in conjunction with gameplay while also trying out Unity's 2020, I'm going to ramble a bit about some of my "No Frills" assets and their "progress", particularly Auras and how I'm so done (but not done) with them.
A bit ago I wrote about an Auras system, to which it was rightly recommended to try to divorce the data from Monos as much as possible, and upon retrospect and considering the pattern I've been making these things, I thought was something to aim towards by splitting off the things with lifetimes as separate components that get added at runtime if they are needed (basically, it just creates timers). Other than that, there was some cleaning to do and some tooltip descriptions, but the majority of the work was the unpleasant experience of creating videos, documentation, and images. In any case, this is the brief overview of the Auras system:
Please forgive the atrocious UI and the placeholder graphics. If anyone wants to muck around with it, feel free to DM.
The dive into "Auras" has been quite informative, and now I have a completely contained package that I can drop into whatever project and have some Auras / Passive things happening. I'm already thinking it'll be a nice test to try it out in the Bullet Hell I have planned for learning about Unity's Timeline and Playables. Many "powerups" can act as Auras as well. Hell, everything is a god damn Aura. The Skill system I've been working on shares much with Auras, so do the Items and their uses as well. It's quite easy to see how an item could have an AOE effect and also have one that 'pulses' or provides a continuous application (e.g. regen). How there's a "caster" and only certain groups can be targeted. Skills the same. Maybe everything is just an "aura", maybe now I need to completely re-write everything and burn what I've been doing to the ground. Maybe I should just make a new system titled "Everything is an Aura".
Probably not everything is an Aura, but that's my thinking right now and what I'm trying to dump out of my head so I can start fresh.
Other "No Frills" things on the plan include Modifiers and Skills. Both systems have their basic framework, but there's some things I need to iron out. I'll be revisiting both of these in the coming weeks to remind myself of the particular problems I'm trying to address in them. Once those are complete, I think that's all the 'major' systems pulled out and re-imagined from the ARPG project, at least all the ones I spent a good amount of time on.
Overall though, I feel pretty happy about these small systems I've created. I can now easily dump them into other projects and make Inventory, Random Drops, Equipment, Auras, or Level-based Attributes pretty easily (for myself) and for any students, so we don't need to completely re-write an inventory every time. One major motivation for all of this re-imagining is to then revisit my ARPG complete package and see what refactoring I can do based on my experiences with separating out the parts. Work is getting busy and will be busier towards September, so I imagine I might have that revisited and refactored by October. I've also picked up some nice Assets from the store that I'll be able to use to make the ARPG system look nice in YouTube videos.
I tried as well as I could to make a VR game for LOWREZJAM and limiting the screen to 64x64 is not working out well enough to my liking.
I can just say f*ck and just down sample the screen which does work and is playable but it causes tons of pixel swimming. Moving your head lets you see everything well but again too much high frequency noise.
I did some warping to lock objects to their pixels making everything look more like a sprite, creating a polar 3D voxel grid around the player's head to lock things in place and reduce pixel swimming or shimmering but unlike when I did the same for an orthographic camera for my last LOWREZJAM entry, in vr there are a lot more motion. I could not get it perfect.
I am giving up on this and going back to my current project UHF Traveler which is progressing quite well. I am currently blocking out the world and just getting an early version of every zone done to get a sense of scale and scope. I'm also getting new ideas while doing this.
I hit some performance issues recently since I am filling out an open world game with lots of stuff so I put some effort into culling/streaming/lod schemes. I then noticed that nothing really helped so I ran a published game with the oculus profiler running only to get similar results.
Turns out I needed to reboot something in the oculus drivers because the next time I ran my prototype I was at max fps with 30-50% free GPU/CPU overhead room instead of 40 fps with -10% GPU/CPU overhead room.
I couldn't even use one unshadowed light without causing a slowdown.
Eventhough I am blocking out the zones I am still doing some asset creation. Houdini has been great for creating clouds and recently a bunch of floating islands. The islands are just a bunch of random upsidedown cones that I turn into a volume, do a bunch of perturbations and then mesh it all back up again.
To brain dump before I start with a side project where I'm going to learn about Unity's Timeline and Playables and how to use them in conjunction with gameplay while also trying out Unity's 2020, I'm going to ramble a bit about some of my "No Frills" assets and their "progress", particularly Auras and how I'm so done (but not done) with them.
A bit ago I wrote about an Auras system, to which it was rightly recommended to try to divorce the data from Monos as much as possible, and upon retrospect and considering the pattern I've been making these things, I thought was something to aim towards by splitting off the things with lifetimes as separate components that get added at runtime if they are needed (basically, it just creates timers). Other than that, there was some cleaning to do and some tooltip descriptions, but the majority of the work was the unpleasant experience of creating videos, documentation, and images. In any case, this is the brief overview of the Auras system:
Please forgive the atrocious UI and the placeholder graphics. If anyone wants to muck around with it, feel free to DM.
The dive into "Auras" has been quite informative, and now I have a completely contained package that I can drop into whatever project and have some Auras / Passive things happening. I'm already thinking it'll be a nice test to try it out in the Bullet Hell I have planned for learning about Unity's Timeline and Playables. Many "powerups" can act as Auras as well. Hell, everything is a god damn Aura. The Skill system I've been working on shares much with Auras, so do the Items and their uses as well. It's quite easy to see how an item could have an AOE effect and also have one that 'pulses' or provides a continuous application (e.g. regen). How there's a "caster" and only certain groups can be targeted. Skills the same. Maybe everything is just an "aura", maybe now I need to completely re-write everything and burn what I've been doing to the ground. Maybe I should just make a new system titled "Everything is an Aura".
Probably not everything is an Aura, but that's my thinking right now and what I'm trying to dump out of my head so I can start fresh.
Other "No Frills" things on the plan include Modifiers and Skills. Both systems have their basic framework, but there's some things I need to iron out. I'll be revisiting both of these in the coming weeks to remind myself of the particular problems I'm trying to address in them. Once those are complete, I think that's all the 'major' systems pulled out and re-imagined from the ARPG project, at least all the ones I spent a good amount of time on.
Overall though, I feel pretty happy about these small systems I've created. I can now easily dump them into other projects and make Inventory, Random Drops, Equipment, Auras, or Level-based Attributes pretty easily (for myself) and for any students, so we don't need to completely re-write an inventory every time. One major motivation for all of this re-imagining is to then revisit my ARPG complete package and see what refactoring I can do based on my experiences with separating out the parts. Work is getting busy and will be busier towards September, so I imagine I might have that revisited and refactored by October. I've also picked up some nice Assets from the store that I'll be able to use to make the ARPG system look nice in YouTube videos.
That's awesome! I'm always happy when an architecture comes together. Now that 2020.1 is out, generically typed classes are viewable in the inspector, so I can do stuff like UnityEvent<Thing> and connect it in the editor. That really decoupled a lot of objects, like things which respond to the Interact button
So I’m on holidays and though I took the laptop along there was much chance at working.
Instead I’ve been doing ‘marketing’, on Instagram.
I had a budget foreseen, and came across a few insights as I used it up.
I started with very few followers and very little action on my ‘funnel’.
-IG for business: super useful to get ‘insights’ i.e. statistics.
-promote this post: 20 bucks over seven days gets more views than 20 bucks over three days. This is apparently because it takes a week for the IG algorithm to fine tune.
-Hard to tell if a post is being promoted more in a specific demographic or being clicked on more in a specific demographic. It’s maybe better to run subsequent promos to manually analyse stats.
-20.000 views in my case gave me 60-100 or so clicks to either website or profile, and about 20 followers, and about 2 sales.
(Something is wrong on the App Store or my price is off the mark. I will release a free version soonest and switch to freemium for my next games.)
Now, I got more followers and click throughs in 24 hours of following 50 people an hour.
I do a search for a keyword such as ‘mobile games’, click on any post that looks like mine, and follow everyone that liked it.
It’s super effective!
Following someone usually gets their attention, and if your content matches their taste you can count on 2 to 5 followers out of those 50. It takes three minutes per hour; check your hourly rate for cost.
Needless to say, IG doesn’t like it.
Because you rack up large numbers of ‘following’ accounts, you have to cull from time to time.
If you cull, follow or like too much in a row, IG will temporarily limit the actions you can take.
Overdo it a lot and you’ll be locked out.
But; it’s your best bang-for-the-buck promo wise.
Yesterday, in order to have something to report, I threw together the code that writes the controller history to a file. My next work item is actually setting up a practical test of whether controls will play back from a file correctly.
EDIT: Haha just kidding they're working now, I've got a game session playing back with perfect fidelity through recorded inputs.
Kupi on
My favorite musical instrument is the air-raid siren.
Yesterday, in order to have something to report, I threw together the code that writes the controller history to a file. My next work item is actually setting up a practical test of whether controls will play back from a file correctly.
EDIT: Haha just kidding they're working now, I've got a game session playing back with perfect fidelity through recorded inputs.
That is pretty neat, I always wonder if my games could do that... Once I did implement 'replay' in a prototype and it didn't work at all. I had no clue why except timing issues? There was a lot of raycasting involved.
So I wondered if I should have discrete states that the game would 'click' to. As this was a racing game, that means that cars should favor 'grid' positions along the track rather than being truly free.... anyway, rabbit hole.
From what I've been reading, seems like replay systems benefit from "command" pattern styles, which I'm not entirely sure how they are different/unique from a finite state machine? Maybe a FSM is in that pattern?
Yesterday, in order to have something to report, I threw together the code that writes the controller history to a file. My next work item is actually setting up a practical test of whether controls will play back from a file correctly.
EDIT: Haha just kidding they're working now, I've got a game session playing back with perfect fidelity through recorded inputs.
That is pretty neat, I always wonder if my games could do that... Once I did implement 'replay' in a prototype and it didn't work at all. I had no clue why except timing issues? There was a lot of raycasting involved.
So I wondered if I should have discrete states that the game would 'click' to. As this was a racing game, that means that cars should favor 'grid' positions along the track rather than being truly free.... anyway, rabbit hole.
Yeah, the core of performance these days is parallelization, so unless you receive a hard guarantee from whatever engine you're using that every execution of your program will be identical, there is probably something somewhere which is being run on multiple processes and isn't guaranteed to be well-ordered. The catch is that for the vast majority of games, two executions aren't likely to differ by enough to be visible to the naked eye, so neither the players nor the designers care.
From what I've been reading, seems like replay systems benefit from "command" pattern styles, which I'm not entirely sure how they are different/unique from a finite state machine? Maybe a FSM is in that pattern?
A Command Object, in the Design Patterns sense, is even more abstract than a state machine transition. It represents any atomic transformation of an input-- I think the usual pedagogical example is a mathematical operation like a sum or a multiplication. Line up the same Commands and execute them in the same order on the same inputs, and you should always get the same outputs. Moreover, if you take care to ensure that your Commands are invertible, you can also get an undo-like function for free by having the Commands perform their inverse operations in reverse order. "Add 3", "Multiply by 7", "Square Root" -> "Square", "Divide By 7", "Subtract 3", and you've got your original input. Or you can stop wherever you like in the sequence to resume from that particular state. That's actually how I handle things in my level editor! I keep a history of edit operations representing, say, laying down a tile, and store any operations that occurred as a direct result (like deleting a tile that overlapped with the one being place) as part of the history entry. Then undoing is just a matter of telling each individual history entry to invert itself.
One could, if they wished, model the act of changing states within an FSM using the Command pattern, which would allow you to create a history of state transitions, whatever good that would do you. One interesting wrinkle there is that state machines frequently have directional state transitions, and may not take kindly to the idea of going the wrong way through a transition, depending on the implementation.
Kupi on
My favorite musical instrument is the air-raid siren.
So I had three separate gameplay systems prototyped that worked, but didn't work together very well:
1. Spawning and movement of giant monsters ("Stompy Monsters")
2. Creating plant data and static meshes representing plants growing on the Stompy Monster.
3. Overlap testing of the player with plants in order to collect them.
So I rewrote a bunch of under-the-covers plumbing to connect them together and here's a video demonstrating the result. The player can climb up onto a blob monster (really just a bunch of spheres duct taped together) and scrounge for the plants that grow on it. Next task is the NPC who asks you to collect this plants and converts them into plot-relevant objects.
Does anyone know a good resource to find how to write a shader to simulate foliage / leaves that move in the wind? I'm probably going to move back to the built-in renderer instead of using the scriptable render pipelines but have held off because I have a couple foliage shaders I made with shader graph that won't be compatible and haven't been able to find any examples for shader code that does this. I may just not know the verbiage to look for.
Usually with foliage the mesh has pivots baked into the branches and leaves so that the vertex shader knows where the center is for rotating the vertices.
Gamemaker Studio released their 2.3 Beta into the public recently (before you had to be On A List(TM)), and I wanted to try out some of the new stuff. Since I didn't want to potentially mangle my D&Desque TBS lunchtime project, and because so many people on the GMS reddit ask about platformer code (which I understand because I've read a lot of it and basic code knowledge but have never really implemented myself), I decided to make a melee platformer in the vein of ActRaiser (but better!) / Castlevania to try out some stuff, like actual animation states and hitboxes and stuff.
Also, I'm trying to do some decent GUI stuff in this one, and I'm using a "DynamicGUI" scripting package that I found and is actually really cool. It handles animating UI elements when they need to get added or removed from the screen and will dynamically reposition them when the game's aspect ratio changes.
Anyway, I've got a pretty standard HP bar thing that I wanted to implement, and I thought it would be cool to have it change color as it shrinks. Now, I could've done this in-code by just picking a starting color and an ending color and doing a quick % blend between the two of them - GMS does that almost natively. Buuuuut, I wanted it to be a little fancier and nonlinear and maybe not just two colors and I didn't want to have to recalculate the color breakpoints each time I changed my mind on it (and so I could reuse the framework with other HP-like bars, like mana or stamina or whatever), so I figure I'd just create a sprite with the gradient I want. Then I can just grab the color off a particular pixel on the sprite.
This, as it turns out, is a gigantic pain in the ass in GMS.
First, the function to do this is apparently pretty expensive, so I gotta be really careful how often I use it, but more importantly it can only grab a pixel color off of a render surface. Which means I need to adapt my "screenshot a sprite" code from my TBS game. Which, there, does a perfect job of creating a new, custom sprite based on an enemy's sprite drawn on a temporary render surface, saving it to the obj_dead and changing the sprite's origin for my "fall down a pit" animation to work "flawlessly."
But here, for some reason, I only get the color black.
If I hardcode the color for the HP bar, it draws properly. If I try to grab it off the sprite, it no works.
Ugh.
On the other hand, I've taken a bunch of opengameart.org resources and hacked together a decent dodge animation, so that's good.
So, a bit more on (iOS) marketing.
After already switching my marketing budget over from Instagram to Apple Search Ads, I switched to Search Ads advanced.
This proved very useful.
On Search Ads Advanced, you can define keywords you want to campaign around. When you are selecting those keywords, Apple gives you an overview of related keywords with a five-star indication of how popular they are; from not on the radar to apparently at most three stars.
This allowed me to find a group of seven keywords/phrases that are indicative of what my game is, and also popular.
At first I put in a highly popular one: "Temple Run 3". I got a lot of views compared to Insta, and about one in fifty people would click through. No installs, though, but then my game isn't that similar to Temple Run. (In fact, the game is a mixed bag wich does an arcady style endless runner in portrait, a calmer flying with pickups in landscape, and has a setting for a very relaxed mode... It's the first game I worked on, in my defense)
Time to upgrade my marketing game again!
I had a relatively minor fix to do this week, and I took advantage of that to update my app store info. I basically took my seven keywords and put them in the keywords field. Two went into the title, behind my 'recognisible brand' name. Then, all the keywords got sprinkled into the text from two to four times (more than that is punished by the algorithm). The text has to be human readable (though no-one will ever read it unless they are already hooked).
I swapped the search ads keyword (only using one so I can get a better view on efficiency) over to 'arcade games' (multiples are actually very frequent in SEO/ ASO for some reason. I would assume that people search for *an* 'arcade game', but no.) Now I get to sit back and watch the data roll in. In a few days, I'll switch to 'floatplanes' which is actually higher starred than 'airplanes'.
So far, there haven't been any installs after the first week, but I hope the new app store texts will fix it. Next week I plan to really look at my preview movies and screenshots, adding text to the latter might help.
As further evidence that game development is making me lose my goddamn mind, this week I created a highly consistent randomizer.
... okay, y'all're game devs, so you know what I'm talking about, but it's fun to say.
So, previously I made sure that the game could record inputs and then play them back, producing the same actual events in the game. That's great for debugging sessions and speedrun validation, but making a game perfectly consistent makes it difficult to do something else that's important for game design: randomization. There's something to be said for a game that operates on entirely consistent rules but permits enough variation to make it difficult to fully explore the possibility space, but for action games, knowing that the first enemy is always going to choose its three-bullet shot can be disappointing. So the engine needs a way to provide randomization, but not in such a way as to violate the requirement that playbacks be repeatable.
There's another wrinkle that I do a lot of my processing in parallel. If every entity shares the same source of randomization, then different executions might pull the random numbers from the randomizer in different orders. So, each entity has to store its own randomizer. But that randomizer still has to be seeded somehow. I considered various approaches (including using some kind of hash function of the position or other sibling components), but ultimately I settled on a singleton component that stores the next random seed; every time an entity with a randomizer component gets created, it gets its random seed from the singleton and increments the counter. Entity creation always occurs in a non-parallelized context, so I can ensure that those operations will always occur in the same order. Combine that with a system that advances the random seed value according to some other high-entropy pattern (like the player's inputs or the passage of time) and it'll be hard for live players to get any kind of guaranteed behavior past the first few seconds of play.
And since you didn't get one last week, here's a video showing off both the input recording and randomization consistency features. I've only eyeballed but, but from what I can tell, the rings all bounce the same way after being emitted in random directions from one of the three Sonics.
Next week is SGDQ, so I have no expectations of getting any work done. The next major task is to transfer everything I've done so far to the newly-released Monogame 3.8, which now fully supports .NET Core.
My favorite musical instrument is the air-raid siren.
So one part of my game is a small-scale crafting system. The player gathers resources and then there is a "mixing" screen when you combine them into other things.
This mixing GUI has stymied me for a while. I tried a bunch of layouts but they were all a confusing mess. Finally I just stripped out extra buttons and indicators so that all I have left is:
1. The result
2. Resources you need to craft the result. If you don't have enough of a resource it is grayed out.
3. A "Mix!" button that crafts the item, greyed out if you don't have enough resources.
I feel like this is simple enough that someone can use the GUI without too much initial confusion. This current mockup works okay? You can make three things currently.
So one part of my game is a small-scale crafting system. The player gathers resources and then there is a "mixing" screen when you combine them into other things.
This mixing GUI has stymied me for a while. I tried a bunch of layouts but they were all a confusing mess. Finally I just stripped out extra buttons and indicators so that all I have left is:
1. The result
2. Resources you need to craft the result. If you don't have enough of a resource it is grayed out.
3. A "Mix!" button that crafts the item, greyed out if you don't have enough resources.
I feel like this is simple enough that someone can use the GUI without too much initial confusion. This current mockup works okay? You can make three things currently.
I like the layout, but I can't immediately read what's happening. Are you combining the middle and right panels to mix into the left panel result? Is each panel a different result which could be mixed?
Icons look great, though, and I appreciate the counters overlaid on them.
Oops, no there are three things you can mix. The big icon is the result and the things below it are the "ingredients".
I considered making one panel instead of three and having the player cycle through the things they can make. I'll see if that works any better.
Maybe scale up the central panel and down the others, so that it's emphasized? Then add scroll arrows to each side?
Seems like a UI that would only work when there's a pretty limited number of things you can craft, though, as hand-scrolling through, like, a hundred items would be painful.
Oops, no there are three things you can mix. The big icon is the result and the things below it are the "ingredients".
I considered making one panel instead of three and having the player cycle through the things they can make. I'll see if that works any better.
Maybe scale up the central panel and down the others, so that it's emphasized? Then add scroll arrows to each side?
Seems like a UI that would only work when there's a pretty limited number of things you can craft, though, as hand-scrolling through, like, a hundred items would be painful.
Scroll arrows would be pretty helpful, yeah.
And this is also something that could probably be cleared up if I just moved the cursor around for a minute, but I thought you might like to know a super cursory glance at a screenshot impression.
I'm a loose acquaintance with the programmer on a new indie title that's doing really well, and he said one of their goals was to make it instantly clear what's happening for people tuning into the middle of a random stream. They end up duplicating information in a few places, which I never even would have considered in my UX design.
"Next week is SGDQ, so I have no expectations of getting any work done."
Yeah, except I can't just not do anything. So this week I went through the instructions they have up at monogame.net about how to install the newly-released 3.8 version of the engine, which now supports (and is intended for) .NET Core. I created .NET Core versions of each project and copied over the old code, which was surprisingly painless. The primary advantages of being on .NET Core are only really relevant in the distant and increasingly unlikely long term, and include:
- Much easier cross-platform PC support; .NET Core is designed to be used on Windows, Linux, and MacOS interchangeably in a way that .NET Framework is not.
- .NET Core has much better / intentional support for the idea of publishing applications independent of the framework installation. That is to say, .NET Framework expects that there will be a massive central installation that every .NET Framework application on your machine will reuse; .NET Core expects that your published application will ship with the components of the whole framework that it actually uses. That means applications are less likely to break because of a framework update that happened outside of its control, and if Microsoft for some reason stops ever shipping the .NET Framework or .NET Core, you can still publish the application.
- But, there's also apparently been a push for performance within the engine; just shifting over to the .NET Core version of Monogame had my stress-test using two-thirds of the CPU time it used to.
- And, just generally speaking, Microsoft's been very clear that .NET Core is the future of .NET, so, y'know, always good to be standing on the platform that isn't shaking to indicate that it's going to fall into the lava momentarily.
My next task is to figure out what I even want my next task to be. I've been getting frustrated with the level / content editor I've set up, so making that experience smoother feels like a natural next task. I'm also struggling with how I want to handle streaming content from the disk / transitioning between levels, but SGDQ hasn't left me with enough of an attention span to do a lot of design work.
See you next week!
My favorite musical instrument is the air-raid siren.
Okay, I switched to a carousel-style selection of the crafting recipes. Everyone has seen a carousel GUI in like, photo galleries or news websites I think.
So I gotta hook this up to the NPC dialog and also make sure there's enough materials to gather so that you can actually make these things!
Okay, I switched to a carousel-style selection of the crafting recipes. Everyone has seen a carousel GUI in like, photo galleries or news websites I think.
So I gotta hook this up to the NPC dialog and also make sure there's enough materials to gather so that you can actually make these things!
Oh, nice! I like the combination of alpha and scaling / positioning. That is instantly readable.
kaceypwe stayed bright as lightningwe sang loud as thunderRegistered Userregular
I just tweeted a GIF of the game I'm currently working on. I've been working on it off and on for years (it still has a long way to go), and this is the first I've ever shown or said anything about the game publicly (other than non-specific posts about it here). Most people would say that I should have done this a while ago (start promoting early!), but I've been incredibly nervous to show anything. And still am! But I figured it was time.
I guess I might as well do a Reddit Screenshot Saturday post? I'm not sure how much people pay attention to those anymore but I guess it can't hurt.
So...the GIF was just an animated version of this (with a couple minor changes).
I just tweeted a GIF of the game I'm currently working on. I've been working on it off and on for years (it still has a long way to go), and this is the first I've ever shown or said anything about the game publicly (other than non-specific posts about it here). Most people would say that I should have done this a while ago (start promoting early!), but I've been incredibly nervous to show anything. And still am! But I figured it was time.
I guess I might as well do a Reddit Screenshot Saturday post? I'm not sure how much people pay attention to those anymore but I guess it can't hurt.
So...the GIF was just an animated version of this (with a couple minor changes).
Ooh, that's a good looking fire. Nice job! Is it animated?
Hey thread! Been a while. I've been pretty busy doing gamedev for my day job (working on this finally announced game) so that I haven't had much time or energy to do any personal dev in a good long while. But today I caught a gamedev bug, and jammed out a tiny little seed of a tower defense game in just about 9 hours:
Where I'm leaving it for today, with enemy spawning, multiple enemy classes, functional UI, the full core loop including basic economy implemented: https://www.youtube.com/watch?v=4NoISIr7vsk
Even started adding a bit of designability, with a wave configurator that gives me debug readouts of how many enemies with how much HP and cash rewards are in each wave. But that made me realize I have absolutely no idea how to balance a tower defense game, so that will be fun
Anyway, thought I'd share! Hope y'all have been doing great.
I just tweeted a GIF of the game I'm currently working on. I've been working on it off and on for years (it still has a long way to go), and this is the first I've ever shown or said anything about the game publicly (other than non-specific posts about it here). Most people would say that I should have done this a while ago (start promoting early!), but I've been incredibly nervous to show anything. And still am! But I figured it was time.
I guess I might as well do a Reddit Screenshot Saturday post? I'm not sure how much people pay attention to those anymore but I guess it can't hurt.
So...the GIF was just an animated version of this (with a couple minor changes).
Ooh, that's a good looking fire. Nice job! Is it animated?
Yep! I forgot I hadn't posted the GIF version here. It's a little too big for the forums. I found a really helpful tutorial that helped me get the look I wanted. It uses a texture sheet animation. Let me find it...
I just tweeted a GIF of the game I'm currently working on. I've been working on it off and on for years (it still has a long way to go), and this is the first I've ever shown or said anything about the game publicly (other than non-specific posts about it here). Most people would say that I should have done this a while ago (start promoting early!), but I've been incredibly nervous to show anything. And still am! But I figured it was time.
I guess I might as well do a Reddit Screenshot Saturday post? I'm not sure how much people pay attention to those anymore but I guess it can't hurt.
So...the GIF was just an animated version of this (with a couple minor changes).
Ooh, that's a good looking fire. Nice job! Is it animated?
Yep! I forgot I hadn't posted the GIF version here. It's a little too big for the forums. I found a really helpful tutorial that helped me get the look I wanted. It uses a texture sheet animation. Let me find it...
I said that last week would probably not have much work done because of SGDQ, but I forgot that the live broadcast is always full of intermissions with which to do incidental activities (such as the occasional twenty minutes of coding or whatever), but the week after SGDQ is the one where I watch all the VoDs I missed, and those have no breaks. Consequently, I legitimately have nothing to report other than the fact that I made my main game class accessible as a static instance because it made more sense than trying to stuff a reference to it into a specialized component in every component store. Writing your classes to be independently instantiable is all well and good, but seriously-- the main game is probably something you can confidently say will only exist once per process, and doing so lets me cut some redundancy out of my code.
I'll be honest: I don't know what I'm supposed to be working on in my game engine. Like I said last time, my next task is figuring out what my next task is. But I'm also not feeling really into it lately, despite my vacation time, because the world is still 2020 out there. If I don't run out of VoDs and recently-released games by next Friday, I'll have something to report; if not, I'll bore you with an analysis of various damage formulae I've been considering for my hypothetical JRPG project.
My favorite musical instrument is the air-raid siren.
I want to play an animation for a hit effect and then destroy the object. Is there any kind of track that can do that?
You can set a gameobject active/inactive natively, but not destroy. You would need to write that functionality, but for a playable it doesn't seem to make much sense to me to destroy since you need to be able to rewind / fast forward, so destroying kind of messes with things there. The closest thing I've seen is sending things to a pool and back (inactive / active) gameobjects. You could check out this bullet hell shooter that uses timeline for guidance: https://connect.unity.com/p/timeline-driven-danmaku-bullet-hell-shooter
You could also put an Animation Event on the actual Animation that calls a script that's attached on the same obj as the Animator which does the instantiate/destroy if you really need to get it and only care if it's used during runtime.
In other news, I've put together some 'showcase' demos for some of my "No Frills" things in action. Basically using assets to show people, hey, look, this stuff can work with pretty stuff too.
In other news, work has me busy with learning Unreal and making some prototype stuff for classes, and also we're trying to make a fall-guys lite online multiplayer game work inside a browser, which has proved quite a problem since browsers like to throttle games which affects the timestamps in Unity...so I'm betting the online part we're just going to stick to standalone builds. The original spec of the prototype was just a single player obstacle course with ragdoll person, then about midway 'online multiplayer' was tagged on, then about the last 1/3 'and webgl only'.
Posts
Timely 😣
Also, that looks really good! Did you do the sprites yourself?
Fun fact: The white highlight on the pills is a separate sprite. The sprites are white and multiplied by a color. Since that method wouldn't allow bright highlights I did them as a separate row in my sprite sheet and just draw them on top of each other.
I managed to use a Perlin noise map to edit meshes and create procedurally generated terrain, and then started messing everything up when I tried to use Unity's physics engine to smooth things out instead of just raycasting a bunch to move things. I might revisit this at some point, but for now it gave me a couple of ideas for my main game.
(Did you know that Perlin noise produces a perfectly mirrored result for negative sampling values? I didn't, and that was a fun couple of hours while I tried to figure out why my tiles were lining up weird.)
This is the guide I used for the terrain generation; it's not super pleasing but it had enough info to get things done.
https://gamedevacademy.org/complete-guide-to-procedural-level-generation-in-unity-part-1/
.
As for my ""real"" project:
https://www.hallgrimgames.com/blog/2018/11/25/custom-unity-ui-meshes
This was also a big mood as I was finishing this up:
http://surfpossum.com/applets/dragAndDrop/readme.html
My job had me getting out of bed two hours early every day this week, so I have been grumpy and tired and mostly just wanted to deliver packages in Death Stranding during the evenings. So I will not be repeating last week's small novel, but I did get some dev work done.
Not knowing exactly where to start, I decided to just start with the top item on my list of things I'd ever proposed doing that hasn't yet been done, which is standardizing the way I handle player inputs and writing a system for recording them. There are two reasons for wanting to record and play back player inputs: the main one is to be able to more easily reproduce spontaneously-observed bugs; if I'm ever doing a test session and go "wait, why did that character bounce up the wall?" it would be nice to just slap a system key and throw that session's inputs into a file; since the rest of the engine is designed to produce identical results every time it executes, if you play back recorded inputs you should get exactly the result you had last time. The other, more stretch-goaly concept is speedrun verification; it would be cool if a hypothetical speedrun mode (and remember, my target is a Sonic-like, so "speedrun mode" is totally a thing) could store and then export the player's inputs so you can prove that you actually got that time. (Alternatively, it might invalidate every speedrun because who can prove that you didn't just TAS your inputs...)
Anyway, as with a lot of my engine design, I've sort of reflexively copied Unity's model until I have better ideas. Hovering off in static space is a set of "Commands" whose meaning varies with the game. A Command is really just a floating-point value in the range of -1 to 1, named with an integer value (this is the index of the command value in the Commands class's internal array). You can read the raw value of the Command or configure a threshold value that determines whether it's on or off. (That makes button press checks look something like "Commands.Active(CommandNames.Jump)".)
At the next layer down, there's a CommandSource abstract class that allows the Command values to be set by different methods according to the implementation. The two so far are a ControlMappingCommandSource, which turns controller or PC inputs into command values, and a RecordedControlCommandSource, which sets the command values to the values it has recorded. Both do a little extra work to make sure that the recording files don't get too huge by tracking only Controls that actually changed each frame, but the methods by which they do so are uninteresting.
There's one design issue that I haven't fully addressed yet, which is the role of load times on control recording. Obviously, if the game takes different amounts of time to fully load a level, the control recording is going to get out of sync with the actual gameplay. The solution to that, as I see it, is to detect when the game is fully blocked on content loading and stop issuing Commands out of the recording. But that's future work from where I am now; right now I still don't have it playing back a recording from a simple session, so my next goal is to get that written.
Or I guess if you want to do an input buffer you might want to outright track how long a button has been pressed.
Good luck with your replay system. It's always nice when a game has one of those.
My game idea (collectible monsters do coffee break rogue-like) is slowly leaning towards have a base building section between runs, to give it that constant progress some earlier rogue-like / mystery dungeons lack. I’m considering the sense in having monsters not taken on the run gain experience by being left to defend the base, whether that actually happens or is just how it’s worded to the player. Plus potentially experience could be knocked out of defeated foes as a physical object, to be kept and ‘spent’ on / ‘fed’ to whatever monster you want. That seems nice for a party based game.
I have found out today that Pokémon has, because of course it has, actually already done this idea, but looking into it the game series doesn’t appear to be that satisfying, so I’ve not been deterred.
A bit ago I wrote about an Auras system, to which it was rightly recommended to try to divorce the data from Monos as much as possible, and upon retrospect and considering the pattern I've been making these things, I thought was something to aim towards by splitting off the things with lifetimes as separate components that get added at runtime if they are needed (basically, it just creates timers). Other than that, there was some cleaning to do and some tooltip descriptions, but the majority of the work was the unpleasant experience of creating videos, documentation, and images. In any case, this is the brief overview of the Auras system:
Please forgive the atrocious UI and the placeholder graphics. If anyone wants to muck around with it, feel free to DM.
The dive into "Auras" has been quite informative, and now I have a completely contained package that I can drop into whatever project and have some Auras / Passive things happening. I'm already thinking it'll be a nice test to try it out in the Bullet Hell I have planned for learning about Unity's Timeline and Playables. Many "powerups" can act as Auras as well. Hell, everything is a god damn Aura. The Skill system I've been working on shares much with Auras, so do the Items and their uses as well. It's quite easy to see how an item could have an AOE effect and also have one that 'pulses' or provides a continuous application (e.g. regen). How there's a "caster" and only certain groups can be targeted. Skills the same. Maybe everything is just an "aura", maybe now I need to completely re-write everything and burn what I've been doing to the ground. Maybe I should just make a new system titled "Everything is an Aura".
Probably not everything is an Aura, but that's my thinking right now and what I'm trying to dump out of my head so I can start fresh.
Other "No Frills" things on the plan include Modifiers and Skills. Both systems have their basic framework, but there's some things I need to iron out. I'll be revisiting both of these in the coming weeks to remind myself of the particular problems I'm trying to address in them. Once those are complete, I think that's all the 'major' systems pulled out and re-imagined from the ARPG project, at least all the ones I spent a good amount of time on.
Overall though, I feel pretty happy about these small systems I've created. I can now easily dump them into other projects and make Inventory, Random Drops, Equipment, Auras, or Level-based Attributes pretty easily (for myself) and for any students, so we don't need to completely re-write an inventory every time. One major motivation for all of this re-imagining is to then revisit my ARPG complete package and see what refactoring I can do based on my experiences with separating out the parts. Work is getting busy and will be busier towards September, so I imagine I might have that revisited and refactored by October. I've also picked up some nice Assets from the store that I'll be able to use to make the ARPG system look nice in YouTube videos.
I can just say f*ck and just down sample the screen which does work and is playable but it causes tons of pixel swimming. Moving your head lets you see everything well but again too much high frequency noise.
I did some warping to lock objects to their pixels making everything look more like a sprite, creating a polar 3D voxel grid around the player's head to lock things in place and reduce pixel swimming or shimmering but unlike when I did the same for an orthographic camera for my last LOWREZJAM entry, in vr there are a lot more motion. I could not get it perfect.
I am giving up on this and going back to my current project UHF Traveler which is progressing quite well. I am currently blocking out the world and just getting an early version of every zone done to get a sense of scale and scope. I'm also getting new ideas while doing this.
I hit some performance issues recently since I am filling out an open world game with lots of stuff so I put some effort into culling/streaming/lod schemes. I then noticed that nothing really helped so I ran a published game with the oculus profiler running only to get similar results.
Turns out I needed to reboot something in the oculus drivers because the next time I ran my prototype I was at max fps with 30-50% free GPU/CPU overhead room instead of 40 fps with -10% GPU/CPU overhead room.
I couldn't even use one unshadowed light without causing a slowdown.
Eventhough I am blocking out the zones I am still doing some asset creation. Houdini has been great for creating clouds and recently a bunch of floating islands. The islands are just a bunch of random upsidedown cones that I turn into a volume, do a bunch of perturbations and then mesh it all back up again.
That's awesome! I'm always happy when an architecture comes together. Now that 2020.1 is out, generically typed classes are viewable in the inspector, so I can do stuff like UnityEvent<Thing> and connect it in the editor. That really decoupled a lot of objects, like things which respond to the Interact button
Instead I’ve been doing ‘marketing’, on Instagram.
I had a budget foreseen, and came across a few insights as I used it up.
I started with very few followers and very little action on my ‘funnel’.
-IG for business: super useful to get ‘insights’ i.e. statistics.
-promote this post: 20 bucks over seven days gets more views than 20 bucks over three days. This is apparently because it takes a week for the IG algorithm to fine tune.
-Hard to tell if a post is being promoted more in a specific demographic or being clicked on more in a specific demographic. It’s maybe better to run subsequent promos to manually analyse stats.
-20.000 views in my case gave me 60-100 or so clicks to either website or profile, and about 20 followers, and about 2 sales.
(Something is wrong on the App Store or my price is off the mark. I will release a free version soonest and switch to freemium for my next games.)
Now, I got more followers and click throughs in 24 hours of following 50 people an hour.
I do a search for a keyword such as ‘mobile games’, click on any post that looks like mine, and follow everyone that liked it.
It’s super effective!
Following someone usually gets their attention, and if your content matches their taste you can count on 2 to 5 followers out of those 50. It takes three minutes per hour; check your hourly rate for cost.
Needless to say, IG doesn’t like it.
Because you rack up large numbers of ‘following’ accounts, you have to cull from time to time.
If you cull, follow or like too much in a row, IG will temporarily limit the actions you can take.
Overdo it a lot and you’ll be locked out.
But; it’s your best bang-for-the-buck promo wise.
Yesterday, in order to have something to report, I threw together the code that writes the controller history to a file. My next work item is actually setting up a practical test of whether controls will play back from a file correctly.
EDIT: Haha just kidding they're working now, I've got a game session playing back with perfect fidelity through recorded inputs.
That is pretty neat, I always wonder if my games could do that... Once I did implement 'replay' in a prototype and it didn't work at all. I had no clue why except timing issues? There was a lot of raycasting involved.
So I wondered if I should have discrete states that the game would 'click' to. As this was a racing game, that means that cars should favor 'grid' positions along the track rather than being truly free.... anyway, rabbit hole.
Yeah, the core of performance these days is parallelization, so unless you receive a hard guarantee from whatever engine you're using that every execution of your program will be identical, there is probably something somewhere which is being run on multiple processes and isn't guaranteed to be well-ordered. The catch is that for the vast majority of games, two executions aren't likely to differ by enough to be visible to the naked eye, so neither the players nor the designers care.
A Command Object, in the Design Patterns sense, is even more abstract than a state machine transition. It represents any atomic transformation of an input-- I think the usual pedagogical example is a mathematical operation like a sum or a multiplication. Line up the same Commands and execute them in the same order on the same inputs, and you should always get the same outputs. Moreover, if you take care to ensure that your Commands are invertible, you can also get an undo-like function for free by having the Commands perform their inverse operations in reverse order. "Add 3", "Multiply by 7", "Square Root" -> "Square", "Divide By 7", "Subtract 3", and you've got your original input. Or you can stop wherever you like in the sequence to resume from that particular state. That's actually how I handle things in my level editor! I keep a history of edit operations representing, say, laying down a tile, and store any operations that occurred as a direct result (like deleting a tile that overlapped with the one being place) as part of the history entry. Then undoing is just a matter of telling each individual history entry to invert itself.
One could, if they wished, model the act of changing states within an FSM using the Command pattern, which would allow you to create a history of state transitions, whatever good that would do you. One interesting wrinkle there is that state machines frequently have directional state transitions, and may not take kindly to the idea of going the wrong way through a transition, depending on the implementation.
1. Spawning and movement of giant monsters ("Stompy Monsters")
2. Creating plant data and static meshes representing plants growing on the Stompy Monster.
3. Overlap testing of the player with plants in order to collect them.
So I rewrote a bunch of under-the-covers plumbing to connect them together and here's a video demonstrating the result. The player can climb up onto a blob monster (really just a bunch of spheres duct taped together) and scrounge for the plants that grow on it. Next task is the NPC who asks you to collect this plants and converts them into plot-relevant objects.
Also, I'm trying to do some decent GUI stuff in this one, and I'm using a "DynamicGUI" scripting package that I found and is actually really cool. It handles animating UI elements when they need to get added or removed from the screen and will dynamically reposition them when the game's aspect ratio changes.
Anyway, I've got a pretty standard HP bar thing that I wanted to implement, and I thought it would be cool to have it change color as it shrinks. Now, I could've done this in-code by just picking a starting color and an ending color and doing a quick % blend between the two of them - GMS does that almost natively.
This, as it turns out, is a gigantic pain in the ass in GMS.
First, the function to do this is apparently pretty expensive, so I gotta be really careful how often I use it, but more importantly it can only grab a pixel color off of a render surface. Which means I need to adapt my "screenshot a sprite" code from my TBS game. Which, there, does a perfect job of creating a new, custom sprite based on an enemy's sprite drawn on a temporary render surface, saving it to the obj_dead and changing the sprite's origin for my "fall down a pit" animation to work "flawlessly."
But here, for some reason, I only get the color black.
If I hardcode the color for the HP bar, it draws properly. If I try to grab it off the sprite, it no works.
Ugh.
On the other hand, I've taken a bunch of opengameart.org resources and hacked together a decent dodge animation, so that's good.
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
After already switching my marketing budget over from Instagram to Apple Search Ads, I switched to Search Ads advanced.
This proved very useful.
On Search Ads Advanced, you can define keywords you want to campaign around. When you are selecting those keywords, Apple gives you an overview of related keywords with a five-star indication of how popular they are; from not on the radar to apparently at most three stars.
This allowed me to find a group of seven keywords/phrases that are indicative of what my game is, and also popular.
At first I put in a highly popular one: "Temple Run 3". I got a lot of views compared to Insta, and about one in fifty people would click through. No installs, though, but then my game isn't that similar to Temple Run. (In fact, the game is a mixed bag wich does an arcady style endless runner in portrait, a calmer flying with pickups in landscape, and has a setting for a very relaxed mode... It's the first game I worked on, in my defense)
Time to upgrade my marketing game again!
I had a relatively minor fix to do this week, and I took advantage of that to update my app store info. I basically took my seven keywords and put them in the keywords field. Two went into the title, behind my 'recognisible brand' name. Then, all the keywords got sprinkled into the text from two to four times (more than that is punished by the algorithm). The text has to be human readable (though no-one will ever read it unless they are already hooked).
I swapped the search ads keyword (only using one so I can get a better view on efficiency) over to 'arcade games' (multiples are actually very frequent in SEO/ ASO for some reason. I would assume that people search for *an* 'arcade game', but no.) Now I get to sit back and watch the data roll in. In a few days, I'll switch to 'floatplanes' which is actually higher starred than 'airplanes'.
So far, there haven't been any installs after the first week, but I hope the new app store texts will fix it. Next week I plan to really look at my preview movies and screenshots, adding text to the latter might help.
As further evidence that game development is making me lose my goddamn mind, this week I created a highly consistent randomizer.
... okay, y'all're game devs, so you know what I'm talking about, but it's fun to say.
So, previously I made sure that the game could record inputs and then play them back, producing the same actual events in the game. That's great for debugging sessions and speedrun validation, but making a game perfectly consistent makes it difficult to do something else that's important for game design: randomization. There's something to be said for a game that operates on entirely consistent rules but permits enough variation to make it difficult to fully explore the possibility space, but for action games, knowing that the first enemy is always going to choose its three-bullet shot can be disappointing. So the engine needs a way to provide randomization, but not in such a way as to violate the requirement that playbacks be repeatable.
There's another wrinkle that I do a lot of my processing in parallel. If every entity shares the same source of randomization, then different executions might pull the random numbers from the randomizer in different orders. So, each entity has to store its own randomizer. But that randomizer still has to be seeded somehow. I considered various approaches (including using some kind of hash function of the position or other sibling components), but ultimately I settled on a singleton component that stores the next random seed; every time an entity with a randomizer component gets created, it gets its random seed from the singleton and increments the counter. Entity creation always occurs in a non-parallelized context, so I can ensure that those operations will always occur in the same order. Combine that with a system that advances the random seed value according to some other high-entropy pattern (like the player's inputs or the passage of time) and it'll be hard for live players to get any kind of guaranteed behavior past the first few seconds of play.
And since you didn't get one last week, here's a video showing off both the input recording and randomization consistency features. I've only eyeballed but, but from what I can tell, the rings all bounce the same way after being emitted in random directions from one of the three Sonics.
Next week is SGDQ, so I have no expectations of getting any work done. The next major task is to transfer everything I've done so far to the newly-released Monogame 3.8, which now fully supports .NET Core.
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
This mixing GUI has stymied me for a while. I tried a bunch of layouts but they were all a confusing mess. Finally I just stripped out extra buttons and indicators so that all I have left is:
1. The result
2. Resources you need to craft the result. If you don't have enough of a resource it is grayed out.
3. A "Mix!" button that crafts the item, greyed out if you don't have enough resources.
I feel like this is simple enough that someone can use the GUI without too much initial confusion. This current mockup works okay? You can make three things currently.
I like the layout, but I can't immediately read what's happening. Are you combining the middle and right panels to mix into the left panel result? Is each panel a different result which could be mixed?
Icons look great, though, and I appreciate the counters overlaid on them.
I considered making one panel instead of three and having the player cycle through the things they can make. I'll see if that works any better.
Maybe scale up the central panel and down the others, so that it's emphasized? Then add scroll arrows to each side?
Seems like a UI that would only work when there's a pretty limited number of things you can craft, though, as hand-scrolling through, like, a hundred items would be painful.
Steam: Elvenshae // PSN: Elvenshae // WotC: Elvenshae
Wilds of Aladrion: [https://forums.penny-arcade.com/discussion/comment/43159014/#Comment_43159014]Ellandryn[/url]
Scroll arrows would be pretty helpful, yeah.
And this is also something that could probably be cleared up if I just moved the cursor around for a minute, but I thought you might like to know a super cursory glance at a screenshot impression.
I'm a loose acquaintance with the programmer on a new indie title that's doing really well, and he said one of their goals was to make it instantly clear what's happening for people tuning into the middle of a random stream. They end up duplicating information in a few places, which I never even would have considered in my UX design.
"Next week is SGDQ, so I have no expectations of getting any work done."
Yeah, except I can't just not do anything. So this week I went through the instructions they have up at monogame.net about how to install the newly-released 3.8 version of the engine, which now supports (and is intended for) .NET Core. I created .NET Core versions of each project and copied over the old code, which was surprisingly painless. The primary advantages of being on .NET Core are only really relevant in the distant and increasingly unlikely long term, and include:
- Much easier cross-platform PC support; .NET Core is designed to be used on Windows, Linux, and MacOS interchangeably in a way that .NET Framework is not.
- .NET Core has much better / intentional support for the idea of publishing applications independent of the framework installation. That is to say, .NET Framework expects that there will be a massive central installation that every .NET Framework application on your machine will reuse; .NET Core expects that your published application will ship with the components of the whole framework that it actually uses. That means applications are less likely to break because of a framework update that happened outside of its control, and if Microsoft for some reason stops ever shipping the .NET Framework or .NET Core, you can still publish the application.
- But, there's also apparently been a push for performance within the engine; just shifting over to the .NET Core version of Monogame had my stress-test using two-thirds of the CPU time it used to.
- And, just generally speaking, Microsoft's been very clear that .NET Core is the future of .NET, so, y'know, always good to be standing on the platform that isn't shaking to indicate that it's going to fall into the lava momentarily.
My next task is to figure out what I even want my next task to be. I've been getting frustrated with the level / content editor I've set up, so making that experience smoother feels like a natural next task. I'm also struggling with how I want to handle streaming content from the disk / transitioning between levels, but SGDQ hasn't left me with enough of an attention span to do a lot of design work.
See you next week!
So I gotta hook this up to the NPC dialog and also make sure there's enough materials to gather so that you can actually make these things!
Oh, nice! I like the combination of alpha and scaling / positioning. That is instantly readable.
I guess I might as well do a Reddit Screenshot Saturday post? I'm not sure how much people pay attention to those anymore but I guess it can't hurt.
So...the GIF was just an animated version of this (with a couple minor changes).
Ooh, that's a good looking fire. Nice job! Is it animated?
First wip after 2h, smooth camera movement and tower placement:
Where I'm leaving it for today, with enemy spawning, multiple enemy classes, functional UI, the full core loop including basic economy implemented:
Even started adding a bit of designability, with a wave configurator that gives me debug readouts of how many enemies with how much HP and cash rewards are in each wave. But that made me realize I have absolutely no idea how to balance a tower defense game, so that will be fun
Anyway, thought I'd share! Hope y'all have been doing great.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Yep! I forgot I hadn't posted the GIF version here. It's a little too big for the forums. I found a really helpful tutorial that helped me get the look I wanted. It uses a texture sheet animation. Let me find it...
Edit: This one!
Man, that looks like it's right up my alley!
(but, what about Floppy?)
Oh cool, I was just looking for a good VFX tutorial. Thank you!
I want to play an animation for a hit effect and then destroy the object. Is there any kind of track that can do that?
I said that last week would probably not have much work done because of SGDQ, but I forgot that the live broadcast is always full of intermissions with which to do incidental activities (such as the occasional twenty minutes of coding or whatever), but the week after SGDQ is the one where I watch all the VoDs I missed, and those have no breaks. Consequently, I legitimately have nothing to report other than the fact that I made my main game class accessible as a static instance because it made more sense than trying to stuff a reference to it into a specialized component in every component store. Writing your classes to be independently instantiable is all well and good, but seriously-- the main game is probably something you can confidently say will only exist once per process, and doing so lets me cut some redundancy out of my code.
I'll be honest: I don't know what I'm supposed to be working on in my game engine. Like I said last time, my next task is figuring out what my next task is. But I'm also not feeling really into it lately, despite my vacation time, because the world is still 2020 out there. If I don't run out of VoDs and recently-released games by next Friday, I'll have something to report; if not, I'll bore you with an analysis of various damage formulae I've been considering for my hypothetical JRPG project.
You can set a gameobject active/inactive natively, but not destroy. You would need to write that functionality, but for a playable it doesn't seem to make much sense to me to destroy since you need to be able to rewind / fast forward, so destroying kind of messes with things there. The closest thing I've seen is sending things to a pool and back (inactive / active) gameobjects. You could check out this bullet hell shooter that uses timeline for guidance: https://connect.unity.com/p/timeline-driven-danmaku-bullet-hell-shooter
You could also put an Animation Event on the actual Animation that calls a script that's attached on the same obj as the Animator which does the instantiate/destroy if you really need to get it and only care if it's used during runtime.
In other news, I've put together some 'showcase' demos for some of my "No Frills" things in action. Basically using assets to show people, hey, look, this stuff can work with pretty stuff too.
https://ventedpennies.itch.io/auras-demo
https://ventedpennies.itch.io/no-frills-inventory
In other news, work has me busy with learning Unreal and making some prototype stuff for classes, and also we're trying to make a fall-guys lite online multiplayer game work inside a browser, which has proved quite a problem since browsers like to throttle games which affects the timestamps in Unity...so I'm betting the online part we're just going to stick to standalone builds. The original spec of the prototype was just a single player obstacle course with ragdoll person, then about midway 'online multiplayer' was tagged on, then about the last 1/3 'and webgl only'.