I changed my damage system a bit and it feels much better. I decreased and decoupled the iframes from the hit animation and made them much shorter. I've also added a toughness roll to see if the enemy can be interrupted when mid attack. It's working out very well, you can cut down an enemy much faster but now they also have a chance hitting you too if you're just flailing your swords.
Before ranged attacks were dangerous but for melee you just interrupted everything.
I changed my damage system a bit and it feels much better. I decreased and decoupled the iframes from the hit animation and made them much shorter. I've also added a toughness roll to see if the enemy can be interrupted when mid attack. It's working out very well, you can cut down an enemy much faster but now they also have a chance hitting you too if you're just flailing your swords.
Before ranged attacks were dangerous but for melee you just interrupted everything.
Now to start working on audio.
Please please Please implement the inverse ninja law into your game. i.e. when the level begins all the ninjas are slow and have little health but as you go through them they become tougher until the last one standing is a complete badass.
I changed my damage system a bit and it feels much better. I decreased and decoupled the iframes from the hit animation and made them much shorter. I've also added a toughness roll to see if the enemy can be interrupted when mid attack. It's working out very well, you can cut down an enemy much faster but now they also have a chance hitting you too if you're just flailing your swords.
Before ranged attacks were dangerous but for melee you just interrupted everything.
Now to start working on audio.
Please please Please implement the inverse ninja law into your game. i.e. when the level begins all the ninjas are slow and have little health but as you go through them they become tougher until the last one standing is a complete badass.
I already had a Ninja boss at the end of the forest, I could put that in since this is a bonus side area. You only face a handful of Ninjas on the main path but if you go in their camp there is like 30 to fight before their leader and a chest or two.
I can see the argument now of why Microsoft instituted a "No Easter Eggs" policy. I'm in the process of updating the graphics for the game I'm porting, and not only do I have to get rid of the copyright-infringy Star Trek:TNG interface, The old artist from 27 years ago like to sneak in stuff that will not fly if I'm to have a published release. I just ran across one that has to deal with the dialog boxes. Each dialog box in numbered in the upper right with a three digit code. For example:
000 = Alert
001 = Info
002 = Options
So as I'm redoing these interface screens I come across this...
I changed my damage system a bit and it feels much better. I decreased and decoupled the iframes from the hit animation and made them much shorter. I've also added a toughness roll to see if the enemy can be interrupted when mid attack. It's working out very well, you can cut down an enemy much faster but now they also have a chance hitting you too if you're just flailing your swords.
Before ranged attacks were dangerous but for melee you just interrupted everything.
Now to start working on audio.
Please please Please implement the inverse ninja law into your game. i.e. when the level begins all the ninjas are slow and have little health but as you go through them they become tougher until the last one standing is a complete badass.
In completely unrelated news. I thank have come up with an idea for some DLC.
The video is crummy, but it gets the point across : I made something. It's the smallest thing ever, it won't be released, I don't think it's complete in the first place, but it exists, it works (if barely and full of bugs), and I've learned a fair bit from making it. Mostly about how to handle collisions, and I'm certain I'm doing it wrong anyway. Collisions are evil.
Well, here's to more projects. I've got more simple stuff in mind to get the hang of this.
Rend Presents: The Kupi-style. A Friday Status Report For: Untitled: Tactics
Lines Written this week (excluding generated code): ~7,400
Total number of unit tests: 165
I have been getting up at 430 AM so that I have a solid two hours of work on my game before going into work. I am most productive in the morning, and so I figured I'd keep at least SOME of that time for myself. It's been doing great for me though, as I've gotten a lot of serious work done this week and last week due in no small part to that time.
This week I have implemented Line of Sight, the Basic Move ability, combat stats and the damage formula, input and the input router, a non-unity implementation of random numbers (since I can't use the Unity one in my unit tests), and a lot of upgrades to my A* pathfinding algorithm - and, nearly 100% test coverage of my code.
But by far the two systems that have been most fun to work on are AI and Cutscenes.
One design decision I've made is to make almost everything that has a material impact on the game's state into a cutscene. Moving pieces around the board, dealing damage, moving the camera, basically a huge swathe of systems in the game which are not directly resultant from human input are cutscenes. The reason I've made this decision is that it makes it very, very easy to script any number of things: this will come in handy during the tutorial battle for sure. Another great boon of this design is that, since I can import cutscenes via XML, I can use them to design the effects of special abilities, so that the majority of the special abilities in the game won't have to be hard coded.
For AI I've implemented a behavior tree (the entire skeleton of it) plus several action nodes, including a node which acquires the nearest target (hostile or friendly), a node which acquires a space to move to which is at an exact range from a given location (for, say, an archer or mage), and a node which acquires a space to move as close to a target location as possible (for charge and attack). Additionally, I've got nodes in the tree which spawn components to begin the Basic Move ability and which target specific locations. Once I implement the wait AI node, I'll be ready to have a smoothly functioning chase-and-kill AI which can move around the board and try to attack you. I've also made the AI xml-importable, so writing that will be a breeze.
That's my first major milestone (a technically-working battle), and I think I'll have that done in a few days at most, hopefully less with the weekend looming and a whole lot of free time. My general roadmap after this is to do a single relatively feature complete battle, which will involve a lot more cutscene work (oh you KNOW there's gonna be those text boxes though), followed by a non-tactical interface, including a world or town map, party panel, ability to equip items and weapons, and of course saving and loading the game.
But, all that is to come. Week one has completed successfully.
So here's a funny thing. I've run into a bout of icon issues. Once again I'm re-drawing 27 year old graphics to give them a slight resolution boost, and I have come across some pretty archaic icons. My favorite is the PageUp/PageDown icons that are so old, they were taken teletype keyboards. I decided to keep them as they kind of fit the ascetic.
The save icon caused an interesting interaction with my 14 year old nephew who is playtesting the game. Here's the old icon as it shows across the menu bar.
So I get feedback note from my nephew and he tells me something really strange...
"The save icon is upside down"
I was kind of struck by this. I didn't realize there was an orientation, but sure enough, a quick google image search for "save icon" shows, that, yes, in the intervening years that little floppy got flipped. I found it so strange that my nephew would spot something so innocuous, especially since I haven't seen a floppy disk in years. In fact, I haven't seen one in ages. This sparked a question I decided to ask my nephew.
Me: "Say, do you know what the save icon represents?"
Nephew: "Isn't it a lock box? The keyhole is on the bottom which would make it hard to open."
Yea, evidently he always saw it as a secure storage box. Basically one of these.
I guess what I'm trying to say is you get interesting feedback from playtesting.
== Ninja Edit ==
For the record, the icon looks like this now.
Kupi's Unjustifiably Abridged Weekly (Ha!) Friday Status Report
I've moved out of the design phase and into the actual implementation of my ECS architecture, and run into the predictable fallout of the theory-reality divide. Fortunately, everything I'm dealing with is more along the lines of indexing problems and uninitialized memory rather than the more fatal "the type system fundamentally rejects what you are attempting to do". I'm working my way through the various features I've plotted out for my "Component Storage" class, which is capable of storing an arbitrary set of struct arrays and coordinating how various combinations of components share that space. (Remember, half the point of this system is to keep all of your entities packed into the same regions of memory so the CPU doesn't invalidate the cache as often.) The specifics of how it manages those different entity combinations (which I've taken to calling "Archetypes" since I saw one person somewhere who I can't even remember now refer to them in that way) and lets you do super-fast queries for the series of Archetypes that contain specific Components I'll have to leave off to another time, because EVO is on and my attention is too fragmentary to explain something in words that it took me having to draw out a visual aid for myself to grok the first time.
My favorite musical instrument is the air-raid siren.
Whew! I just spent the latter but of two weeks updating the graphics for ROE. I'm almost halfway done. Also, thanks to @ChicoBlue who helped with the characters.
Here's one of the spritesheets in it's original 320x200 resolution.
And here it is in 4x resolution (Spoilered for big)
On of the things I'm most proud of is that I recreated the spinning globe in 3D, while matching the original landmass. This means I had to unwrap that tiny 4 color globe into a little-bitty map, create a new HD map, and then render it with clouds and oceans and stuff...
No joke.. Look
Of course, obligatory screenshot.
I have some graphic artifacts to clean up. The game wasn't originally designed to run in 1280x800, so there are crufties all over the place. I can begin to make the tutorials now. I may have a new beta demo available for download with the new graphics. . (I have a post in the Indie forums)
So I've move on to replacing the 3D ships in the game, but I'm unhappy with the result. (Picture under spoiler)
Now this is just a tanker, and pretty simple. I have just the flat vertex colors above, and I decided to give the ship a normal map to make it look more ... "realistic", but not happy with the result. Should I go all out and just old-school the textures? I'm kinda leaning towards the top I guess.
Now this is just a tanker, and pretty simple. I have just the flat vertex colors above, and I decided to give the ship a normal map to make it look more ... "realistic", but not happy with the result. Should I go all out and just old-school the textures? I'm kinda leaning towards the top I guess.
The author is the developer of Megasphere which has quite possibly the best pixel art ever made. But not only is the art the best his lighting, particles and animations are awesome.
Everyone considering doing a pixel art game should look at Megasphere and weep. It is the pinnacle to strive for in terms of graphical perfection.
I figured out the problem with the proof of concept tunnel cart racer. Turns out I was applying gravity using AddRelativeForce instead of AddForce.... whoops.
That meant gravity at the top of the tunnel was the reverse of what it should have been but worked normally at the bottom of the tunnel and produced weird swimming effects on the sides.
I used the Sherlock Holmes debugging technique of making a list of every assumption I could think of then explicitly testing those one by one. debug.drawray was very useful
When I was reading "Adding normals to sprites" struck me as super strange because my 3D modeler mind went to the concept of a normal vector for polygon. My thought was, "Wouldn't the normal vector of a sprite just point straight out of the screen?". Turns out the article is about normal mapping, which is something I never thought about doing to a sprite. Neat-o
Sadly, I need to learn about using pixel shaders but they are an enigma . The game I'm working on is altering colors by grabbing a bitmap section, checking every pixel in a for/next loop and altering the bitmap if the pixel is equal to a value. It's super slow and I think is dragging down slower machines. Just every time I see info about a pixel shader it's either really vague or goes in some crazy OpenGL/Direct3D low level graphics card mathematics gunk. All I want to do is when the shader is "on" to draw pixels a particular color.
It shows me how to make a shader object, but then say I need to attach the source code to a shader to make it work. What source code? What language? How do you "program" a shader? When I look up a shader language it, it gives me like 30 of them with stuff like "fragmets" and you have to pass vectors and stuff. It seems so complex. Can someone kind of clue me in on how this all works it would be sweet.
So the spaceship parts in my game are made by companies with different logos. Here's the original graphic below...
It's super tempting to just run this all through am upscaler like hqx or Waifu2x, but it just looks awful. In the end I just sat down with Inkscape for two days and redrew them all
Here's what it looks like when using hqx to automatically scale it
and Waifu2x (Only upsacled once, but you can see the artifacting)
Don't rely on upscalers to do you work for you *cough* Squareenix *cough*
I was searching the internet for mentions of my game (as you do) when I noticed a page exclaiming a "free download" of it. This is amazing. My game isn't out yet but someone has gone back in time and made it available to us. I'm almost tempted to grab it and see how it turned out.
In other news, I added fog to the game. It took a while to make it look realistic but I think I got it. Some of the levels (especially those that have a background which contrasts heavily with the fog) look stunning. Of course now I have to update the screenshots on my Steam page.
I was searching the internet for mentions of my game (as you do) *snip*
I can highly recommend setting up a google news alert for the name of your game - a good way to make sure you're not missing out when someone writes about it!
Ok I've only been able to put some stolen hours every once in a while into this, but progress!
It's super unbalanced right now, where I think sort of everything is overpowered? If you don't make mistakes, you win really easily, but if you do make mistakes, you lose really easily.
I think the next step is adding an in-between bosses thing where you can actually tell what's happened after each boss, with progress pointed out, instead of the breakneck pace of just respawning immediately.
I have 1.9.4 downloaded as a tar.gz file. And I have Python 3.7.0 installed. Is the tar.gz file a wheel? Am I supposed to rename it and then use PIP to install it? (I'm on Windows 10.)
Drez on
Switch: SW-7690-2320-9238Steam/PSN/Xbox: Drezdar
0
AkimboEGMr. FancypantsWears very fine pants indeedRegistered Userregular
I have 1.9.4 downloaded as a tar.gz file. And I have Python 3.7.0 installed. Is the tar.gz file a wheel? Am I supposed to rename it and then use PIP to install it? (I'm on Windows 10.)
For those interested, I uploaded a new Beta demo of my game. You can get it in the indie forum. I fixed an issue where the demo mission was crashing. I also updated the theme some so now it's a bit prettier, but I'm not quite happy with the UI. I would adore some feedback.
==Ninja Edit== Demo pulled, I super goofed up the intro - It will be back soon (This is what I get when I comment out the titles when compiling a debug build)
Demo is back up. Watch your variable types guys! Unsigned ints can't make things go backwards!
I have exciting news!
While I was updating the credits in the game, I decided to look up the names of the original developers. I already knew the main developer as he was the one I got the source code from. I kind of got into the mindset of "I wonder what they are doing now". I started with the original art director, Maurice Molyneaux. Turns out, over the years he was the director of product development for Namco, Chief creative officer for Nuvo studios, screen writer for a $18 Million dollar feature film, and has worked with THQ and Psygnosis back in the PS1 days.
I decided to send him a letter.
Turns out he was so enamored with what I was doing, he went into his zip disk archive and info dumped everything he had on the original art direction for the game. Old articles, reference art, and lots of cutting room stuff. Then I got stories about how the game was made and he offered advice on.. well.., whatever the hell I'm doing. (He seemed to have a better idea then I do). He pushed me in a few good directions. It was a real eye opening experience.
He even tweeted about me
I have 1.9.4 downloaded as a tar.gz file. And I have Python 3.7.0 installed. Is the tar.gz file a wheel? Am I supposed to rename it and then use PIP to install it? (I'm on Windows 10.)
Oh, what the hell, somehow I got unsubscribed from this thread.
Is there an obvious way in Unity to draw a specific frame of a sprite AnimationClip stored in a ScriptableObject so that I can adjust hitboxes for each frame? Right now, I'm doing it in the inspector with GUI.DrawTextureWithTexCoords, and it just can't be this ridiculous.
// In class MoveEditor : Editor
// collect keyframes
foreach (var binding in AnimationUtility.GetObjectReferenceCurveBindings(Clip))
{
foreach (var keyFrame in AnimationUtility.GetObjectReferenceCurve(Clip, binding))
{
sprites.Add(keyFrame.value as Sprite);
}
}
// render selected keyframe
Sprite s = sprites[currentFrameIndex % sprites.Count];
Vector2 texSize = new Vector2(s.texture.width, s.texture.height);
Rect srcRectPixels = s.textureRect; // I'm not sure how this differs from s.rect
Rect srcRectFraction = new Rect(srcRectPixels.position / texSize, srcRectPixels.size / texSize);
var srcToScreenRatio = Mathf.Min(Screen.width / srcRectPixels.width, Screen.height / srcRectPixels.height);
var destRect = new Rect(SPRITE_DRAW_POS, srcRectPixels.size * srcToScreenRatio);
GUI.DrawTextureWithTexCoords(destRect, s.texture, srcRectFraction);
Finally got bloom to work. Didn't want it too strong so I set it to be a neon like glow. Would love to get some depth of field to make the far off space station slightly out of focus (to make it look very far away) but I can't get it to work.
It is finally getting close to "Beta" very excited now!
Rend's Weekly Periodic Dev Log Updates
Between going to evo a couple weeks ago and crunch time at work, I've neglected to come back and update the thread on my progress, but progress continues at a good clip!
Since I've run into crunch time at work, most of my time after work has been spent trying to decompress from particularly stressful days. However, I'm still waking up Way Too Early (tm) in order to reclaim a couple of hours each day prior to work, so that I continue to work on the game each and every day.
Since a few weeks ago I accomplished my first major milestone, which is a technically playable battle! That involves at least one friendly, human controlled piece, and at least one enemy, AI controlled piece. The AI must be able to acquire and choose targets for movement and attacks, where the human player must be limited on what actions they can take each turn. That much is now done!
Next milestone is a much more "feature complete battle." To this end I've done a lot of basic stuff, such as click-and-drag for camera movement, and refactoring a lot of hard-coded constants out as configuration components which are loaded at runtime via xml.
In addition, I've also implemented several fancier, flashier, more impressive systems such as my secondary resource system, morale, text boxes (with portraits), temporary buffs and debuffs, and a basic defend action to go along with basic move and basic attack. Also, floating combat text!
Just this morning I implemented tooltips and added them to the three basic action buttons, and I added four different orientations to them (top left, top right, bottom left, bottom right, of the object spawning the tooltip). They're not smart enough to know which orientation to use yet but that will come later. For now I set them manually.
I also solved a couple bugs I've been building up this morning, including a bug which caused all text boxes past the first to automatically and instantly advance to completion, without animating the text (this is because the input which advanced past the previous text box was not being consumed, and as such the next text box was assuming it applied).
Another bug was that the floating combat text for the basic attack move was showing raw damage numbers and not final damage numbers, which is because for some reason I thought that conversion of raw damage to final damage should be done in the system which actually dealt the damage. Turns out that was really dumb, and at least one other component (and likely several) will need to know what the final damage will be, given raw damage, the actor and target, etc. So I've refactored final damage calculation into the same utility class which calculates the damage modifiers for armor and attack vs defense stat differentials.
The trello is growing as fast as it's shrinking, but considering how high level it was when I finished my prior milestone that was nothing if not expected. However I'll be getting to the REAL good stuff soon: classes and subclasses for fighters, plus the special abilities that go along with those classes. In preparation for that I'm going to have to move a lot more of the cutscene elements to be xml-importable, as well as make targeting strings xml-importable.
(Background on what it means for my game to have xml-importable targeting)
The way targeting works in my game is that each move, once it becomes relevant, spawns a string of target requests. Each request comes with an origin point, a range, whether that range is line-of-sight or walking, and a list of flags determining whether you can target ground, self, ally, enemy, and neutral. The targeting system checks selected spaces against those parameters and either targets/confirms that space or aborts the target string and currently selected action. If a target request is targeted and then confirmed, it moves on to the next target request in the string, and once it has no more targets and the final target is confirmed, the action fully executes.
So essentially if I can import the target string in xml, which should be fairly easy since the origin points are never arbitrary, and I can also import cutscenes in xml, then I can write entire battle actions in xml. "This is your target" "this is what you do with those targets"
At that point I can refactor the basic moves into xml if I wish as well, instead of having them hardcoded. This should be a HUGE boon to my workflow as well as possibly making the game super easily moddable if that's a thing.
Mmm, yes that's what I want.
Anyway, things progress smoothly! Still putting in at minimum two hours a day, more if I've got the time and energy after work, and progress is steady.
So my adventure with the old staff of this game continues. For those following along, I got in touch with the art director for the game I'm porting. He wanted for me to give him a call...
WOW! The guy hangs out and is friends with the old Star Trek:TNG staff. Evidently, he pitched a few scripts to them back in the day. He hangs out with Mike Okuda, the art director for TNG, Andrew Probert, concept designer for the Enterprise. He also hung out with Matt Jefferies before he died. He's getting me in touch with someone who can help update the UI to my game.. Also. @ChicoBlue made some art for me that wraps around the new 3D models nicely.
(Spoilered for big)
This was the kick in the pants I needed to finish this project!
TIL that the Any() method in Linq will produce garbage. I noticed that my ECS architecture (which I still owe you guys an explanation of) was GCing every ten seconds while in a test program that did more or less literally nothing, and by process of elimination I finally managed to determine that it was the function that finalizes entity deletions, operating
while ( entitiesToDelete.Any() )
that was causing it. When I changed it to entitiesToDelete.Count > 0, no more GCs. That's such a weird thing to make garbage on, too, since most of the time they're good about determining if the collection you're iterating over implements a better interface.
This is what I get for prioritizing semantics over implementation details.
My favorite musical instrument is the air-raid siren.
I have 1.9.4 downloaded as a tar.gz file. And I have Python 3.7.0 installed. Is the tar.gz file a wheel? Am I supposed to rename it and then use PIP to install it? (I'm on Windows 10.)
TIL that the Any() method in Linq will produce garbage. I noticed that my ECS architecture (which I still owe you guys an explanation of) was GCing every ten seconds while in a test program that did more or less literally nothing, and by process of elimination I finally managed to determine that it was the function that finalizes entity deletions, operating
while ( entitiesToDelete.Any() )
that was causing it. When I changed it to entitiesToDelete.Count > 0, no more GCs. That's such a weird thing to make garbage on, too, since most of the time they're good about determining if the collection you're iterating over implements a better interface.
This is what I get for prioritizing semantics over implementation details.
That sucks cause it is better code to use any than count but yes removing all instances of the GC in the gameplay loop is a must.
I general linq is somewhat risky to use in critical parts. It was design for business cases, not gaming.
Oh yeah, I'm quite well aware. The thing is that they recently reimplemented a lot of the enumerator types to be structs instead of classes, because so many of them are short-lived objects that rarely ever leave their stack frame. That's why this case took me by surprise-- it's not like I was passing in a lambda with a captured variable or something like that where the garbage generation is reasonable in retrospect.
EDIT: Aaagh, I just realized that this happens because of something I've been cautious about a lot lately anyway. You have to be careful with structs because of boxing. The enumerator is a struct, yes, and Any() is an extension method on IEnumerable. So the enumerator gets passed to Any() as an IEnumerable, which results in a boxing operation and garbage gets produced.
Kupi on
My favorite musical instrument is the air-raid siren.
Ha ha actually not. I've reached a point where it feels like I've stressed all the major code paths in my framework, at least enough to create a presentable little tech demo on my favorite fields of cornflower blue. There's a long way to go before it feels like a "game", but the groundwork is there (he says yet again).
For those of you who don't hang off my every word and remember every details of my posts from a quarter of a year ago (you're forgiven), a quick refresher on what I mean by an "intellectually pure" ECS architecture: as typically defined, ECS separates the world into three major provinces: entities, which are literally nothing except for associations between components (indeed, in my system an entity can be fully represented by an integer), components are nothing more than pieces of data (my components are almost entirely without behavior), and systems operate on streams of entities that have specific combinations of components. (For instance, a simple movement system might take every entity with a Position and a Velocity, and update the entity's Position to increase by its Velocity.)
Why try to implement my own ECS architecture rather than use an off-the-shelf engine like Unity or Unreal? I mean, the only bulletproof answer to that is "because it entertains me". I recently got a job with one of the big tech giants, so my 9-to-5 life mostly consists of trying to navigate an incomprehensible labyrinth of code and tools that someone else made that are difficult to diagnose, writing maybe five lines of code on a good day with all the remaining time being investigation and build. I don't really want to come home to spend my limited game-development time trying to navigate an incomprehensible labyrinth of code and tools that someone else made which are prone to failing in ways that are difficult to diagnose. But, more seriously, a few more reasons:
- The ECS architecture lends itself well to maintaining cache coherency, which can be a hidden bottleneck to performance. I don't put much stock in this point, just because the .NET Framework is made by smarter people than me who have probably already set up the runtime to consider things like that.
- Testability. A system is allowed to make any changes it wants on the components that exist in the data storage area. If you make writes into the data storage transactional (meaning, writes are delayed until the system stops processing), there is no change in the data storage until the end of each system's processing-- which means that a system's processing operation is the moral equivalent of a pure function. Pure functions are really easy to test: same input, same output. This also means easy debugging: if a system's processing function crashes, we maintain the game state in an unmodified state just before the function call-- serialize it to a file, email it to the developer, and you have a snapshot of the moment just before impact.
- Parallelization: I don't plan to get too fancy with my system pipeline (I'm just making a Sonic knock-off, after all), but if it really needs it, the bit about pure functions up there also means that parallelization is much easier than it would be otherwise. The fewer class instances with mutable state, the easier it is to coordinate work between multiple cores.
- You can do some really neat tricks by sending the same data through multiple pipelines, which I'll discuss below. This simplifies a number of really painful, bite-you-in-the-ass scenarios that you often run into in game development.
- In the worst-case scenario, I'm creating a C# DLL, so I can always drop the entire thing into Unity if MonoGame turns out to be insufficient in some respect. (If it's good enough for Stardew Valley, though, it's good enough for me.)
The cornerstone of my ECS architecture is a class called "ComponentStorage". As you might imagine, ComponentStorage's main responsibility is storing components in a way that's amenable to looking them up later. The way I settled on handling it was to give ComponentStorage a dictionary mapping Types (the C# reflection object) to arrays of component structs. The components stored in these arrays are then associated with what I took to calling "archetypes" after seeing the term used once. An archetype is a specific combination of component types-- for instance, if a "rock" game object has the components Rock (indicates it's a Rock), Position, Velocity, and Hitbox, there will be an Archetype instance describing which spans of the component arrays belong to the Rock archetype.
This is very difficult to put into words such that it transmits well, so instead have some ASCII art that I hope will make it clearer, using my previous example of a simple Legend of Zelda-like where Kupi tries to push rocks onto switches in order to open doors:
The archetypes are stored in a list, and store how many instances of that archetype exist, along with the total available capacity for that archetype. Then, they also store the index at which their "stripe" begins in each component array (that's the "@ X"). In the component storage segment, I've visualized the arrays, with the numbers indicating "real" instances (and which archetypes they belong to by index in the list), with underscores representing empty space. Basically, it's like your standard List<T> instance, except I'm keeping multiple lists in the same memory buffer. There's a lot of bookkeeping involved in expanding the individual stripes and whatnot but I won't bore you with the specifics. It works, though! I swear it works.
You'll notice that with each archetype also has a thing that says "(Next: X)" for each component. For each component type in an archetype, the archetype stores the index of the next archetype in the archetype list that contains that component. This is how you can get fast queries for subsets of components: from any given archetype, you take the maximum next index for each component you're looking for and skip to that index, or stop iterating if any next-index does not exist. Let's say we want every archetype that has a Position and Hitbox (for our collision detection phase). We start at "Rock". The maximum next index for Position and Hitbox is 1, so we go to "Switch". The maximum next index of Position and Hitbox in "Switch" is 3, so we skip "Floor Tile" and go to "Wall". And likewise to "Door" and then "Kupi", where iteration stops because neither Position nor Hitbox has a next archetype index.
But what if the first archetype doesn't have your target component combination? I use the sentinel pattern, meaning there's a special archetype that isn't in the list and contains every archetype. All scans start at this special first archetype, which lets them jump to the first archetype that satisfies all of the component constraints.
I'm starting to get that "you're talking too long" feeling, so I'll pass over the specifics of how entity queries work other than to say that you can probably figure out how you go from a series of archetypes to a series of array accesses.
A quick aside: MonoGame is structured such that the main game loop consists of two phases: Update and Draw. In an ideal world, MonoGame calls Update() and then Draw() and then sleeps for the remainder of your frame duration. If the Update() call takes too long, it will skip the Draw() call, unless it's skipped the Draw() call too many times, in which case it skips the Update() call instead and your players get really angry. The ECS architecture I've created plays nicely with this paradim. An object called a Context combines a ComponentStorage with a list of system classes to execute in order on the ComponentStorage. But the same ComponentStorage can exist in two separate contexts-- for instance, an Update Context with a list of systems that handle the gameplay logic, and a Draw Context with systems that handle the rendering of the game state.
But that's not all! (I'll let you go soon, I promise!)
If you've been a young, starry-eyed game developer at any point in the past, I'll bet you've run into this situation. You've been hacking away at your game for a while. You've prototyped some fun hero controls, made a couple monsters, designed a level or two, and so on. But you've been entering and leaving gameplay by jumping between your editor and the main gameplay mode. As you're considering what practical features the game needs, you have this creeping sense of dread as you start considering how to implement pausing the game. If you're in a Unity or Unreal-style engine, you've probably spread your gameplay logic over the Update() override for a bunch of different Actors or GameObjects or whatever they call them. And each and every one of them has to be updated to respect the pause state, and you're plagued by the occasional monster that keeps running around when you pause the game or a sound effect that keeps playing. There might be some kind of global time-step variable that you can turn down to 0, but you have to make sure it doesn't affect the pause menu, too, or the player won't be able to interact with the pause menu itself. What a pain in the ass!
In my ECS architecture, here's what happens: when the player presses Pause, you create a new Context containing the pause menu's components and its systems. You emit an event to the systems in the gameplay context that the game is stopping in case they need to clean up (like by pausing sound effect playbacks). Then you stop telling the main game context to run. But you keep telling the Draw contexts to run, so the player can see the main game below the pause menu. And when the player chooses to unpause, you tell the main gameplay context "Okay, we're resuming" and start telling it to process each frame again.
Boom, instant pause logic. None of the components have to know it exists. Most of the systems don't even need to know it exists. dusts off hands
My next steps are integrating a simple collision library I wrote yonks ago into this system, and moving on from there to some of the other generally-applicable system types, like sprite animation, sound management, level definitions, and so on, before moving on to something genuinely gameplay-like.
My favorite musical instrument is the air-raid siren.
Bunch of assets in latest humble bundle. Unity focused but I imagine they could work with any engine. At $15 for the highest tier it seems like a worthwhile investment even if you aren't going to use it immediately.
Posts
Before ranged attacks were dangerous but for melee you just interrupted everything.
Now to start working on audio.
Please please Please implement the inverse ninja law into your game. i.e. when the level begins all the ninjas are slow and have little health but as you go through them they become tougher until the last one standing is a complete badass.
I already had a Ninja boss at the end of the forest, I could put that in since this is a bonus side area. You only face a handful of Ninjas on the main path but if you go in their camp there is like 30 to fight before their leader and a chest or two.
000 = Alert
001 = Info
002 = Options
So as I'm redoing these interface screens I come across this...
In completely unrelated news. I thank have come up with an idea for some DLC.
The video is crummy, but it gets the point across : I made something. It's the smallest thing ever, it won't be released, I don't think it's complete in the first place, but it exists, it works (if barely and full of bugs), and I've learned a fair bit from making it. Mostly about how to handle collisions, and I'm certain I'm doing it wrong anyway. Collisions are evil.
Well, here's to more projects. I've got more simple stuff in mind to get the hang of this.
For: Untitled: Tactics
Lines Written this week (excluding generated code): ~7,400
Total number of unit tests: 165
I have been getting up at 430 AM so that I have a solid two hours of work on my game before going into work. I am most productive in the morning, and so I figured I'd keep at least SOME of that time for myself. It's been doing great for me though, as I've gotten a lot of serious work done this week and last week due in no small part to that time.
This week I have implemented Line of Sight, the Basic Move ability, combat stats and the damage formula, input and the input router, a non-unity implementation of random numbers (since I can't use the Unity one in my unit tests), and a lot of upgrades to my A* pathfinding algorithm - and, nearly 100% test coverage of my code.
But by far the two systems that have been most fun to work on are AI and Cutscenes.
One design decision I've made is to make almost everything that has a material impact on the game's state into a cutscene. Moving pieces around the board, dealing damage, moving the camera, basically a huge swathe of systems in the game which are not directly resultant from human input are cutscenes. The reason I've made this decision is that it makes it very, very easy to script any number of things: this will come in handy during the tutorial battle for sure. Another great boon of this design is that, since I can import cutscenes via XML, I can use them to design the effects of special abilities, so that the majority of the special abilities in the game won't have to be hard coded.
For AI I've implemented a behavior tree (the entire skeleton of it) plus several action nodes, including a node which acquires the nearest target (hostile or friendly), a node which acquires a space to move to which is at an exact range from a given location (for, say, an archer or mage), and a node which acquires a space to move as close to a target location as possible (for charge and attack). Additionally, I've got nodes in the tree which spawn components to begin the Basic Move ability and which target specific locations. Once I implement the wait AI node, I'll be ready to have a smoothly functioning chase-and-kill AI which can move around the board and try to attack you. I've also made the AI xml-importable, so writing that will be a breeze.
That's my first major milestone (a technically-working battle), and I think I'll have that done in a few days at most, hopefully less with the weekend looming and a whole lot of free time. My general roadmap after this is to do a single relatively feature complete battle, which will involve a lot more cutscene work (oh you KNOW there's gonna be those text boxes though), followed by a non-tactical interface, including a world or town map, party panel, ability to equip items and weapons, and of course saving and loading the game.
But, all that is to come. Week one has completed successfully.
The save icon caused an interesting interaction with my 14 year old nephew who is playtesting the game. Here's the old icon as it shows across the menu bar.
So I get feedback note from my nephew and he tells me something really strange...
"The save icon is upside down"
I was kind of struck by this. I didn't realize there was an orientation, but sure enough, a quick google image search for "save icon" shows, that, yes, in the intervening years that little floppy got flipped. I found it so strange that my nephew would spot something so innocuous, especially since I haven't seen a floppy disk in years. In fact, I haven't seen one in ages. This sparked a question I decided to ask my nephew.
Me: "Say, do you know what the save icon represents?"
Nephew: "Isn't it a lock box? The keyhole is on the bottom which would make it hard to open."
Yea, evidently he always saw it as a secure storage box. Basically one of these.
== Ninja Edit ==
For the record, the icon looks like this now.
You should pull out a floppy and blow his mind.
I've moved out of the design phase and into the actual implementation of my ECS architecture, and run into the predictable fallout of the theory-reality divide. Fortunately, everything I'm dealing with is more along the lines of indexing problems and uninitialized memory rather than the more fatal "the type system fundamentally rejects what you are attempting to do". I'm working my way through the various features I've plotted out for my "Component Storage" class, which is capable of storing an arbitrary set of struct arrays and coordinating how various combinations of components share that space. (Remember, half the point of this system is to keep all of your entities packed into the same regions of memory so the CPU doesn't invalidate the cache as often.) The specifics of how it manages those different entity combinations (which I've taken to calling "Archetypes" since I saw one person somewhere who I can't even remember now refer to them in that way) and lets you do super-fast queries for the series of Archetypes that contain specific Components I'll have to leave off to another time, because EVO is on and my attention is too fragmentary to explain something in words that it took me having to draw out a visual aid for myself to grok the first time.
Here's one of the spritesheets in it's original 320x200 resolution.
And here it is in 4x resolution (Spoilered for big)
No joke.. Look
Of course, obligatory screenshot.
Now this is just a tanker, and pretty simple. I have just the flat vertex colors above, and I decided to give the ship a normal map to make it look more ... "realistic", but not happy with the result. Should I go all out and just old-school the textures? I'm kinda leaning towards the top I guess.
http://www.fallout3nexus.com/downloads/file.php?id=16534
Check out this tutorial about adding normals to sprites so you can use 3D lighting effects.
The author is the developer of Megasphere which has quite possibly the best pixel art ever made. But not only is the art the best his lighting, particles and animations are awesome.
Everyone considering doing a pixel art game should look at Megasphere and weep. It is the pinnacle to strive for in terms of graphical perfection.
That meant gravity at the top of the tunnel was the reverse of what it should have been but worked normally at the bottom of the tunnel and produced weird swimming effects on the sides.
I used the Sherlock Holmes debugging technique of making a list of every assumption I could think of then explicitly testing those one by one. debug.drawray was very useful
Sadly, I need to learn about using pixel shaders but they are an enigma . The game I'm working on is altering colors by grabbing a bitmap section, checking every pixel in a for/next loop and altering the bitmap if the pixel is equal to a value. It's super slow and I think is dragging down slower machines. Just every time I see info about a pixel shader it's either really vague or goes in some crazy OpenGL/Direct3D low level graphics card mathematics gunk. All I want to do is when the shader is "on" to draw pixels a particular color.
For example, here is the shader API for the game library I'm using.
It shows me how to make a shader object, but then say I need to attach the source code to a shader to make it work. What source code? What language? How do you "program" a shader? When I look up a shader language it, it gives me like 30 of them with stuff like "fragmets" and you have to pass vectors and stuff. It seems so complex. Can someone kind of clue me in on how this all works it would be sweet.
Seems like a real "above the weeds" kinda guy.
Our first game is now available for free on Google Play: Frontier: Isle of the Seven Gods
It's super tempting to just run this all through am upscaler like hqx or Waifu2x, but it just looks awful. In the end I just sat down with Inkscape for two days and redrew them all
Here's what it looks like when using hqx to automatically scale it
and Waifu2x (Only upsacled once, but you can see the artifacting)
Don't rely on upscalers to do you work for you *cough* Squareenix *cough*
In other news, I added fog to the game. It took a while to make it look realistic but I think I got it. Some of the levels (especially those that have a background which contrasts heavily with the fog) look stunning. Of course now I have to update the screenshots on my Steam page.
I can highly recommend setting up a google news alert for the name of your game - a good way to make sure you're not missing out when someone writes about it!
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Ok I've only been able to put some stolen hours every once in a while into this, but progress!
It's super unbalanced right now, where I think sort of everything is overpowered? If you don't make mistakes, you win really easily, but if you do make mistakes, you lose really easily.
I think the next step is adding an in-between bosses thing where you can actually tell what's happened after each boss, with progress pointed out, instead of the breakneck pace of just respawning immediately.
Particle systems added to UI elements in Unity:
I have 1.9.4 downloaded as a tar.gz file. And I have Python 3.7.0 installed. Is the tar.gz file a wheel? Am I supposed to rename it and then use PIP to install it? (I'm on Windows 10.)
It's also available from PyPi, so you can just pip install it.
==Ninja Edit==
Demo pulled, I super goofed up the intro - It will be back soon (This is what I get when I comment out the titles when compiling a debug build)
Demo is back up. Watch your variable types guys! Unsigned ints can't make things go backwards!
I have exciting news!
While I was updating the credits in the game, I decided to look up the names of the original developers. I already knew the main developer as he was the one I got the source code from. I kind of got into the mindset of "I wonder what they are doing now". I started with the original art director, Maurice Molyneaux. Turns out, over the years he was the director of product development for Namco, Chief creative officer for Nuvo studios, screen writer for a $18 Million dollar feature film, and has worked with THQ and Psygnosis back in the PS1 days.
I decided to send him a letter.
Turns out he was so enamored with what I was doing, he went into his zip disk archive and info dumped everything he had on the original art direction for the game. Old articles, reference art, and lots of cutting room stuff. Then I got stories about how the game was made and he offered advice on.. well.., whatever the hell I'm doing. (He seemed to have a better idea then I do). He pushed me in a few good directions. It was a real eye opening experience.
He even tweeted about me
I'm going to be doing a push to finalize the art so I can get the tutorials done... Then it's final bug hunting I guess.
For Windows I strongly doubt it. Given its SDL dependency I think you'd need to be looking at a prebuilt binary.
I'd try here:
https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
Is there an obvious way in Unity to draw a specific frame of a sprite AnimationClip stored in a ScriptableObject so that I can adjust hitboxes for each frame? Right now, I'm doing it in the inspector with GUI.DrawTextureWithTexCoords, and it just can't be this ridiculous.
// In class MoveEditor : Editor // collect keyframes foreach (var binding in AnimationUtility.GetObjectReferenceCurveBindings(Clip)) { foreach (var keyFrame in AnimationUtility.GetObjectReferenceCurve(Clip, binding)) { sprites.Add(keyFrame.value as Sprite); } } // render selected keyframe Sprite s = sprites[currentFrameIndex % sprites.Count]; Vector2 texSize = new Vector2(s.texture.width, s.texture.height); Rect srcRectPixels = s.textureRect; // I'm not sure how this differs from s.rect Rect srcRectFraction = new Rect(srcRectPixels.position / texSize, srcRectPixels.size / texSize); var srcToScreenRatio = Mathf.Min(Screen.width / srcRectPixels.width, Screen.height / srcRectPixels.height); var destRect = new Rect(SPRITE_DRAW_POS, srcRectPixels.size * srcToScreenRatio); GUI.DrawTextureWithTexCoords(destRect, s.texture, srcRectFraction);It is finally getting close to "Beta" very excited now!
https://steamcdn-a.akamaihd.net/steam/apps/703100/ss_067949bd78c6dc24b45e4de660d3e3d936d55e66.600x338.jpg?t=1534930460
Between going to evo a couple weeks ago and crunch time at work, I've neglected to come back and update the thread on my progress, but progress continues at a good clip!
Since I've run into crunch time at work, most of my time after work has been spent trying to decompress from particularly stressful days. However, I'm still waking up Way Too Early (tm) in order to reclaim a couple of hours each day prior to work, so that I continue to work on the game each and every day.
Since a few weeks ago I accomplished my first major milestone, which is a technically playable battle! That involves at least one friendly, human controlled piece, and at least one enemy, AI controlled piece. The AI must be able to acquire and choose targets for movement and attacks, where the human player must be limited on what actions they can take each turn. That much is now done!
Next milestone is a much more "feature complete battle." To this end I've done a lot of basic stuff, such as click-and-drag for camera movement, and refactoring a lot of hard-coded constants out as configuration components which are loaded at runtime via xml.
In addition, I've also implemented several fancier, flashier, more impressive systems such as my secondary resource system, morale, text boxes (with portraits), temporary buffs and debuffs, and a basic defend action to go along with basic move and basic attack. Also, floating combat text!
Just this morning I implemented tooltips and added them to the three basic action buttons, and I added four different orientations to them (top left, top right, bottom left, bottom right, of the object spawning the tooltip). They're not smart enough to know which orientation to use yet but that will come later. For now I set them manually.
I also solved a couple bugs I've been building up this morning, including a bug which caused all text boxes past the first to automatically and instantly advance to completion, without animating the text (this is because the input which advanced past the previous text box was not being consumed, and as such the next text box was assuming it applied).
Another bug was that the floating combat text for the basic attack move was showing raw damage numbers and not final damage numbers, which is because for some reason I thought that conversion of raw damage to final damage should be done in the system which actually dealt the damage. Turns out that was really dumb, and at least one other component (and likely several) will need to know what the final damage will be, given raw damage, the actor and target, etc. So I've refactored final damage calculation into the same utility class which calculates the damage modifiers for armor and attack vs defense stat differentials.
The trello is growing as fast as it's shrinking, but considering how high level it was when I finished my prior milestone that was nothing if not expected. However I'll be getting to the REAL good stuff soon: classes and subclasses for fighters, plus the special abilities that go along with those classes. In preparation for that I'm going to have to move a lot more of the cutscene elements to be xml-importable, as well as make targeting strings xml-importable.
(Background on what it means for my game to have xml-importable targeting)
So essentially if I can import the target string in xml, which should be fairly easy since the origin points are never arbitrary, and I can also import cutscenes in xml, then I can write entire battle actions in xml. "This is your target" "this is what you do with those targets"
At that point I can refactor the basic moves into xml if I wish as well, instead of having them hardcoded. This should be a HUGE boon to my workflow as well as possibly making the game super easily moddable if that's a thing.
Mmm, yes that's what I want.
Anyway, things progress smoothly! Still putting in at minimum two hours a day, more if I've got the time and energy after work, and progress is steady.
WOW! The guy hangs out and is friends with the old Star Trek:TNG staff. Evidently, he pitched a few scripts to them back in the day. He hangs out with Mike Okuda, the art director for TNG, Andrew Probert, concept designer for the Enterprise. He also hung out with Matt Jefferies before he died. He's getting me in touch with someone who can help update the UI to my game.. Also. @ChicoBlue made some art for me that wraps around the new 3D models nicely.
(Spoilered for big)
This was the kick in the pants I needed to finish this project!
that was causing it. When I changed it to entitiesToDelete.Count > 0, no more GCs. That's such a weird thing to make garbage on, too, since most of the time they're good about determining if the collection you're iterating over implements a better interface.
This is what I get for prioritizing semantics over implementation details.
Just chiming in to say this guy's website is legit, and it's saved my butt a number of times over the years.
That sucks cause it is better code to use any than count but yes removing all instances of the GC in the gameplay loop is a must.
I general linq is somewhat risky to use in critical parts. It was design for business cases, not gaming.
EDIT: Aaagh, I just realized that this happens because of something I've been cautious about a lot lately anyway. You have to be careful with structs because of boxing. The enumerator is a struct, yes, and Any() is an extension method on IEnumerable. So the enumerator gets passed to Any() as an IEnumerable, which results in a boxing operation and garbage gets produced.
What I wound up with was a buggy mess:
Ha ha actually not. I've reached a point where it feels like I've stressed all the major code paths in my framework, at least enough to create a presentable little tech demo on my favorite fields of cornflower blue. There's a long way to go before it feels like a "game", but the groundwork is there (he says yet again).
For those of you who don't hang off my every word and remember every details of my posts from a quarter of a year ago (you're forgiven), a quick refresher on what I mean by an "intellectually pure" ECS architecture: as typically defined, ECS separates the world into three major provinces: entities, which are literally nothing except for associations between components (indeed, in my system an entity can be fully represented by an integer), components are nothing more than pieces of data (my components are almost entirely without behavior), and systems operate on streams of entities that have specific combinations of components. (For instance, a simple movement system might take every entity with a Position and a Velocity, and update the entity's Position to increase by its Velocity.)
Why try to implement my own ECS architecture rather than use an off-the-shelf engine like Unity or Unreal? I mean, the only bulletproof answer to that is "because it entertains me". I recently got a job with one of the big tech giants, so my 9-to-5 life mostly consists of trying to navigate an incomprehensible labyrinth of code and tools that someone else made that are difficult to diagnose, writing maybe five lines of code on a good day with all the remaining time being investigation and build. I don't really want to come home to spend my limited game-development time trying to navigate an incomprehensible labyrinth of code and tools that someone else made which are prone to failing in ways that are difficult to diagnose. But, more seriously, a few more reasons:
- The ECS architecture lends itself well to maintaining cache coherency, which can be a hidden bottleneck to performance. I don't put much stock in this point, just because the .NET Framework is made by smarter people than me who have probably already set up the runtime to consider things like that.
- Testability. A system is allowed to make any changes it wants on the components that exist in the data storage area. If you make writes into the data storage transactional (meaning, writes are delayed until the system stops processing), there is no change in the data storage until the end of each system's processing-- which means that a system's processing operation is the moral equivalent of a pure function. Pure functions are really easy to test: same input, same output. This also means easy debugging: if a system's processing function crashes, we maintain the game state in an unmodified state just before the function call-- serialize it to a file, email it to the developer, and you have a snapshot of the moment just before impact.
- Parallelization: I don't plan to get too fancy with my system pipeline (I'm just making a Sonic knock-off, after all), but if it really needs it, the bit about pure functions up there also means that parallelization is much easier than it would be otherwise. The fewer class instances with mutable state, the easier it is to coordinate work between multiple cores.
- You can do some really neat tricks by sending the same data through multiple pipelines, which I'll discuss below. This simplifies a number of really painful, bite-you-in-the-ass scenarios that you often run into in game development.
- In the worst-case scenario, I'm creating a C# DLL, so I can always drop the entire thing into Unity if MonoGame turns out to be insufficient in some respect. (If it's good enough for Stardew Valley, though, it's good enough for me.)
The cornerstone of my ECS architecture is a class called "ComponentStorage". As you might imagine, ComponentStorage's main responsibility is storing components in a way that's amenable to looking them up later. The way I settled on handling it was to give ComponentStorage a dictionary mapping Types (the C# reflection object) to arrays of component structs. The components stored in these arrays are then associated with what I took to calling "archetypes" after seeing the term used once. An archetype is a specific combination of component types-- for instance, if a "rock" game object has the components Rock (indicates it's a Rock), Position, Velocity, and Hitbox, there will be an Archetype instance describing which spans of the component arrays belong to the Rock archetype.
This is very difficult to put into words such that it transmits well, so instead have some ASCII art that I hope will make it clearer, using my previous example of a simple Legend of Zelda-like where Kupi tries to push rocks onto switches in order to open doors:
And even that might be a bit too dense...
The archetypes are stored in a list, and store how many instances of that archetype exist, along with the total available capacity for that archetype. Then, they also store the index at which their "stripe" begins in each component array (that's the "@ X"). In the component storage segment, I've visualized the arrays, with the numbers indicating "real" instances (and which archetypes they belong to by index in the list), with underscores representing empty space. Basically, it's like your standard List<T> instance, except I'm keeping multiple lists in the same memory buffer. There's a lot of bookkeeping involved in expanding the individual stripes and whatnot but I won't bore you with the specifics. It works, though! I swear it works.
You'll notice that with each archetype also has a thing that says "(Next: X)" for each component. For each component type in an archetype, the archetype stores the index of the next archetype in the archetype list that contains that component. This is how you can get fast queries for subsets of components: from any given archetype, you take the maximum next index for each component you're looking for and skip to that index, or stop iterating if any next-index does not exist. Let's say we want every archetype that has a Position and Hitbox (for our collision detection phase). We start at "Rock". The maximum next index for Position and Hitbox is 1, so we go to "Switch". The maximum next index of Position and Hitbox in "Switch" is 3, so we skip "Floor Tile" and go to "Wall". And likewise to "Door" and then "Kupi", where iteration stops because neither Position nor Hitbox has a next archetype index.
But what if the first archetype doesn't have your target component combination? I use the sentinel pattern, meaning there's a special archetype that isn't in the list and contains every archetype. All scans start at this special first archetype, which lets them jump to the first archetype that satisfies all of the component constraints.
I'm starting to get that "you're talking too long" feeling, so I'll pass over the specifics of how entity queries work other than to say that you can probably figure out how you go from a series of archetypes to a series of array accesses.
A quick aside: MonoGame is structured such that the main game loop consists of two phases: Update and Draw. In an ideal world, MonoGame calls Update() and then Draw() and then sleeps for the remainder of your frame duration. If the Update() call takes too long, it will skip the Draw() call, unless it's skipped the Draw() call too many times, in which case it skips the Update() call instead and your players get really angry. The ECS architecture I've created plays nicely with this paradim. An object called a Context combines a ComponentStorage with a list of system classes to execute in order on the ComponentStorage. But the same ComponentStorage can exist in two separate contexts-- for instance, an Update Context with a list of systems that handle the gameplay logic, and a Draw Context with systems that handle the rendering of the game state.
But that's not all! (I'll let you go soon, I promise!)
If you've been a young, starry-eyed game developer at any point in the past, I'll bet you've run into this situation. You've been hacking away at your game for a while. You've prototyped some fun hero controls, made a couple monsters, designed a level or two, and so on. But you've been entering and leaving gameplay by jumping between your editor and the main gameplay mode. As you're considering what practical features the game needs, you have this creeping sense of dread as you start considering how to implement pausing the game. If you're in a Unity or Unreal-style engine, you've probably spread your gameplay logic over the Update() override for a bunch of different Actors or GameObjects or whatever they call them. And each and every one of them has to be updated to respect the pause state, and you're plagued by the occasional monster that keeps running around when you pause the game or a sound effect that keeps playing. There might be some kind of global time-step variable that you can turn down to 0, but you have to make sure it doesn't affect the pause menu, too, or the player won't be able to interact with the pause menu itself. What a pain in the ass!
In my ECS architecture, here's what happens: when the player presses Pause, you create a new Context containing the pause menu's components and its systems. You emit an event to the systems in the gameplay context that the game is stopping in case they need to clean up (like by pausing sound effect playbacks). Then you stop telling the main game context to run. But you keep telling the Draw contexts to run, so the player can see the main game below the pause menu. And when the player chooses to unpause, you tell the main gameplay context "Okay, we're resuming" and start telling it to process each frame again.
Boom, instant pause logic. None of the components have to know it exists. Most of the systems don't even need to know it exists. dusts off hands
My next steps are integrating a simple collision library I wrote yonks ago into this system, and moving on from there to some of the other generally-applicable system types, like sprite animation, sound management, level definitions, and so on, before moving on to something genuinely gameplay-like.
https://www.humblebundle.com/games/unity-bundle