This weekend I participated in the GMTK Game Jam and ending up making this - I'm pretty proud of the gameplay, I wish we'd had more time to add music and sounds though haha.
-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
- Status
I took part in the GMTK Jam with some fellow coworkers from Splash Damage.
And in the interest of knowledge sharing, I've been writing a twitter thread with a little "making of" to share some of my process.
I haven't jammed in a while, so it was good to get back to it again. Really enjoyed making characters too, I really feel I'm starting to improve in this area. Let me know what you think!
You can play and rate it here! https://oursbleu.itch.io/hamma-hat
And in the interest of knowledge sharing, I've been writing a twitter thread with a little "making of" to share some of my process.
I haven't jammed in a while, so it was good to get back to it again. Really enjoyed making characters too, I really feel I'm starting to improve in this area. Let me know what you think!
You can play and rate it here! https://oursbleu.itch.io/hamma-hat
Last edited:
This looks fantastic as usual. Really nice character design and modeling!
I've got a Unity physics question - specifically regarding low FPS and accuracy.
When testing our game on low spec laptops, the game predictably runs sub 30FPS. What was a surprise is that the physics by which the player moves around is also affected - specifically both the movement speed and rotation while on the ground (could be friction related) are seriously slowed and sometimes halted altogether.
Usually I'd think that this was due to code being framerate dependent, but all of my AddForce usage is in the FixedUpdate, so that was a dead end (I didn't actually realize this before when using AddForce). I did try changing the friction type in the player settings to Two Directional which lowered the FPS more, but actually allowed for some movement. Lastly, I've mucked about with the timestep/max timestep and that usually introduces more problems than it solves. At best I can lower the max timestep for "accurate" physics at low FPS, but the game speed runs in slow motion.
This isn't an area I'm particularly well suited to, but if anyone has had experience with Unity physics and low FPS, I'm, all ears.
When testing our game on low spec laptops, the game predictably runs sub 30FPS. What was a surprise is that the physics by which the player moves around is also affected - specifically both the movement speed and rotation while on the ground (could be friction related) are seriously slowed and sometimes halted altogether.
Usually I'd think that this was due to code being framerate dependent, but all of my AddForce usage is in the FixedUpdate, so that was a dead end (I didn't actually realize this before when using AddForce). I did try changing the friction type in the player settings to Two Directional which lowered the FPS more, but actually allowed for some movement. Lastly, I've mucked about with the timestep/max timestep and that usually introduces more problems than it solves. At best I can lower the max timestep for "accurate" physics at low FPS, but the game speed runs in slow motion.
This isn't an area I'm particularly well suited to, but if anyone has had experience with Unity physics and low FPS, I'm, all ears.
Unity will try to run your physics update at least as often as you tell it to. I believe this is 50 times per second by default
Things get really ugly really fast when either your physics are costly enough, or the hardware running it is underpowered enough, that your game can't keep up with that. Because the physics update is always running late, and it's actually running more often than frames are updated, it starts taking significant time away from the frame refresh. In the worst case scenario, physics themselves take all the CPU time leaving none for frame updates, meaning the game becomes a slideshow.
One solution you can try to solve this is to simply increase the physics step. Go to Edit -> Project Settings -> Time and increase Fixed Timestep (don't change Maximum Timestep, it's unlikely your game will ever hit that long in physics calculation). The higher the value, the less often Unity will calculate physics, and the less often FixedUpdate will be called. Unity interpolates and takes into account the time step for all its physics calculations so it should work fine; you may just lose a bit of precision.
Of course, this is assuming you're doing all of your FixedUpdate calculations by using Time.fixedDeltaTime as a factor of everything that is time-sensitive. If you don't, your physics code will run in slow motion when you change the timestep.
thank you! i've been trying really hard to get a readable cohesive style that looks alright.
This sounds like exactly what is happening on lower end hardware and laptops that we're testing for, super helpful.
I'll give this a try since as far as I'm aware we are using Time.fixedDeltaTime on our forces, thanks!
Has any RPG game done well with losing equipment and translating it all into perks?
Looking over the setting of my game it doesn't make much sense to be constantly getting better gear if at all. Since you're ultimately in a very limited part of the world that wouldn't really be in the situation to provide better and better armor and weapons.
Cause right now I'm thinking of having a stat/perk system wherein every time you level up you get X number of points to allocate to either learning a new skill, increasing defense, etc.
And there would be "Hidden Perks" for all of the characters that you can unlock by completing side content (although some will be part of the main quest).
Looking over the setting of my game it doesn't make much sense to be constantly getting better gear if at all. Since you're ultimately in a very limited part of the world that wouldn't really be in the situation to provide better and better armor and weapons.
Cause right now I'm thinking of having a stat/perk system wherein every time you level up you get X number of points to allocate to either learning a new skill, increasing defense, etc.
And there would be "Hidden Perks" for all of the characters that you can unlock by completing side content (although some will be part of the main quest).
Neither SMT: Nocturne nor Digital Devil Saga (that I can remember) have equipment in the traditional sense. In Nocturne, you have the Magatama which is used to learn skills and has buffs and debuffs associated with each. In DDS, you have a skill line you proceed through. Both of those games are among my favorites so it can definitely be done.
I think this is true of every non-Persona SMT game. Since you simply recruit monsters as your "party", they can level up and are fused to make more powerful ones, but they don't have equipment per se.
This also extends to this little-known, SMT-inspired RPG called Pokémon. Your pokemon can be made to hold one item, but it can be anything from a consumable, a stone that makes them evolve, etc. and not a core part of their stats like equipment is in other games.
(I'm assuming Digimon, Yokai Watch, etc. are similar but I don't have enough experience with these).
Epic finally released their official Blender integration plugins, Send to Unreal and UE to Rigify: https://github.com/EpicGames/BlenderTools
You need to link your GitHub account to your Unreal Engine account to access the repo.
You need to link your GitHub account to your Unreal Engine account to access the repo.
So I had never properly used blender (or any other modeling software really...) before. But since the game is getting more complicated using probuilder just wasn't cutting it. So I spent last night learning some low poly modeling in blender and ended up with a new space station design for the 2nd faction in the game.
As well as some small ship designs:
front: https://i.imgur.com/DPTuibu.jpg
back: https://i.imgur.com/t0GkNig.jpg
Will actually have to try this out later. Maybe just shooting at the thing or making some AI fly around it.
As well as some small ship designs:
front: https://i.imgur.com/DPTuibu.jpg
back: https://i.imgur.com/t0GkNig.jpg
Will actually have to try this out later. Maybe just shooting at the thing or making some AI fly around it.
Looks pretty neat, I especially like the space station.So I had never properly used blender (or any other modeling software really...) before. But since the game is getting more complicated using probuilder just wasn't cutting it. So I spent last night learning some low poly modeling in blender and ended up with a new space station design for the 2nd faction in the game.
As well as some small ship designs:
front: https://i.imgur.com/DPTuibu.jpg
back: https://i.imgur.com/t0GkNig.jpg
Will actually have to try this out later. Maybe just shooting at the thing or making some AI fly around it.
One of the fascinating things about game design for what I'm talking about (fighting games/beat'em ups/spectacle action) is that one of the only places to get a good idea of the kinds of things you need to make it actually sing is reddits, steam forums and gamefaqs boards. There is a real dearth of specialist knowledge publicly posted on the web on basic melee combat mechanics planning.
I should probably compile all the good stuff I've found re combat design, but so much of the cooler ideas and observations aren't in gamasutra articles but rather in obscure forum posts where people argue about why X is better than Y or in mechanics guides on the Steam community. Good shit.
I should probably compile all the good stuff I've found re combat design, but so much of the cooler ideas and observations aren't in gamasutra articles but rather in obscure forum posts where people argue about why X is better than Y or in mechanics guides on the Steam community. Good shit.
By the way, this reminds me of a video that correojon sent me a while back. It's a fantastic and very entertaining showcase of several dozen techniques to give games more oomph. It's a presentation by, uh.. the other guy of Vlambeer that is not Rami Ismail. :D
Some of them, like the one that gives the title to the video (screen shake) are more obvious, but keep watching, there's quite a few hidden gems. I ended up using several of these on Divinoids' look and feel to great effect.
You know, even though it's nearly impossible to avoid that video in indie dev, I actually can't recall if I've watched it before or not. lmao! Maybe that'll be my lecture for the day... though I really should finish the main menu video as well
Basically, enemies currently have a set of actions that are always visible. Each turn, they count down and when it hits 0 the action occurs. I've currently made it so their actions have a range of damage and a range in which their counter can roll back up to after their action occurs. Though, i was thinking about doing away with that and going in possibly one of two directions.
1 - Enemies have a deck of actions they pull a certain amount out and then those are resolved in the same way. A counter counts down and then the action occurs and they draw another to fill their hand. I think it would allow enemies to be a bit more dynamic.
2 - Just have enemies operate the same way you do. They have a set of actions that require the use of number cards to activate.
So I'm just wondering if it is more interesting not knowing what the enemy is going to do / be able to do., or being able to see what's going to happen on the their upcoming turn(s).
Most people think of games as active, but I actually think the opposite - I think games are fundamentally reactive, where players observe a state, predict an outcome from incoming stimuli, and react accordingly. This is a long winded way of saying I think games are more interesting when you can see what's coming to some degree instead of just having to guess.
I would agree with this. It's what makes Slay the Spire work. If a game is live-action, it operates on slightly different rules, since reacting happens in real time, but for anything turn or card based, like jarekx 's concept is, you need to know in advance so you can plan your move.
I'm very illiterate with regards to these videos, hahah. Looking for the link to that one, I came across this one as well, which feels like it's probably one most indie devs know about, yet it was new to me.
The "art of screenshake" one starts out a bit slow but once he actually shows the game it's a very fun ride, and a lot more enlightening than you'd expect. I would recommend taking notes of all the stuff that applies to and is not already being done in one's game.
The latter, for sure. Several games actually have "knowing exactly what the game is going to do" as a core pillar of their design, and it tends to work really well, some to widespread critical acclaim: besides the aforementioned Slay the Spire, also look into, er, Into the Breach if you haven't.
I think it would be OK to post it here, but you probably really need to poll players, not a handful of indie devs which are going to give you very skewed results. As such, I'd try contacting a mod to see if they allow you to post in other threads. I don't think it would count as self-promotion unless the poll itself contains the name of your game, but again, best consult an actual mod.
That video gets shared every time I show someone my old GMTK Jam game... I wonder why :D
I've mentioned before that I'm currently working on a metroidvania-style platformer as my main project while I'm learning coding in Gamemaker, but what keeps happening to me is as I learn new things, I keep thinking "I wonder if I could use that to do this completely unrelated thing" and so I keep getting sidetracked testing out different prototypes of things. I'm realising that I create games the same way I play them: eager and excited to start lots of new, different things but slow to actually finish anything.
So anyway, the last couple of days I have been distracted by the idea of attempting to make a Sega Super Scaler-style game. I think it is a good measure of how much I have learned that I was able to build what I have so far completely from scratch by myself, without following any tutorials. It is very rough and basic at the moment, but I'm pretty happy with it as a 2-day proof of concept.
(excuse the choppiness of the video, that's from the recording, it's running at 60fps normally)
I'm using some sprites from Afterburner at the moment just as a placeholder as it is easier to visualise than just using coloured rectangles everywhere. I'm going to keep working on it and, as long as I don't run into an impassable brick wall with it, I have a basic idea of something I could turn it into that is original and less "copyright-infringy".
I'm sure there is a better, more efficient way to do this kind of game than what I've done, I've just been making it up as I go along really. One problem I'm already hitting is that each piece of scenery is a separate game object, running its own movement code, which I know is very inefficient, and with enough active at once can cause slowdown on my (admittedly very old) PC, and that is before I have enemies implemented yet.
So anyway, the last couple of days I have been distracted by the idea of attempting to make a Sega Super Scaler-style game. I think it is a good measure of how much I have learned that I was able to build what I have so far completely from scratch by myself, without following any tutorials. It is very rough and basic at the moment, but I'm pretty happy with it as a 2-day proof of concept.
(excuse the choppiness of the video, that's from the recording, it's running at 60fps normally)
I'm using some sprites from Afterburner at the moment just as a placeholder as it is easier to visualise than just using coloured rectangles everywhere. I'm going to keep working on it and, as long as I don't run into an impassable brick wall with it, I have a basic idea of something I could turn it into that is original and less "copyright-infringy".
I'm sure there is a better, more efficient way to do this kind of game than what I've done, I've just been making it up as I go along really. One problem I'm already hitting is that each piece of scenery is a separate game object, running its own movement code, which I know is very inefficient, and with enough active at once can cause slowdown on my (admittedly very old) PC, and that is before I have enemies implemented yet.
I've never used particles in Gamemaker before, that's something I'll definitely look into. One thing I tried out was cutting the number of objects by a third then have each object in it's draw event draw itself and two more sprites either side of it a random distance apart, which seems to run a bit better but doesn't look as good.
I understand you're emulating the 3D effect by hand, doing the calculations yourself, then zooming and positioning sprites, right? I can't overstate how that seriously incredible work, especially for a two-day prototype! Feel free to go into detail about how it all works, because I'm sure most of us will find it fascinating.
If particles work anything like Unity, then the improvement in performance would be massive. The biggest issue is probably to coerce them into doing what you want, especially because, as I understand, GameMaker is not a 3D engine, so you would have to scale and move them every frame by hand, which may incur in its own performance hit. If you were doing it in a 3D engine it would be as easy as setting their position and forgetting about it, but I understand that would kind of defeat the point of what you want to make.
Still, I think particles is the way to go. I have an effect in my game where snow falls as hundreds or thousands of particles, and even on Switch it doesn't affect the framerate at all, whereas effects with individual objects, even just a few dozens of them, seriously tanked the framerate on Switch and had to be reworked.
If you have any links or resources please share, I always love reading about that stuff!
Yeah that video is amazing, I think rewatching this video several times during development can be a great help to have great gamefeel, sort of like a checklist of things you can apply.
There's a GDC talk from Platinum games about the way they design their combat systems and they say something similar, that their games are "passive", because the player usually has to react to the enemies' actions by dodging at the right moment and attacking in between enemy actions. It's like the normal state is the player comboing enemies and the game then provides those stimuli through enemy attacks to force dodging/parrying to drive gameplay.
I 100% agree with you that you need to see what's coming in order to make an informed decission, which makes the game much more interesting than purely reacting or guessing. That's why when you try to design a combat system you can't design the player in a vacuum and must pay equal or more attention to the enemies at the same time: How much wind-times attacks have, what different types of actions & associated reactions there are, how to convey those clearly through animations/sound/FX/UI...All those things will inform the player actions in what they should be, how much time and/or resources they need to be executed...and in the end you may find that you actually spent much more time designing the enemies than the player itself.
Thanks a lot, although I think what I've done is probably less complex and less flexible than what you're imagining. It's all very much cobbled together stuff.
Here's an explanation of what I'm doing for anyone interested. Please feel free to poke holes in it
I started out by getting the horizon in. It's controlled by two objects, call them oHorizonLeft and oHorizonRght, placed slightly off-screen, one to the left and one the the right. They are locked to their x coordinates but they each have a variable, yTarget, which is a y axis position, which they constantly move towards, and which I change depending on player input. So if you press left, the left object moves up towards y position 300 and the right object moves down towards y position 800 for example. If there is no input they return to default positions, say 500 and 500.
I then have a second pair of objects, oEndLeft and oEndRight, that do a similar job. They are positioned slightly wider apart and just off the bottom of the screen. They are locked to their y positions but move to target positions on the x axis based on player control. Gamemaker has a function called draw_sprite_pos which draws a sprite stretched between four x,y coordinates, and I use this to draw my ground sprite between these four objects.
Scenery objects are spawned at a random position along the line between oHorizonLeft and oHorizonRight, and move towards the equivalent position along the line between oEndLeft and oEndRight. They are scaled up depending on how far along from their start position to their goal position they are, and rotated based on the angle between the two horizon objects. Altitude is then just an additional variable that modifies the scaling.
Here's a crude MS Paint job to better visualise it:
The scenery objects need to constantly be running code because their start and end points are constanly moving as the horizon moves, which is why they are game objects at the moment. I should try and read up on how Sega actually did this stuff as I'm sure there is a better way.
I then have a second pair of objects, oEndLeft and oEndRight, that do a similar job. They are positioned slightly wider apart and just off the bottom of the screen. They are locked to their y positions but move to target positions on the x axis based on player control. Gamemaker has a function called draw_sprite_pos which draws a sprite stretched between four x,y coordinates, and I use this to draw my ground sprite between these four objects.
Scenery objects are spawned at a random position along the line between oHorizonLeft and oHorizonRight, and move towards the equivalent position along the line between oEndLeft and oEndRight. They are scaled up depending on how far along from their start position to their goal position they are, and rotated based on the angle between the two horizon objects. Altitude is then just an additional variable that modifies the scaling.
Here's a crude MS Paint job to better visualise it:
The scenery objects need to constantly be running code because their start and end points are constanly moving as the horizon moves, which is why they are game objects at the moment. I should try and read up on how Sega actually did this stuff as I'm sure there is a better way.
Gamemaker is the only engine I have any experience with so far, so a 3D engine is off the cards at the moment for me. And as you say, it kind of defeats the purpose. I'm going to look into particles though. Even if I can't use it for this, it's something I should probably be familiar with for other uses anyway.
Last edited:
Thanks a lot, although I think what I've done is probably less complex and less flexible than what you're imagining. It's all very much cobbled together stuff.
Here's an explanation of what I'm doing for anyone interested. Please feel free to poke holes in it
I started out by getting the horizon in. It's controlled by two objects, call them oHorizonLeft and oHorizonRght, placed slightly off-screen, one to the left and one the the right. They are locked to their x coordinates but they each have a variable, yTarget, which is a y axis position, which they constantly move towards, and which I change depending on player input. So if you press left, the left object moves up towards y position 300 and the right object moves down towards y position 800 for example. If there is no input they return to default positions, say 500 and 500.
I then have a second pair of objects, oEndLeft and oEndRight, that do a similar job. They are positioned slightly wider apart and just off the bottom of the screen. They are locked to their y positions but move to target positions on the x axis based on player control. Gamemaker has a function called draw_sprite_pos which draws a sprite stretched between four x,y coordinates, and I use this to draw my ground sprite between these four objects.
Scenery objects are spawned at a random position along the line between oHorizonLeft and oHorizonRight, and move towards the equivalent position along the line between oEndLeft and oEndRight. They are scaled up depending on how far along from their start position to their goal position they are, and rotated based on the angle between the two horizon objects. Altitude is then just an additional variable that modifies the scaling.
Here's a crude MS Paint job to better visualise it:
The scenery objects need to constantly be running code because their start and end points are constanly moving as the horizon moves, which is why they are game objects at the moment. I should try and read up on how Sega actually did this stuff as I'm sure there is a better way.
Gamemaker is the only engine I have any experience with so far, so a 3D engine is off the cards at the moment for me. And as you say, it kind of defeats the purpose. I'm going to look into particles though. Even if I can't use it for this, it's something I should probably be familiar with for other uses anyway.
This is delightful, and fantastically communicated as well; I understood all of it with a single read! I think particles will be really the way to go; I've checked out of curiosity and it does seem that GM allows you to position, scale and rotate particles at will. You would simply create a fixed number of particles and manipulate them exactly like you're already doing with each individual bush right now, including recycling them by moving them up top once they hit the bottom of the screen.
Also, if you don't mind an idea, I think it would make the illusion particularly convincing if the bushes started to appear "over the curve of the world" so to speak, i.e. having their tops become visible over the horizon first, instead of popping into existence. I think it could be done by having the furthest bushes (beyond the horizon):
- Render under the ground sprite instead of over it.
- Keep the size and rotation logic.
- Set their Y position as starting on the horizon and becoming lower the further away they are from the horizon, instead of being lower the closer they are to the camera.
More messing around in blender and more space ship designs:
Now off to actually set up all of these in game... The others are fine ( just repetitive unity work ) but the tanker on the bottom is gonna be a capital ship so it requires a bunch of setup and testing for separately destroyable shield generators, engines, and the cargo pods. And the AI might also need some tweaks for such a long ship. We'll see!
This is actually an interesting approach. Quite clever.
Now off to actually set up all of these in game... The others are fine ( just repetitive unity work ) but the tanker on the bottom is gonna be a capital ship so it requires a bunch of setup and testing for separately destroyable shield generators, engines, and the cargo pods. And the AI might also need some tweaks for such a long ship. We'll see!
Thanks a lot, although I think what I've done is probably less complex and less flexible than what you're imagining. It's all very much cobbled together stuff.
Here's an explanation of what I'm doing for anyone interested. Please feel free to poke holes in it
I started out by getting the horizon in. It's controlled by two objects, call them oHorizonLeft and oHorizonRght, placed slightly off-screen, one to the left and one the the right. They are locked to their x coordinates but they each have a variable, yTarget, which is a y axis position, which they constantly move towards, and which I change depending on player input. So if you press left, the left object moves up towards y position 300 and the right object moves down towards y position 800 for example. If there is no input they return to default positions, say 500 and 500.
I then have a second pair of objects, oEndLeft and oEndRight, that do a similar job. They are positioned slightly wider apart and just off the bottom of the screen. They are locked to their y positions but move to target positions on the x axis based on player control. Gamemaker has a function called draw_sprite_pos which draws a sprite stretched between four x,y coordinates, and I use this to draw my ground sprite between these four objects.
Scenery objects are spawned at a random position along the line between oHorizonLeft and oHorizonRight, and move towards the equivalent position along the line between oEndLeft and oEndRight. They are scaled up depending on how far along from their start position to their goal position they are, and rotated based on the angle between the two horizon objects. Altitude is then just an additional variable that modifies the scaling.
Here's a crude MS Paint job to better visualise it:
The scenery objects need to constantly be running code because their start and end points are constanly moving as the horizon moves, which is why they are game objects at the moment. I should try and read up on how Sega actually did this stuff as I'm sure there is a better way.
Gamemaker is the only engine I have any experience with so far, so a 3D engine is off the cards at the moment for me. And as you say, it kind of defeats the purpose. I'm going to look into particles though. Even if I can't use it for this, it's something I should probably be familiar with for other uses anyway.
This is actually an interesting approach. Quite clever.
Thanks! The bushes actually already do appear from behind the horizon, it's just hard to see in the video because of the speed they move and the choppiness of the video (you can see it happening in the thumbnail before you click play - although they shouldn't be slightly visible through the semi-transparent ground, that's a result of my quick and dirty implementation of the day/sunset effect where the ground is actually two sprites which change alpha). At the moment they start behind the ground and slightly below the horizon and move upwards until their y <= horizon then switch to being drawn in front of the ground and moving downwards. Although my implementation of it isn't perfect - I currently don't move them on the x axis until they appear over the horizon because if I do they tend to rise slightly too high before moving downwards when the horizon is tilted, because they have moved on the x axis but are still checking the horizon at their starting x position (if that makes any sense!).
Do you mind elaborating on your suggestion a bit? In particular, what do you mean by this?
I'm blind, you're completely right, you already do this. >_< I think the effect might benefit from being a bit slower, perhaps.
I think you already do this, but I meant that the far back bushes should "move upwards" on the screen as they get closer until they reach the horizon; then once they do, start moving downwards as they do now. Basically simulating them going "over" the horizon, or the curve of the world:
Again, I assume you already do this, although it's so quick it's hard to notice.
Another thing I've noticed on rewatch is that the bushes seem to "grow" as they get closer to the camera. This seems to be because the speed at which their sprites scale up seems to be smaller than the speed at which the distance between bushes scales up. As a consequence you have e.g. bushes that didn't touch when they were far away, seeming to "grow" and eventually overlap each other. My intuition is that this would be solved by tweaking either the rate of growth, or alternatively, how far apart the blue circles in your diagram (oEndLeft and oEndRight) are.
I'm blind, you're completely right, you already do this. >_< I think the effect might benefit from being a bit slower, perhaps.
I think you already do this, but I meant that the far back bushes should "move upwards" on the screen as they get closer until they reach the horizon; then once they do, start moving downwards as they do now. Basically simulating them going "over" the horizon, or the curve of the world:
Again, I assume you already do this, although it's so quick it's hard to notice.
Another thing I've noticed on rewatch is that the bushes seem to "grow" as they get closer to the camera. This seems to be because the speed at which their sprites scale up seems to be smaller than the speed at which the distance between bushes scales up. As a consequence you have e.g. bushes that didn't touch when they were far away, seeming to "grow" and eventually overlap each other. My intuition is that this would be solved by tweaking either the rate of growth, or alternatively, how far apart the blue circles in your diagram (oEndLeft and oEndRight) are.
Yeah, that seems to be basically what I am doing with the horizon stuff. I'll play around with the speed of it. I tested some taller column-like sprites and the effect is definitely more noticable, the bushes just aren't very tall.
And you're right about the "growing" thing. All the values for scaling, red and blue circle positions, etc. are just kind of plucked out of the air at the moment and definitely need tweaking to get things looking right.
Thanks for the feedback by the way!
Last edited:
Working a bit more in my city builder, I think I could make some progress in combat, post an article in IndieDB and then go back to my turn based experiment.
Here's a defensive turret I made with Blender and Substance Painter:
And here I'm testing it in Unity:
Here's a defensive turret I made with Blender and Substance Painter:
And here I'm testing it in Unity:
More work done this weekend. Since I was modeling ships during the week nights I really wanted to fly them. Just one little problem. No ship swapping, buying, selling, storage etc. mechanics in game yet.
So after a long couple of days that stuff is now all coded up and done (aside from polish etc. obviously).
Testing if things work: Land at a new station, check which ships the station sells, buy a couple of different ships from the shipyard, check the ships the player owns from the ship storage panel, enter one of the ships and then undock from the station and fly away with the new shiny ship.
Twitter version: https://twitter.com/OArkko/status/1284947775793369089
And then also some 7680x4320 screenshots of all the different new ships rigged into unity:
Front: https://i.imgur.com/Rjb9K69.jpg
Top: https://i.imgur.com/owdcuYo.jpg
Not sure what to work on next. Maybe gas giants?
So after a long couple of days that stuff is now all coded up and done (aside from polish etc. obviously).
Testing if things work: Land at a new station, check which ships the station sells, buy a couple of different ships from the shipyard, check the ships the player owns from the ship storage panel, enter one of the ships and then undock from the station and fly away with the new shiny ship.
Twitter version: https://twitter.com/OArkko/status/1284947775793369089
And then also some 7680x4320 screenshots of all the different new ships rigged into unity:
Front: https://i.imgur.com/Rjb9K69.jpg
Top: https://i.imgur.com/owdcuYo.jpg
Not sure what to work on next. Maybe gas giants?
Last edited:
backend stuff. might work on some more visual stuff this week. I was hoping to find some nice bgs to slot in so I could get parallax working, but I can't find anything great open source, so I might have to just make my own (or modify an open source one slightly). Mind you, nothing I can find commonly online works well with my glaring-colour sprites right now, but it's all for testing so whatevs
First character of my fighting game project, Ghost with a Gun !
It's my first full body sculpt, still some work to do on the legs, but after that, the revolver and sneakers will be pretty easy I think.
I'm going to 3D print her as figurine too, probably tuesday when I'm done sculpting her.
I was hoping to a have a finished playable by the end of today but life got in the way. I did manage to get a functional inventory working and make the battle screen a little less ugly. I'm still debating on how to display the cards / skills and whether I want the enemy offset on the other side or lined up with the player on the left. Lined up makes it easier to glance up and see their HP / buffs but I don't really like how that looks.
Added a few new enemies including a Math teacher who inflicts the subtract status on you. Subtract basically does what is says, subtracts one from your cards when they get drawn at the beginning of your turn. Can make things difficult if you are running skills that want higher numbers for damage, but if you are running low number skills it can be a blessing as you may draw some of those higher numbers and get them into a workable range easier. I know i'll have Add and Subtract as statuses, may also include multiply and divide though that could get hairy and out of control.
Next, I'm gonna add a Number Wizard who looks at your deck and offers you three choices of ways to change it. They could see a two and want to double them, making all 2's become 4's, see your 6's and subtract 1 from them, etc. I figured it would be a thematic way of changing your deck without just simply letting you remove cards from it.
So I tried different gas giant solutions. Ended up with a fluffy jupiter particle system with a custom lighting solution:
And then I also tried some other approaches for planets. Previously they were just plain old spheres with gameobjects stuck on the surface. It's gonna be more work but I do like the blender sculpted + normal mapped planets quite a bit more. Still not quite sure how much it's worth the effort considering that I really do want a lot of hand crafted planets.
And then I also tried some other approaches for planets. Previously they were just plain old spheres with gameobjects stuck on the surface. It's gonna be more work but I do like the blender sculpted + normal mapped planets quite a bit more. Still not quite sure how much it's worth the effort considering that I really do want a lot of hand crafted planets.
I've been cutting a lot of features from my game in order to improve the core and stick to my release target.
Multiplayer mode? Gone
VR option? Gone
Procedural maps and campaigns? Gone
It also really helps with describing the game. It was Civilization X Minecraft X Skyrim which could be interpreted a million different ways. 'Twas a mess trying to explain all the ways it could be played.
Now it's just structured as an action-adventure game and the experience itself is what makes it special. It's kinda scary since it's a very competitive genre with botw, assassin's creed, ghost of tsushima, etc. all made by huge teams but I'm confident at least some players will enjoy my take on it.
Multiplayer mode? Gone
VR option? Gone
Procedural maps and campaigns? Gone
It also really helps with describing the game. It was Civilization X Minecraft X Skyrim which could be interpreted a million different ways. 'Twas a mess trying to explain all the ways it could be played.
Now it's just structured as an action-adventure game and the experience itself is what makes it special. It's kinda scary since it's a very competitive genre with botw, assassin's creed, ghost of tsushima, etc. all made by huge teams but I'm confident at least some players will enjoy my take on it.
hope theres a bunch of yaoi hands in this one
for real though hope to see some good shit. i'm keeping my eye out for the next yuri jam
It's good that you're making those cuts and tough decisions now, rather than scrambling later. I don't have much experience in either of those 3 things, but those don't seem like small undertakings.
I'm still over 6 months away from my release target but it kinda feels like scrambling haha.
Cutting procedural maps/campaigns was a really tough choice since I developed all the tech for it already but I couldn't fit both it and my gameplay systems into next gen ram. Pre generating most of the world and putting it on the SSD solves that issue.
Well, I just added a "Bully' enemy. They use a skill called "Sick Burn' that inflicts you with the burn status effect. They also have a starting status themselves called Fragile Ego, and after you hit them for a certain amount of damage their active skills become "Cower' which just adds 1 Shield.
Since I have a teacher, and a bully. Maybe I'm going to make this a schoolyard based game where the kids are playing this on recess or something. The different classes could be kids that are into different things, so the 'monk' would really just be a kid that was always taking Martial Arts class, and so on.
Since I have a teacher, and a bully. Maybe I'm going to make this a schoolyard based game where the kids are playing this on recess or something. The different classes could be kids that are into different things, so the 'monk' would really just be a kid that was always taking Martial Arts class, and so on.
Gotta love them
today, I released my first entry for the yaoi jam.
it's about an angel who falls in love with a boy who talks to the skies.
let me know what you think ♡
it's about 7-10 minutes long (windows only for now)
https://xiri.itch.io/lilian-the-beginning-of-the-end
- Status