So, due to the way my body freaked out when I went full Crunch mode to get my game out for the holidays, I have since been very casually working on a UI overhaul, and am getting fairly close to a done state.
I recently took a UI break to focus on feature improvements, and I am now just a handful of steps away from finally adding multiple saves and a third character class. Right now you can only have one character, and have to kill the save to try the other class. This will obviously be a big boon to players and open up expansion and customization options quite a bit, and opens up a few ethical future paid expansion options like extra character classes and slots.
Multiple character save slots and character switching are in! Lots of cleanup before it goes live, but players will now be able to play through on all three classes, and can quickly switch between characters, with separate progression. There's now also a special player save so things can be tracked and applied between different character saves.
Plugging away at the character editor. All of the content file add/remove controls are there at this point. The most presentable thing I created this week was the "subset picker", a sort of I-don't-even-know-what-to-call-this title for a thing that lets you pick a particular subset of a texture, such as what the game ought to consider "walk animation frame 3".
You can left-click and drag to select the subset you want, which is clamped to the actual dimensions of the image file. The dimensions can be fixed to a specific target size, such as for selecting the icon the Character ought to be represented by in the level editor's tools pallet. I also just coded (like, today, in the span of an hour) a tool to do a sort of iterative flood-fill when you right-click on a non-transparent pixel that discovers the borders of a sprite. (Notice that the dust cloud coming out of Sonic's feet have been picked up despite not being connected to the bulk of his sprite.) I still have one more feature to include, which is the ability to middle-click and drag to explore more of the image, but otherwise the subset picker is good to go.
My target for next week is to have the animation editor finished. If I'm particularly disciplined (I won't be), I could also get the collision data editor going as well, which is tightly coupled to the animation editor in any event.
My favorite musical instrument is the air-raid siren.
One step further, and the hexagons are being created by an Entity in a Jobs system... It's a very simple adaptation of the Unity DOTS sample scenes (they've dropped calling it ECS). The Monobehaviour loader took a while to load, but this is lightning fast. Meaning I can get more buildings on the screen, quicker. This is about the limit of what works on my Skull Canyon: 100*100 hexagons for about 30 square kilometers of city...
It's pretty smooth at 44fps, but I'm going to get some sleep instead of doing an iOS build.
Next up is animating the alien that's somewhere in there (it's briefly visible in the video in my previous post) and start looking at DOTS particle systems. So, DOTS making dots. I'll get my coat.
hey game dev thread, got a situation that I thought some people might have some advice on.
Has anyone here ever done an engagement test with a publisher? I've been working on a casual spelling game and I've been lucky enough to attract the interest of a publisher. They want to do an engagement test. Basically I give them a demo build of my game, they pay for about $500 worth of facebook ads, and if the numbers are good enough the relationship might proceed.
The studio is called Lion Studios and they seem legit as far as I can tell. The representative told me to work on about 20 levels and hand it over to them.
Has anyone ever done anything like this before? I've only tested my game with strangers a handful of times and it's difficult to know whether it will flop or whether strangers will be interested.
What should I focus on?
1. tutorial
2. Graphical Polish
3. Metagame
4. making the levels varied and interesting
I haven't posted anything recently because I was busy with a new job that the first 6 months were a rush that just took all my focus but now things have cooled down a bit and I got my first VR headset last week I had to try it out. My wife asked me what games did I want to play in VR and I told her that I didn't want a VR headset to play games (going back to subnautica though), I wanted one to build and try ideas and have fun.
So my last weekend was dedicated to experimented with various ideas
That roll locking flight mechanic is something I'd been thinking about too. Nice to see somebody actually implement it. The one I was thinking of would roll only during turns, so you feel real gravity in the direction that centrifugal force would be pulling, by only rolling to align the real world force direction with the expected force direction in VR.
That roll locking flight mechanic is something I'd been thinking about too. Nice to see somebody actually implement it. The one I was thinking of would roll only during turns, so you feel real gravity in the direction that centrifugal force would be pulling, by only rolling to align the real world force direction with the expected force direction in VR.
The roll locking I implemented is also dependent on the dot product of your forward direction and the force (gravity) vector. As you can see in the video this allows you to do loops or turn towards or away from the up direction without the ship trying to level, since you are parallel to the force the change in leveling direction is jarring. So you level only when your forward is perpendicular to up or down which is when you'd want to level your ship anyway. Basically you only auto-level when trying to fly along your true horizon. I still need to add roll controls though for all other cases.
Has anybody tried to implement multiple music files to compose a whole song?
The most distinct use of the effect I can remember was on SSX. When you pick up speed, you get additional percussion and higher volume. When you make a big jump, the bass and drums drop out to emphasize the altitude and let the wind sounds stand out.
My guess is that a) they're running multiple tracks stored in individual files, so they can mute the drums and such, running the remainder through an equalizer filter, or b) they're running finalized tracks without a dynamic equalizer and fading between them.
Has anyone tried to do this in Unity? Are there any assets or libraries to manage this kind of thing?
Has anybody tried to implement multiple music files to compose a whole song?
The most distinct use of the effect I can remember was on SSX. When you pick up speed, you get additional percussion and higher volume. When you make a big jump, the bass and drums drop out to emphasize the altitude and let the wind sounds stand out.
My guess is that a) they're running multiple tracks stored in individual files, so they can mute the drums and such, running the remainder through an equalizer filter, or b) they're running finalized tracks without a dynamic equalizer and fading between them.
Has anyone tried to do this in Unity? Are there any assets or libraries to manage this kind of thing?
What you're looking for is called Adaptive Music. There are a few unity assets that will manage it for you. Psai Music Engine or Elias can show you how its done. Pretty sure i remember seeing a FMOD and WWise tutorial on youtube some years back,
Last week, I said that if I was particularly disciplined, I could have the collision volume editor finished, though I was pessimistic about the possibility. And as it turns out................................................................................ I was not particularly disciplined.
I did, however, hit my target of having the animation editor finished.
Animations in my engine have, in no particular order:
- A name by which they can be referred to other than their file name. This allows for a weak form of virtualization of animations, where you might not know what Character you're dealing with, but you can tell it to display the "Pain" animation as it's knocked back.
- The texture (expressed as an index into the associated Character's content array) to pull the sprites from.
- The default playback length in frames (this can be overridden at run-time).
- A playback type that indicates how they should play back, such as "progress forward and stop at the end", or "progress forward and loop back around to the start".
- An array of Frames that define the subset of the texture to display (selected quickly using the subset picker from last time) and the offset from local origin (useful aligning run cycles to the ground, for instance).
- Each Frame also has an association between collision volume names and the collision data to dispatch to the named Entity's collision volume component on transitioning to that frame.
Right now you can create collision data, but you can't actually update the data itself. That's my next task for the coming week.
I also did some work to figure out how to integrate my human-readable JSON files into MonoGame's data pipeline. Previously, I'd gone to the effort of finding a good open-source ZIP/Deflate library to use to compress my object files. As it turns out, MonoGame inherits from XNA the concept that every game ought to compress its content files-- the base class for the content processor includes a data compression step built-in. It'll still be handy to be able to deflate things like save files (which aren't part of MonoGame's content pipeline), but for now it doesn't feel worth the effort of re-compressing my data when MonoGame handles it for me. In doing all this, I discovered that the content reader class (you have to implement four classes to add your own data type to the content pipeline...) is afforded a reference to the ContentManager that's using it to load. Since my Character type carries around a bill of materials for the content it needs, that means that instead of having a separate step for loading the character file and then looping over its content path arrays, all that loading can take place in the Character content reader itself. And even better, my planned Level object works the same way, storing the Characters it needs. Which means that loading into a new level will, in the fullness of time, compress down to just one line of code! (... in a background thread so the loading process doesn't cause frame hitches which means that there will be a bunch of code dedicated to determining when that process has finished but don't pay too much attention to that, ONE LINE OF CODE)
My favorite musical instrument is the air-raid siren.
Has anybody tried to implement multiple music files to compose a whole song?
The most distinct use of the effect I can remember was on SSX. When you pick up speed, you get additional percussion and higher volume. When you make a big jump, the bass and drums drop out to emphasize the altitude and let the wind sounds stand out.
My guess is that a) they're running multiple tracks stored in individual files, so they can mute the drums and such, running the remainder through an equalizer filter, or b) they're running finalized tracks without a dynamic equalizer and fading between them.
Has anyone tried to do this in Unity? Are there any assets or libraries to manage this kind of thing?
What you're looking for is called Adaptive Music. There are a few unity assets that will manage it for you. Psai Music Engine or Elias can show you how its done. Pretty sure i remember seeing a FMOD and WWise tutorial on youtube some years back,
Yeah, I saw the FMOD stuff a while back, but that is a bit much. I'm messing around with updating the AudioSource.timeSamples value to see if I can keep tracks in sync. I'll let you know if it's a huge failure!
I added visual editing of collision volumes associated with character animations. Aside from some convenience macros that I might need to make my Sonic knockoff, this interface is now finished. Huzzah!
My next major task is creating the "template editor" that creates and modifies component storage instances. Once that's done, Character editing will be feature complete and I can move on to the level editor.
Incidentally, I was playing Timespinner recently and something just felt... familiar about the game in a way I couldn't place. On a hunch, I looked up what engine they used, and wouldn't you know it? XNA 4!
My favorite musical instrument is the air-raid siren.
So, I'm hitting a few framerate issues. You can barely see the dots on the road a bit beyond the empty road up front, and those cars are separate entities. Very low poly, but I think they're putting the game up to its limit on the iPhone. I definitely need a closer cutoff/crossover on all the detail levels, but that should be more than fine. The cars won't be visible from up top of the big towers, for example, and they shouldn't be visible more than a hex and a half away.
Most of all, it still looks white as f*ck on the phone, but I put in a bug report and let's hope that gets fixed at their end somehow...
Looking pretty good in the editor tho.
Owing to getting back into several different games this week, I didn't get much accomplished. Still have one thing to report, though:
The Component Storage Editor, which... edits the Component Storage class that... stores Components. The Component Storage class is both the main repository for entities and acts as an individual cloneable, fuseable collection. So individual Character files store a Component Storage that acts as the template for all instances of that Character. When you create a new copy of that character, their Component Storage is cloned and then fused with the main Component Storage used by the game. Right now the only thing you can do with this editor is create new Entities and then re-assign their values through text. (I decided against going with Unity-style form controls because I can't really see the dev effort put into doing so breaking even versus just... retyping the values when I need to. Collision volumes and sprites already have visual editors and other object relationships will be assigned through the Level Editor.)
I ran into some errors with reflection and parsing my custom fixed-point errors, which were 1) uninteresting enough that I lost interest in working on them, and therefore 2) are my first task for this next week.
My favorite musical instrument is the air-raid siren.
A bit of advice, I'd like to get in to game dev a bit, not with any intention to release anything but just to mess around. However I've not programmed in years, we're talking starting with Basic on the c64 and finishing with c and c++ whilst in school before hitting my late teens and finding more 'interesting' (at the time) stuff to do.
I do some programming at work, but it's normally forcing SAS to do things it's not really meant to do, and more recently some stats stuff in R.
So I've no idea where to start, like not a clue. My very tiny programming background comes from an era where you had to start everything by scratch, which isn't the case now? There's unity, and unreal and others no doubt. I did a bit of Quake 2 modding but nothing major so I guess that's a bit like playing with an engine?
My goals are to play about with VR, it's been something I've loved for ages so anything that will let me write simple stuff for PCVR and (even better) the Quest. I'm guessing there's a difference there too with Quest being android based.
I've no commercial goals at all, it's just for my own fun. Where do I start? What tools do I need? Should I bother?
A bit of advice, I'd like to get in to game dev a bit, not with any intention to release anything but just to mess around. However I've not programmed in years, we're talking starting with Basic on the c64 and finishing with c and c++ whilst in school before hitting my late teens and finding more 'interesting' (at the time) stuff to do.
I do some programming at work, but it's normally forcing SAS to do things it's not really meant to do, and more recently some stats stuff in R.
So I've no idea where to start, like not a clue. My very tiny programming background comes from an era where you had to start everything by scratch, which isn't the case now? There's unity, and unreal and others no doubt. I did a bit of Quake 2 modding but nothing major so I guess that's a bit like playing with an engine?
My goals are to play about with VR, it's been something I've loved for ages so anything that will let me write simple stuff for PCVR and (even better) the Quest. I'm guessing there's a difference there too with Quest being android based.
I've no commercial goals at all, it's just for my own fun. Where do I start? What tools do I need? Should I bother?
Renpy visual novels
Gamemaker for 2d and many other things
Rpgmaker for various.."things"
Unity
Unreal 4 and source for fps
Pick a game you really enjoy, scale it down and try and make it
A bit of advice, I'd like to get in to game dev a bit, not with any intention to release anything but just to mess around. However I've not programmed in years, we're talking starting with Basic on the c64 and finishing with c and c++ whilst in school before hitting my late teens and finding more 'interesting' (at the time) stuff to do.
I do some programming at work, but it's normally forcing SAS to do things it's not really meant to do, and more recently some stats stuff in R.
So I've no idea where to start, like not a clue. My very tiny programming background comes from an era where you had to start everything by scratch, which isn't the case now? There's unity, and unreal and others no doubt. I did a bit of Quake 2 modding but nothing major so I guess that's a bit like playing with an engine?
My goals are to play about with VR, it's been something I've loved for ages so anything that will let me write simple stuff for PCVR and (even better) the Quest. I'm guessing there's a difference there too with Quest being android based.
I've no commercial goals at all, it's just for my own fun. Where do I start? What tools do I need? Should I bother?
Unity and Unreal are the biggest/most well supported engines out there right now, so I'd just read up both of those, do a few basic tutorials for each one (start with the ones about using the interface rather than coding stuff just to get a feel for each one), then do a couple of their "build this game using these supplied assets" tutorials (I know Unity has a few of those, I assume Unreal does too). Obviously coding is a big part of the process, but even just getting comfortable with the basic interface can go a long way to building the confidence/know-how you'll need to make a hobby out of it. And there's a lot you can do on the hobbyist level without having to do much in the way of hardcode coding these day.
You can also try out some of the engines Royce mentioned, but in my opinion they're a little more specialized and not quite as robust as the two major ones.
UE4 also lets you do all of your logic in Blueprints, which is a handy way of bypassing needing to (potentially) learn another programming language. After a decade of Python I've no intention of going back to C-alikes for a hobby, so that was handy for me.
I think it's pretty much Unity or Unreal if you want to play with VR.
Both have solid workflows to most VR systems.
You might want to do a single beginner's tutorial in each engine and decide based on the experience (ease of use, community support) which you prefer.
Last week I said I had to handle some annoying odds and ends because I didn't handle them last week.
This week I handled some annoying odds and ends because I didn't handle them last week.
Odds ended and ends odded:
- I fixed the serialization of my fixed-point number type by giving it a TryParse method and more carefully examining the possible ways its format could be flummoxed. (I wrote a suite of unit tests to verify these cases. Unit tests! They're great.) So it's now easier to gracefully detect an incoming failure and tell the user their input is garbage, rather than just exploding.
- When saving to a file, I now shunt the original (if any) into a backup and then restore from the backup on failure or delete the backup on success. This means that if there's an error in the middle of writing the new file, you don't wind up with nothing but a half-written garbage file.
- Component Storage now supports adding and removing individual Components from Entities. This would be trivial if Components were reference types, but they're value types in my architecture due to semantic and data-alignment concerns. That means that the cost of adding or removing a Component is the cost of copying all of the other components of the same entity to a different Archetype (combination of component types). I've wracked my brain for cases when adding or removing individual components with any frequency would be necessary and haven't come up with any... or at least, none that would justify going back and re-architecting my component storage and System pipeline from scratch. Honestly, if anyone else has experience with ECS architectures and can speak to cases when adding or removing Components from Entities at runtime (not including parenting changes) was useful from a game-design sense, I'd like to hear about it.
Otherwise, I'm getting closer to having the Character Editor finished, which means I'm close to starting on the Level Editor. And after that... gameplay design! It's slowly coming together...
My favorite musical instrument is the air-raid siren.
My schedule has been through an adventure that I don't feel like recounting here, but the summary is that I've taken my standard week off of work and all forms of personal responsibility to watch SGDQ. This means that I've accomplished exactly nothing in terms of game dev this week and feel no guilt about it.
To keep this post on-topic, though, I did at least put some thought into the challenge regarding viable use cases for transient components. The best application I could come up with is some kind of "burning" status; if an object has a BurningComponent, then the BurningSystem lowers its health, changes its associated sprite's tint, emits fire particles around the position of the burning object, and lowers the remaining time stored by the BurningComponent. When the remaining time hits zero, it deletes the BurningComponent from its Entity, so the Entity is no longer burning.
The counter to that is that I can achieve the same effect by creating an Entity with nothing but a BurningComponent which is parented to the Entity that's supposed to be burning. Then the BurningSystem does all of the previously-described effects, just with an additional check to ensure that the parent reference is still valid. If the parent reference is invalid, then the burn entity gets deleted that frame.
Or, to summarize: transient Entities can sufficiently emulate the effect of transient Components in the arrangement I have now, so I don't believe that finding a way to make adding and removing Components from Entities hyper-performant is worth sacrificing the optimizations I've already done.
This week's plans are to proofread the Component Storage Editor and move the loading of textures and collision data into the Animation object to avoid some data-shape issues I ran into previously.
My favorite musical instrument is the air-raid siren.
My traditional bi-annual week of watching SGDQ has been followed by my traditional bi-annual week of watching all of the VoDs I missed while I was sleeping. Productivity was limited.
This week I moved the textures and collision data that are stored as content to being stored by the Animations that use them, rather than by the Character who owns the Animations. This avoids some data-consistency issues I was encountering in the editor at the cost of storing more references to the same data, but even if I load dozens of content files, that still only totals, like... 5k worth of references. It's nothing.
I've also done a little setup work to allow loading from raw files (uncompressed text and PNG files) where they're available rather than MonoGame's content pipeline. The primary motivation for doing this is allowing me to run the game out of the level editor to simulate something like Unity's "edit and play in a single editor" workflow, but after some thought I've realized that I sleepwalked into providing mod support for every game I make on my architecture, so that's neat.
My plans for next week are to validate that all the work I described above works as intended.
My favorite musical instrument is the air-raid siren.
Tom Scott did a series of videos in collaboration with a mobile studio on what it takes to build an app, focusing on the know-how more than the nitty gritty of coding, might be of interest to some people here (linking to the introduction video, you can find the actual playlist via that).
For people who are in or near the Absolute Newbie stage of gamedev stuff, the guy running most of those courses is great. They're absolutely not the standard Youtube tutorial where someone mumbles through their workflow in an unrehearsed way.
Hopefully this will be my last slow week for a while. Nevertheless... not much to report this week. I rearranged my content file formats a bit and modified the editor to account for the changes. I still need to do a full round-trip through the project editor to make sure that my content pipeline is still working before I can call that done.
The next step after that is to do some serious design work on the level format. I'd been planning to move on to the level editor as the next major phase, but it turns out that before you can edit levels, you actually have to have a level object to edit. I've had ideas kicking around for something that uses a modified version of the sweep-and-prune broad-phase collision detection system I built to handle the creation and deletion of items as they pass close to a particular reference frame (say, the player character or the camera), but nothing concrete enough to start laying down code. So, expect an essay next week on the specifics and, in all likelihood, and apology for it not being fully implemented yet.
My favorite musical instrument is the air-raid siren.
Offering what i hope is the correct link as this bit of trickery might help someone in the future solve their problem.
Space combat takes place in one level space that is projected onto the windows of the ship interior spaces, like looking through the portals in portals.
When you leave a ship, you jump to that portal space.
When you board an enemy ship, you leap to a third space.
Offering what i hope is the correct link as this bit of trickery might help someone in the future solve their problem.
Space combat takes place in one level space that is projected onto the windows of the ship interior spaces, like looking through the portals in portals.
When you leave a ship, you jump to that portal space.
When you board an enemy ship, you leap to a third space.
This article might have some more detail on it, but definitely has a great look at the trials of that team, and how that led them to work creatively with what they had and build on it to make Warframe what it is today.
I'm still working on the same game, FNS. For various reasons I've not made any huge leaps. A lot of the visual issues I've had were resolved by limiting the scaling in the game, which meant rescaling all meshes in Blender.
Currently, I'm working on modelling a ship that will likely be one of the player ships. I'm making it modular so I can reuse assets, but it's slow going as it has to be an almost 1:1 copy of a real-life model my partner got from a friend. He's relying on volunteer work for his TV pilot, and he wants to volunteers to see their work reflected in the game. It adds a slight challenge to the modeling work to keep things faithful!
I've also been sidetracked by a short story that is going to be published in a collection, and the need for a solid marketing setup to be in place for the release of that collection. A lot of the self-publishing stuff for stories and books transfers across to indie gamedev. Basically, it's A LOT of HARD work. Selecting the right tools, and even understanding the marketing, is crucial to not waste your time, effort, and eventually money.
In the coming days, as I come out of a bad cold, I'll be setting up Mailchimp, facebook pages, and various landing pages on my own website. I've been busy with CSS for the latter, getting it to scale properly. I've also revamped my 'about' section, as well as starting on CSS code for the 'press' pages which they should be able to copy paste.
All in all, it's a lot more work than simply getting games on a store.
Fixing up my site also has made me realize that for the next upcoming games I'm going to have to dig deep. I've long wanted to involve my fantasy and sci-fi worlds. But they are very world building heavy and best suited for (strategic) rpg gameplay. I've dabbled with some of that last year, but have yet to return to it since picking up Unity. Some small scale testing will set me back on that track.
But for the immediate future, aside from FNS development and my sidequest in marketing, I am going to try and get the Unity shader graph to work in my game Endless Azure, already out on android. The idea is to get color swaps going through shader graph so that I can model additional airplanes without having to worry about the four differing UV maps I needed in my handcoded shader. If it works, adding extra airplanes for an iOS release will be easier. And with all Schneider Trophy planes added to the game, I feel I can add in-game purchases.
also does anyone have any tips about finding an artist to work with? We've got a pretty strong team but what we really need now is an artist who is interested in putting in the time for the next game jam
It goes over AI techniques used in games. It was interesting to see the AI system I developed for Parabolus is pretty much the same one used in Halflife (their one is more complex however).
All right, well. What I have finally settled on calling the "Level Scrolling System" isn't fully complete, but I got the basics of it banged out this week. Certainly enough that I could write a few unit tests to make sure that the behavior is basically correct. So this week's post is dedicated to just what the Level Scrolling System is.
It stands to reason that the kind of game object that's fastest to process is one that doesn't exist. Even if your level contains 100 enemies total, unless all 100 of them are on-screen and moving at the same time, you don't necessarily need to be tracking them at the same time. Plus, if you have an enemy like a Goomba that will brainlessly walk off the edge of a platform, spawning them in at the start of play when the player is half a mile away leads to the player finding Goombas in very low places on the level. An engine like Unity or Unreal solves this with a "sleeping object" system where objects that are very far away or not moving go into a "sleep" mode where none of their components get processor time, but I've chosen a different approach based on no particular reasoning other than this one made sense to me and I like keeping the actual in-game object count low.
The actual Level data object stores the map as a series of "Spawners". Spawners, as you might imagine, spawn a Character (which is what I call an Actor or a GameObject) when they're activated, and are placed on the moral equivalent of a grid, despite not actually having a grid-like data structure for tracking them. The Character that the Spawner creates is stored in a separate array, so all Spawners that spawn the same Character point to the same Character template by reference.
I use a heavily modified version of the Sweep And Prune broad-phase collision detection system I've described before to determine when Spawners should be activated. The Level Scrolling System (henceforth LSS) stores four lists of "Spawner Buckets" that group the Spawners by one of their extents on an axis. So, there's one list of buckets for the minimum X positions, one list for the maximum X positions, one for the minimum Y positions, and one for the maximum Y positions. The LSS also keeps a persistent index into those buckets indicating where the current "window" into the Level is overlapping. Every time the LSS ticks, it determines the new minimum and maximum grid positions on the X and Y axes, and scrolls the persistent indexes on the spawner bucket lists accordingly. When the persistent index on one of the extents lists moves, then spawners are either added or removed from a "potentially triggered" set; when the window overlaps a spawner on both axes, then the spawner is actually triggered and emits its Character.
(Don't worry if that's incomprehensible. It's about three generations removed from the original algorithm and essentially can't be adequately described without pictures.)
Spawners store a three-state... state... indicating whether they're enabled, disabled, or have spawned their character. This prevents the game from spawning, say, the same Goomba twice in a row because you scrolled the screen backward slightly and then forward again. When a Character that was spawned in by a Spawner is deleted for being too far out of play, the Spawner is reset to Enabled; when the Character is deleted for other reasons then the Spawner goes to the Disabled state. (Now that I think about it, the middle state might not even be necessary, because there's no other mechanism by which a Spawner can return to a "ready" state.)
And that's basically it. The short version is that there's a compressed Level object, and a window scrolls over top of it emitting genuine objects into play, which are then deleted once they too far away and reset the Spawner that created them. This theoretically allows for very large levels without actually burning a lot of memory storing the objects until they're relevant to the player.
My plan for the coming week is to write unit tests for this system and hopefully get a visual sample ready. From there, it's on to the actual level editor.
My favorite musical instrument is the air-raid siren.
does anyone have any advice about how to decide whether to bin or continue working on a casual game? I've been working on a casual iOS spelling game for about 1 year, and at GDC I saw some interest from a publisher. The company publishes 'hyper-casual' phone games and bought ads for a 150 user engagement test for my game.
Primarily they were interested in Day 1 retention, apparently they pursue a publishing arrangement if the game has a D1 retention of 50%, which seems like a lot to me. My game went:
D1: 19%
D2: 11%
D3: 9%
Also of interest is the funnel for how many people completed each section of the game - with a lot of people falling off before completing the tutorial - which suggests the tutorial needs work?
The publisher more or less said to me that I should move onto new projects - but I think they're only really interested in big hitz when I would be satisfied with any outcome above 'literally nobody notices you released a game'
how do you decide whether sink more hours of your rapidly ending life into a project or say fuck it and start again
Posts
I recently took a UI break to focus on feature improvements, and I am now just a handful of steps away from finally adding multiple saves and a third character class. Right now you can only have one character, and have to kill the save to try the other class. This will obviously be a big boon to players and open up expansion and customization options quite a bit, and opens up a few ethical future paid expansion options like extra character classes and slots.
Plugging away at the character editor. All of the content file add/remove controls are there at this point. The most presentable thing I created this week was the "subset picker", a sort of I-don't-even-know-what-to-call-this title for a thing that lets you pick a particular subset of a texture, such as what the game ought to consider "walk animation frame 3".
You can left-click and drag to select the subset you want, which is clamped to the actual dimensions of the image file. The dimensions can be fixed to a specific target size, such as for selecting the icon the Character ought to be represented by in the level editor's tools pallet. I also just coded (like, today, in the span of an hour) a tool to do a sort of iterative flood-fill when you right-click on a non-transparent pixel that discovers the borders of a sprite. (Notice that the dust cloud coming out of Sonic's feet have been picked up despite not being connected to the bulk of his sprite.) I still have one more feature to include, which is the ability to middle-click and drag to explore more of the image, but otherwise the subset picker is good to go.
My target for next week is to have the animation editor finished. If I'm particularly disciplined (I won't be), I could also get the collision data editor going as well, which is tightly coupled to the animation editor in any event.
It's pretty smooth at 44fps, but I'm going to get some sleep instead of doing an iOS build.
Next up is animating the alien that's somewhere in there (it's briefly visible in the video in my previous post) and start looking at DOTS particle systems. So, DOTS making dots. I'll get my coat.
Has anyone here ever done an engagement test with a publisher? I've been working on a casual spelling game and I've been lucky enough to attract the interest of a publisher. They want to do an engagement test. Basically I give them a demo build of my game, they pay for about $500 worth of facebook ads, and if the numbers are good enough the relationship might proceed.
The studio is called Lion Studios and they seem legit as far as I can tell. The representative told me to work on about 20 levels and hand it over to them.
Has anyone ever done anything like this before? I've only tested my game with strangers a handful of times and it's difficult to know whether it will flop or whether strangers will be interested.
What should I focus on?
1. tutorial
2. Graphical Polish
3. Metagame
4. making the levels varied and interesting
help me out here!
https://medium.com/@alascii
So my last weekend was dedicated to experimented with various ideas
Saturday was about flying
Sunday was piloting a mech
I was so busy working on integrating the camera stuff that I still haven't tried coding in the touch controllers.
The roll locking I implemented is also dependent on the dot product of your forward direction and the force (gravity) vector. As you can see in the video this allows you to do loops or turn towards or away from the up direction without the ship trying to level, since you are parallel to the force the change in leveling direction is jarring. So you level only when your forward is perpendicular to up or down which is when you'd want to level your ship anyway. Basically you only auto-level when trying to fly along your true horizon. I still need to add roll controls though for all other cases.
The most distinct use of the effect I can remember was on SSX. When you pick up speed, you get additional percussion and higher volume. When you make a big jump, the bass and drums drop out to emphasize the altitude and let the wind sounds stand out.
My guess is that a) they're running multiple tracks stored in individual files, so they can mute the drums and such, running the remainder through an equalizer filter, or b) they're running finalized tracks without a dynamic equalizer and fading between them.
Has anyone tried to do this in Unity? Are there any assets or libraries to manage this kind of thing?
What you're looking for is called Adaptive Music. There are a few unity assets that will manage it for you. Psai Music Engine or Elias can show you how its done. Pretty sure i remember seeing a FMOD and WWise tutorial on youtube some years back,
Last week, I said that if I was particularly disciplined, I could have the collision volume editor finished, though I was pessimistic about the possibility. And as it turns out................................................................................ I was not particularly disciplined.
I did, however, hit my target of having the animation editor finished.
Animations in my engine have, in no particular order:
- A name by which they can be referred to other than their file name. This allows for a weak form of virtualization of animations, where you might not know what Character you're dealing with, but you can tell it to display the "Pain" animation as it's knocked back.
- The texture (expressed as an index into the associated Character's content array) to pull the sprites from.
- The default playback length in frames (this can be overridden at run-time).
- A playback type that indicates how they should play back, such as "progress forward and stop at the end", or "progress forward and loop back around to the start".
- An array of Frames that define the subset of the texture to display (selected quickly using the subset picker from last time) and the offset from local origin (useful aligning run cycles to the ground, for instance).
- Each Frame also has an association between collision volume names and the collision data to dispatch to the named Entity's collision volume component on transitioning to that frame.
Right now you can create collision data, but you can't actually update the data itself. That's my next task for the coming week.
I also did some work to figure out how to integrate my human-readable JSON files into MonoGame's data pipeline. Previously, I'd gone to the effort of finding a good open-source ZIP/Deflate library to use to compress my object files. As it turns out, MonoGame inherits from XNA the concept that every game ought to compress its content files-- the base class for the content processor includes a data compression step built-in. It'll still be handy to be able to deflate things like save files (which aren't part of MonoGame's content pipeline), but for now it doesn't feel worth the effort of re-compressing my data when MonoGame handles it for me. In doing all this, I discovered that the content reader class (you have to implement four classes to add your own data type to the content pipeline...) is afforded a reference to the ContentManager that's using it to load. Since my Character type carries around a bill of materials for the content it needs, that means that instead of having a separate step for loading the character file and then looping over its content path arrays, all that loading can take place in the Character content reader itself. And even better, my planned Level object works the same way, storing the Characters it needs. Which means that loading into a new level will, in the fullness of time, compress down to just one line of code! (... in a background thread so the loading process doesn't cause frame hitches which means that there will be a bunch of code dedicated to determining when that process has finished but don't pay too much attention to that, ONE LINE OF CODE)
I have also discovered that i mistakenly set my art templates to 2400 pixels high rather than something divisible by 720.
So rather than delete the work so far on 1 character....I can just resize the max height of the template, and scale the art from there.
All future characters will light up at the bottom, and not fly out over the top of the game window.
I should really right this stuff down in a text layer.
Yay, documentation.
http://www.fallout3nexus.com/downloads/file.php?id=16534
Yeah, I saw the FMOD stuff a while back, but that is a bit much. I'm messing around with updating the AudioSource.timeSamples value to see if I can keep tracks in sync. I'll let you know if it's a huge failure!
For a visual aid, see my last post.
I added visual editing of collision volumes associated with character animations. Aside from some convenience macros that I might need to make my Sonic knockoff, this interface is now finished. Huzzah!
My next major task is creating the "template editor" that creates and modifies component storage instances. Once that's done, Character editing will be feature complete and I can move on to the level editor.
Incidentally, I was playing Timespinner recently and something just felt... familiar about the game in a way I couldn't place. On a hunch, I looked up what engine they used, and wouldn't you know it? XNA 4!
So, I'm hitting a few framerate issues. You can barely see the dots on the road a bit beyond the empty road up front, and those cars are separate entities. Very low poly, but I think they're putting the game up to its limit on the iPhone. I definitely need a closer cutoff/crossover on all the detail levels, but that should be more than fine. The cars won't be visible from up top of the big towers, for example, and they shouldn't be visible more than a hex and a half away.
Most of all, it still looks white as f*ck on the phone, but I put in a bug report and let's hope that gets fixed at their end somehow...
Looking pretty good in the editor tho.
Owing to getting back into several different games this week, I didn't get much accomplished. Still have one thing to report, though:
The Component Storage Editor, which... edits the Component Storage class that... stores Components. The Component Storage class is both the main repository for entities and acts as an individual cloneable, fuseable collection. So individual Character files store a Component Storage that acts as the template for all instances of that Character. When you create a new copy of that character, their Component Storage is cloned and then fused with the main Component Storage used by the game. Right now the only thing you can do with this editor is create new Entities and then re-assign their values through text. (I decided against going with Unity-style form controls because I can't really see the dev effort put into doing so breaking even versus just... retyping the values when I need to. Collision volumes and sprites already have visual editors and other object relationships will be assigned through the Level Editor.)
I ran into some errors with reflection and parsing my custom fixed-point errors, which were 1) uninteresting enough that I lost interest in working on them, and therefore 2) are my first task for this next week.
I do some programming at work, but it's normally forcing SAS to do things it's not really meant to do, and more recently some stats stuff in R.
So I've no idea where to start, like not a clue. My very tiny programming background comes from an era where you had to start everything by scratch, which isn't the case now? There's unity, and unreal and others no doubt. I did a bit of Quake 2 modding but nothing major so I guess that's a bit like playing with an engine?
My goals are to play about with VR, it's been something I've loved for ages so anything that will let me write simple stuff for PCVR and (even better) the Quest. I'm guessing there's a difference there too with Quest being android based.
I've no commercial goals at all, it's just for my own fun. Where do I start? What tools do I need? Should I bother?
PSN: SirGrinchX
Oculus Rift: Sir_Grinch
Renpy visual novels
Gamemaker for 2d and many other things
Rpgmaker for various.."things"
Unity
Unreal 4 and source for fps
Pick a game you really enjoy, scale it down and try and make it
Use tutorials, youtube, and stackoverflow.
Lot of AAA are ugly under the hood, just enjoy.
http://www.fallout3nexus.com/downloads/file.php?id=16534
Unity and Unreal are the biggest/most well supported engines out there right now, so I'd just read up both of those, do a few basic tutorials for each one (start with the ones about using the interface rather than coding stuff just to get a feel for each one), then do a couple of their "build this game using these supplied assets" tutorials (I know Unity has a few of those, I assume Unreal does too). Obviously coding is a big part of the process, but even just getting comfortable with the basic interface can go a long way to building the confidence/know-how you'll need to make a hobby out of it. And there's a lot you can do on the hobbyist level without having to do much in the way of hardcode coding these day.
You can also try out some of the engines Royce mentioned, but in my opinion they're a little more specialized and not quite as robust as the two major ones.
Both have solid workflows to most VR systems.
You might want to do a single beginner's tutorial in each engine and decide based on the experience (ease of use, community support) which you prefer.
PSN: SirGrinchX
Oculus Rift: Sir_Grinch
Last week I said I had to handle some annoying odds and ends because I didn't handle them last week.
This week I handled some annoying odds and ends because I didn't handle them last week.
Odds ended and ends odded:
- I fixed the serialization of my fixed-point number type by giving it a TryParse method and more carefully examining the possible ways its format could be flummoxed. (I wrote a suite of unit tests to verify these cases. Unit tests! They're great.) So it's now easier to gracefully detect an incoming failure and tell the user their input is garbage, rather than just exploding.
- When saving to a file, I now shunt the original (if any) into a backup and then restore from the backup on failure or delete the backup on success. This means that if there's an error in the middle of writing the new file, you don't wind up with nothing but a half-written garbage file.
- Component Storage now supports adding and removing individual Components from Entities. This would be trivial if Components were reference types, but they're value types in my architecture due to semantic and data-alignment concerns. That means that the cost of adding or removing a Component is the cost of copying all of the other components of the same entity to a different Archetype (combination of component types). I've wracked my brain for cases when adding or removing individual components with any frequency would be necessary and haven't come up with any... or at least, none that would justify going back and re-architecting my component storage and System pipeline from scratch. Honestly, if anyone else has experience with ECS architectures and can speak to cases when adding or removing Components from Entities at runtime (not including parenting changes) was useful from a game-design sense, I'd like to hear about it.
Otherwise, I'm getting closer to having the Character Editor finished, which means I'm close to starting on the Level Editor. And after that... gameplay design! It's slowly coming together...
My schedule has been through an adventure that I don't feel like recounting here, but the summary is that I've taken my standard week off of work and all forms of personal responsibility to watch SGDQ. This means that I've accomplished exactly nothing in terms of game dev this week and feel no guilt about it.
To keep this post on-topic, though, I did at least put some thought into the challenge regarding viable use cases for transient components. The best application I could come up with is some kind of "burning" status; if an object has a BurningComponent, then the BurningSystem lowers its health, changes its associated sprite's tint, emits fire particles around the position of the burning object, and lowers the remaining time stored by the BurningComponent. When the remaining time hits zero, it deletes the BurningComponent from its Entity, so the Entity is no longer burning.
The counter to that is that I can achieve the same effect by creating an Entity with nothing but a BurningComponent which is parented to the Entity that's supposed to be burning. Then the BurningSystem does all of the previously-described effects, just with an additional check to ensure that the parent reference is still valid. If the parent reference is invalid, then the burn entity gets deleted that frame.
Or, to summarize: transient Entities can sufficiently emulate the effect of transient Components in the arrangement I have now, so I don't believe that finding a way to make adding and removing Components from Entities hyper-performant is worth sacrificing the optimizations I've already done.
This week's plans are to proofread the Component Storage Editor and move the loading of textures and collision data into the Animation object to avoid some data-shape issues I ran into previously.
My traditional bi-annual week of watching SGDQ has been followed by my traditional bi-annual week of watching all of the VoDs I missed while I was sleeping. Productivity was limited.
This week I moved the textures and collision data that are stored as content to being stored by the Animations that use them, rather than by the Character who owns the Animations. This avoids some data-consistency issues I was encountering in the editor at the cost of storing more references to the same data, but even if I load dozens of content files, that still only totals, like... 5k worth of references. It's nothing.
I've also done a little setup work to allow loading from raw files (uncompressed text and PNG files) where they're available rather than MonoGame's content pipeline. The primary motivation for doing this is allowing me to run the game out of the level editor to simulate something like Unity's "edit and play in a single editor" workflow, but after some thought I've realized that I sleepwalked into providing mod support for every game I make on my architecture, so that's neat.
My plans for next week are to validate that all the work I described above works as intended.
Twitch: KoopahTroopah - Steam: Koopah
"Finish It! Motivation and Processes"?
*Add to cart*
Hopefully this will be my last slow week for a while. Nevertheless... not much to report this week. I rearranged my content file formats a bit and modified the editor to account for the changes. I still need to do a full round-trip through the project editor to make sure that my content pipeline is still working before I can call that done.
The next step after that is to do some serious design work on the level format. I'd been planning to move on to the level editor as the next major phase, but it turns out that before you can edit levels, you actually have to have a level object to edit. I've had ideas kicking around for something that uses a modified version of the sweep-and-prune broad-phase collision detection system I built to handle the creation and deletion of items as they pass close to a particular reference frame (say, the player character or the camera), but nothing concrete enough to start laying down code. So, expect an essay next week on the specifics and, in all likelihood, and apology for it not being fully implemented yet.
Offering what i hope is the correct link as this bit of trickery might help someone in the future solve their problem.
When you leave a ship, you jump to that portal space.
When you board an enemy ship, you leap to a third space.
http://www.fallout3nexus.com/downloads/file.php?id=16534
https://www.pcgamer.com/15-years-later-warframe-is-finally-close-to-realizing-its-original-vision/
This article might have some more detail on it, but definitely has a great look at the trials of that team, and how that led them to work creatively with what they had and build on it to make Warframe what it is today.
Switch: nin.codes/roldford
I'm still working on the same game, FNS. For various reasons I've not made any huge leaps. A lot of the visual issues I've had were resolved by limiting the scaling in the game, which meant rescaling all meshes in Blender.
Currently, I'm working on modelling a ship that will likely be one of the player ships. I'm making it modular so I can reuse assets, but it's slow going as it has to be an almost 1:1 copy of a real-life model my partner got from a friend. He's relying on volunteer work for his TV pilot, and he wants to volunteers to see their work reflected in the game. It adds a slight challenge to the modeling work to keep things faithful!
I've also been sidetracked by a short story that is going to be published in a collection, and the need for a solid marketing setup to be in place for the release of that collection. A lot of the self-publishing stuff for stories and books transfers across to indie gamedev. Basically, it's A LOT of HARD work. Selecting the right tools, and even understanding the marketing, is crucial to not waste your time, effort, and eventually money.
In the coming days, as I come out of a bad cold, I'll be setting up Mailchimp, facebook pages, and various landing pages on my own website. I've been busy with CSS for the latter, getting it to scale properly. I've also revamped my 'about' section, as well as starting on CSS code for the 'press' pages which they should be able to copy paste.
All in all, it's a lot more work than simply getting games on a store.
Fixing up my site also has made me realize that for the next upcoming games I'm going to have to dig deep. I've long wanted to involve my fantasy and sci-fi worlds. But they are very world building heavy and best suited for (strategic) rpg gameplay. I've dabbled with some of that last year, but have yet to return to it since picking up Unity. Some small scale testing will set me back on that track.
But for the immediate future, aside from FNS development and my sidequest in marketing, I am going to try and get the Unity shader graph to work in my game Endless Azure, already out on android. The idea is to get color swaps going through shader graph so that I can model additional airplanes without having to worry about the four differing UV maps I needed in my handcoded shader. If it works, adding extra airplanes for an iOS release will be easier. And with all Schneider Trophy planes added to the game, I feel I can add in-game purchases.
I did my first game jam on the weekend and it was super fun!
Definitely recommend giving one a go if you have the chance. Here's the game we made: https://btkal.itch.io/dna-surfer
also does anyone have any tips about finding an artist to work with? We've got a pretty strong team but what we really need now is an artist who is interested in putting in the time for the next game jam
https://medium.com/@alascii
https://www.youtube.com/user/tthompso/videos
It goes over AI techniques used in games. It was interesting to see the AI system I developed for Parabolus is pretty much the same one used in Halflife (their one is more complex however).
All right, well. What I have finally settled on calling the "Level Scrolling System" isn't fully complete, but I got the basics of it banged out this week. Certainly enough that I could write a few unit tests to make sure that the behavior is basically correct. So this week's post is dedicated to just what the Level Scrolling System is.
It stands to reason that the kind of game object that's fastest to process is one that doesn't exist. Even if your level contains 100 enemies total, unless all 100 of them are on-screen and moving at the same time, you don't necessarily need to be tracking them at the same time. Plus, if you have an enemy like a Goomba that will brainlessly walk off the edge of a platform, spawning them in at the start of play when the player is half a mile away leads to the player finding Goombas in very low places on the level. An engine like Unity or Unreal solves this with a "sleeping object" system where objects that are very far away or not moving go into a "sleep" mode where none of their components get processor time, but I've chosen a different approach based on no particular reasoning other than this one made sense to me and I like keeping the actual in-game object count low.
The actual Level data object stores the map as a series of "Spawners". Spawners, as you might imagine, spawn a Character (which is what I call an Actor or a GameObject) when they're activated, and are placed on the moral equivalent of a grid, despite not actually having a grid-like data structure for tracking them. The Character that the Spawner creates is stored in a separate array, so all Spawners that spawn the same Character point to the same Character template by reference.
I use a heavily modified version of the Sweep And Prune broad-phase collision detection system I've described before to determine when Spawners should be activated. The Level Scrolling System (henceforth LSS) stores four lists of "Spawner Buckets" that group the Spawners by one of their extents on an axis. So, there's one list of buckets for the minimum X positions, one list for the maximum X positions, one for the minimum Y positions, and one for the maximum Y positions. The LSS also keeps a persistent index into those buckets indicating where the current "window" into the Level is overlapping. Every time the LSS ticks, it determines the new minimum and maximum grid positions on the X and Y axes, and scrolls the persistent indexes on the spawner bucket lists accordingly. When the persistent index on one of the extents lists moves, then spawners are either added or removed from a "potentially triggered" set; when the window overlaps a spawner on both axes, then the spawner is actually triggered and emits its Character.
(Don't worry if that's incomprehensible. It's about three generations removed from the original algorithm and essentially can't be adequately described without pictures.)
Spawners store a three-state... state... indicating whether they're enabled, disabled, or have spawned their character. This prevents the game from spawning, say, the same Goomba twice in a row because you scrolled the screen backward slightly and then forward again. When a Character that was spawned in by a Spawner is deleted for being too far out of play, the Spawner is reset to Enabled; when the Character is deleted for other reasons then the Spawner goes to the Disabled state. (Now that I think about it, the middle state might not even be necessary, because there's no other mechanism by which a Spawner can return to a "ready" state.)
And that's basically it. The short version is that there's a compressed Level object, and a window scrolls over top of it emitting genuine objects into play, which are then deleted once they too far away and reset the Spawner that created them. This theoretically allows for very large levels without actually burning a lot of memory storing the objects until they're relevant to the player.
My plan for the coming week is to write unit tests for this system and hopefully get a visual sample ready. From there, it's on to the actual level editor.
does anyone have any advice about how to decide whether to bin or continue working on a casual game? I've been working on a casual iOS spelling game for about 1 year, and at GDC I saw some interest from a publisher. The company publishes 'hyper-casual' phone games and bought ads for a 150 user engagement test for my game.
Primarily they were interested in Day 1 retention, apparently they pursue a publishing arrangement if the game has a D1 retention of 50%, which seems like a lot to me. My game went:
D1: 19%
D2: 11%
D3: 9%
Also of interest is the funnel for how many people completed each section of the game - with a lot of people falling off before completing the tutorial - which suggests the tutorial needs work?
The publisher more or less said to me that I should move onto new projects - but I think they're only really interested in big hitz when I would be satisfied with any outcome above 'literally nobody notices you released a game'
how do you decide whether sink more hours of your rapidly ending life into a project or say fuck it and start again
https://medium.com/@alascii
Simple: Is it still fun to work on? If not, can I still learn things while continuing to work on this?
If not, I pick a bigger challenge.
Commercially it's a different story, but I'm not qualified to answer that.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.