What's wrong with the code? It doesn't look clumsy to me.
It strikes me very much as if (thing != null) { thing.method }, which language authors have been increasingly designing around. Like the C# null conditional operator or the Ruby safe navigation operator.
Given that, I was wondering if I were missing a Unity idiom that would compare RaycastHit objects without having to know about their internals. Or even just a more compact way of doing so, though I think the answer is just that I need to make the method myself.
What's wrong with the code? It doesn't look clumsy to me.
It strikes me very much as if (thing != null) { thing.method }, which language authors have been increasingly designing around. Like the C# null conditional operator or the Ruby safe navigation operator.
Given that, I was wondering if I were missing a Unity idiom that would compare RaycastHit objects without having to know about their internals. Or even just a more compact way of doing so, though I think the answer is just that I need to make the method myself.
Yeah you can do something like:
thing?.method();
But a lot of this shit is just code fluff, it doesn't really mean much and is sometimes harder to understand than != null.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
imo the real answer to getting rid of null checks is the Null Object Pattern. In OO, if you can use polymorphism to solve unnecessary branching, it's usually the right answer!
So back in the day i made Flash games and chucked them up on MochiGames to get them monetized and distributed and I'd make, like, £100 a year which given I was just making these for fun was all right.
Is there an equivalent these days for HTML5 canvas games or has the death of flash completely fucking regressed the environment for small game makers in yet another way?
Like I know I can submit to Kongregate and Newgrounds but they aren't then syndicating the content to a thousand other places. I'm looking for a one and done kind of deal.
imo the real answer to getting rid of null checks is the Null Object Pattern. In OO, if you can use polymorphism to solve unnecessary branching, it's usually the right answer!
Yeah, I agree. The standard Unity idiom (as far as I can tell) is to be involved entirely too much about the internals of a RaycastHit and know to check hit.collider before comparing hit.distance values. So I think I need to write a hit extension method for reliable comparisons.
It reminds me (by contrast) of the Sugar Punch critiques of the awful animation in NRS games. Compared to Garou, Darkstalkers, UNIEL, etc, the lack of anticipation, squash, stretch, overshoot, strong silhouettes is all very striking
I tried to use public library photoshop with faster processor than my old rig.
I have no idea where anything is with this program and I run better with gimp
edit: Its just occurred to me that having my steam controller dongle plugged into a USB port might have screwed things up, lets unplug that and uninstall Wacom and........
The code is ugly as heck (to bring it to the discussion previously). So many if and null checks...
Lilnoobs on
0
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
I'm thinking about starting development on a Puzzle Fighter clone to put out on Steam cheap for a few dollars. I would really love a way to play Puzzle Fighter on my computer without having to wait for Capcom to make it happen. Especially since they're canning the mobile version.
I tried to use public library photoshop with faster processor than my old rig.
I have no idea where anything is with this program and I run better with gimp
edit: Its just occurred to me that having my steam controller dongle plugged into a USB port might have screwed things up, lets unplug that and uninstall Wacom and........
My resolution just got better.
From your Steam dongle??? I use mine all the time and haven't seen that.
Oh man... make it dance themed instead of fighting themed... Yeah. That sounds cool.
I've been thinking about this during my department offsite since I woke up. I think I'm gonna start deving up a game mode when I get home in Game Maker 2. Probably just classical 'Tetris' first to start, and we'll go from there. What are some of your guys' favorite game modes from different puzzlers? I'm thinking I'd like to include modes similar to classic Tetris, standard Puzzle Fighter, Tetris Attack, Fever mode from Puyo Pop (not necessarily Puyo Pop though, just the Fever feature, building a meter when cleaning up trash that when full leads a player to a 'bonus' section that could counter your opponent with easier deliverable trash), and a power-up or item mode that provides a bit more RNG and chance for not as experienced players to have a more even playing field when playing with more advanced players. I think those five modes would provide a diverse collection of puzzlers that people love but haven't been put in a one stop shop before.
Oh man... make it dance themed instead of fighting themed... Yeah. That sounds cool.
I've been thinking about this during my department offsite since I woke up. I think I'm gonna start deving up a game mode when I get home in Game Maker 2. Probably just classical 'Tetris' first to start, and we'll go from there. What are some of your guys' favorite game modes from different puzzlers? I'm thinking I'd like to include modes similar to classic Tetris, standard Puzzle Fighter, Tetris Attack, Fever mode from Puyo Pop (not necessarily Puyo Pop though, just the Fever feature, building a meter when cleaning up trash that when full leads a player to a 'bonus' section that could counter your opponent with easier deliverable trash), and a power-up or item mode that provides a bit more RNG and chance for not as experienced players to have a more even playing field when playing with more advanced players. I think those five modes would provide a diverse collection of puzzlers that people love but haven't been put in a one stop shop before.
In short, blocks come up from the bottom of the screen, and instead of randomly getting a block from a set group and spinning them to fit the current blocks in your area, you instead swap two blocks from two columns to try and make pairs of 3+. The more combos or blocks you match, the more junk gets sent to your opponent. Game ends when your opponents blocks hit the ceiling.
I tried to use public library photoshop with faster processor than my old rig.
I have no idea where anything is with this program and I run better with gimp
edit: Its just occurred to me that having my steam controller dongle plugged into a USB port might have screwed things up, lets unplug that and uninstall Wacom and........
My resolution just got better.
From your Steam dongle??? I use mine all the time and haven't seen that.
It jumped from 1200 to 1300 width, my eyes are free
Edit: currently waiting for car brakes to get repaired and doodling afro futurism magical school space harrier
Just a random brainwave because all my game dev this week was boring (like, "find the values of an exponential function that lead to the correct relationship between attack power and Skill Point cost" kind of boring): people have explored how players perceive randomness in games. Fire Emblem fans, for instance, have all experienced the feeling of missing three 97% attacks in a row, or getting hit by a 15% chance to hit with a 2% crit rate and losing a guy in one shot. One mitigation is to double-throw and take the average, which pushes high values toward better accuracy and low values toward lower accuracy. But how about this for a simpler fix: be honest with the player. Show them the dice. If they have 97% accuracy, they might be more willing to accept a string of misses if they know they rolled a 2, 1, and a 3. It won't deflect accusations of the dice being fixed, but at point nothing will.
My favorite musical instrument is the air-raid siren.
I think it certainly makes people accept the randomness better. One example that comes to mind is how the loot in WoW worked for the longest time, it just worked off a 1-100 roll and it displayed the roll and who the winner was. More people just use the /roll function now to trade personal loot, but if someone loses a roll it doesn't usually escalate much further than "aww damn" if they lose to someone else. Where people hate the shit out of the new personal loot system where the game just internally rolls and you either get an item or it tells you to screw yourself and you get a pittance of gold.
In fire emblem's case I think that's an issue of bad design. IMO fire emblem takes randomness a couple steps too far, though I struggle with why I think that because I also think that XCOM does not do that.
Perhaps it's because in Fire Emblem every character is a named character with a written story and so losing any one of them feels insurmountable, or perhaps it's because XCOM pairs it's brutal randomness with significantly more depth than fire emblem. I'm not sure, but there's something about the context there such that I can't stand fire emblem but I can't shut up about XCOM
Once again, for those not in the loop, I'm porting/remastering a commercial game from 1991. The game is rather complicated and in depth and so I'm adding a badly needed tutorial system. When I licensed the source code I also got the original manual data files as well. For those who may be younger, once upon a time games came with thickish manuals that not only told you how to install the game, but also tended to be packed full of tutorials, lore, stories, maps, and other odds and ends. The final manual I have is in PageMaker 4(!) format, which can't be opened by anything under the sun anymore. However, there was a slightly older draft that was in Word 5.5 that shockingly opened with LibeOffice. This version didn't have any of the illustrations embedded, but I have those in a resource folder. I'm adding them back in now and matching the text with a PDF scan of the original manual to make sure everything is up to date. (For example the draft mentions using the manual as copy protection, which was not in the final release)
Now the problem I have is the manual is a staggering 220 pages long, but there is a lot of good content in there. Lots of in-universe roleplayish stuff. How about would you entice a player to go though a manual nowadays? Make oblique references to it in the game? Offer a dead-tree version, or maybe as an e-book and not just a PDF? The manual tickles my nostalgia bones to no end, but I don't know if current players will understand the value of the thing.
Converting such a manual into the digital world sounds like a job in-of-itself. You could take the Destiny method with collectibles that hint at the manual online (e.g. grimoires), so the player finds little easter nuggets of lore and can visit some website for further details.
There's also the mass effect way where once they 'unlock' a part of the lore it exists within the player's 'codex' that the player can freely peruse while inside the game.
I guess it depends on what exactly is in the manual that you think is engaging and how much time you are willing to spend converting it into a digital format.
Forgive me for any awkward wording, I am living in the BC time.
As I go though the manual, I'm finding self-contained gems that can be encapsulated into the tutorial system. There is a tutorial I can rip wholesale too. I'm about halfway though fixing it up (It's a weekend project). Turns out the manual is broken up by sections that can probably be scripted out. However I will need to record the tutorials which may be time-consuming.
Rules of Engagement (the game I'm working on) is a starship battle simulator, but it links into an "Xcom" like game called "Breach 2" that is stand alone. You can play each other stand alone or if you have them together, will behave like a bigger game. When you take over an outpost or broad an enemy ship, ROE passes control Breach and back. IPC happens though a data file transfer. (a kind of psudo-savefile gets passed back and forth). I'm also rebuilding the interlinking part now. After the Tutorial and IGS linking, it will be into Beta for final bug squashing and graphics overhaul.
Yeah honestly I think the only thing you can really do is make players aware of the manual - beyond that, it's kind of on them whether they're interested or not. If it were me, I'd probably just do something in-game like "blah blah blah Cybers (see section 3.2 of the manual to learn more)" whenever it felt appropriate. If you did that, if it was also somehow clickable to take them directly to that section, or at least have it open the manual, they'd be more likely to do it then rather than having to remember to do it out-of-game. (Or get the manual in-game if possible).
Greetings penny arcade dev board
It has been a while and I decided to start yet another project following the following set of principles
1. no assets (I cheated for the floor though, didnt feel like writing a procedural texture)
2. no plan, as in no design doc, no flowcharts, no trello, no goal
3. one sentence daily dev goals/requirements obtained by asking myself "am I ready to release?" and then implementing what came after "no because....", then forcing myself to stop after I wrote "one sentence" worth of code
4. no per-emptive optimization(huge enthusiasm killer), including not following any coding or organization principles whatsoever, not even making folders in my unity project pane until I had a specific reason to
5. publish the moment I hesitate to answer "no because..." to by mantra question
complete results here: https://acp.itch.io/thewedge a hybrid endless runner + rail shooter, no instructions, should be able to figure out controls by 2nd go
playable in browser but if you have shields up you might need to switch to a more "open" browser for the game to work
~12 days of one sentence dev work and 2-3 days of proof of concept work to figure out what I wanted to make
the game is fun enough to leave as is but there is always stuff that can be added
my original plan was to release on mobile, I'll try it but i dont think tap targeting will be nearly as much fun as mousing over enemies and seeing them blow up
I'm happy to share my code or explain how I did anything if there are any non-obvious features anyone has questions about
Hey everyone! I've (barely) started studying up on Unity's new "performance by default" ECS paradigm, and since it took me a bit to actually get a handle on why it works, I figured I'd do a little write-up on what I know about it both to pass that knowledge along and to help solidify that knowledge by forcing it to come back out of my own head. All of this is gleaned from one of Unity's GDC videos here.
To start out with, Unity's current paradigm is "ECS" in the sense that "we stopped writing design documents and have daily standups" is "Agile". Maybe that's a slightly extreme analogy, but the point remains that right now Unity uses a more object-oriented approach to implementing ECS, and OOP is bad and for stupid people*. (I struggle to remind myself that it is irrational to feel personally attacked by a criticism of a software development paradigm, but when you've done something a particular way for ten years it's difficult to keep the statement that "this method produces worse code" from implying "and therefore people who use that method are bad programmers".) The new paradigm moves toward a more procedural style in which all operations are simple transformations of highly-compact data. This pushes the new implementation closer to the "canonical" form of ECS.
In the canonical form of ECS, the three members of the acronym have the following roles:
- Entity: Has no function but to act as an aggregation of Components.
- Component: Describes a specific attribute or behavior of the Entity. Note that it "describes" rather than "provides".
- System: Controls the interaction and transformation of Components.
What will probably be most surprising for someone used to the object-oriented model is that in this new paradigm, there is no class that represents an Entity. In the current model, there are GameObjects, which aggregate a number of behaviors related to Entities and provide things like Component-finding functions and most-common functionality like position and rotation by way of the Transform class. No such class exists in the new paradigm. Instead, an Entity is represented by a synchronized position in a set of arrays of Components.
For simplicity's sake, let's say that we only have one type of Entity, a Character, which is made of one Position, Health, Hitbox, and Sprite Component each. Then, the underlying collection of entities looks like this:
const int MaxEntities = 100;
Position[] positions = new Position[MaxEntities];
Health[] healths = new Health[MaxEntities];
Hitbox[] hitboxes = new Hitbox[MaxEntities];
Sprite[] sprites = new Sprite[MaxEntities];
(I should note that you, the programmer/Unity user does not declare these collections. This is just a pseudocodey way of representing what I suspect Unity does behind the scenes with your Component classes and the big Entity/GameObject tree structure.)
If you need to refer to a specific Entity, your one and only method of doing so is to know the index of the Entity in the component arrays. positions[37] is the position information for entity #38. healths[37] is the health information for that same entity. And so on. But there is no Entity class by which anything in the system can refer to an Entity. And, for our purposes, that's actually a good thing. Nobody should ever need to refer to a specific Entity. They should only care about Components.
Now, there are different types of Entities, defined by which Components they have. There might be, say, a light-emitting Entity that has a Position, some lighting information, and a Sprite, but no Health or Hitbox. These are stored in separate collections from, say, the Components that make up the Character Entities.
Components in the new paradigm are also significantly different from the Monobehaviors we're used to. Monobehaviors have hooks to override a large number of behaviors, like startup logic through OnStart() or routine updates through Update(). This is no longer the case in the new model. Now, Components are effectively structs. They do not have behaviors other than, perhaps, helper functions for composite transformations. A Position Component from my example isn't like a Transform, with its ability to create an object hierarchy. It's just a vector with a 2D position (I'll say it's 2D because Characters render through Sprites). Health is just a simple floating-point counter with maybe a set function that handles value clamping. Hitbox provides a position-relative width, height, and offset. And so on. However, Components don't have behavior. They don't interact, they don't send or receive messages, they don't "think", they just sit there and expose data.
The only thing in the new paradigm that actually has behavior is a System. The role of a System is to pick up a set of Components that it's interested in and either transform them in some way or to produce data that can be consumed by a subsequent System that's part of a data pipeline. My comprehension of how exactly Unity's new ECS paradigm handles this is blurry, but essentially you declare a set of queries that will be used by your System class, which then produce synchronous streams of the appropriate Components. For instance, let's say that we wanted to make a System called SpriteRenderingSystem that draws Sprites at the point in space given by a Position component. The SpriteRenderingSystem would (somehow) declare that its input query should accept any Entity which has a Position component and a Sprite component. You'll notice that in this example, that includes both Characters and Lights. It doesn't matter if an Entity is a Character or a Light, only that it has a Position and a Sprite to render. The SpriteRenderingSystem goes through its component queries (which are known to be synchronized), and draws each Sprite centered at the Position that matches it. It does that not only for the existing Character and Light entities, but also for any future Entity that has both a Position and a Sprite to render. When you later create an Particle Entity archetype that also happens to have a Position and a Sprite Component, the SpriteRenderingSystem picks them up and draws them without any further changes.
Now, this is all what so far. The more important question is why. Why is this system better than what we have now? The first thing that comes to mind is simplification of the behavior code. Separation of concerns is a noble principle, but an excessive reliance on subclassing, virtual functions, and event publication can make the flow of your gameplay logic extremely difficult to track. In this new paradigm, the use of callbacks, publication and subscription, and so on is minimized, meaning you have a smoother, forward-facing flow to your game's behavior. A more obscure concern is the idea of cache coherency. (I'm putting cache coherency in the middle because people tend to forget the middle element of a list.) In an object-oriented approach, you tend to have objects that are linked together through pointers to highly diffuse areas of memory. Cache misses are a huge trouble spot for losing performance at a low level, because pulling new pages in from RAM takes a dog's age in microprocessor time. In this new approach, related Components are very tightly packed together. As the SpriteRenderingSystem iterates over the paired Position and Sprite elements, it's working on values that are close together in memory, resulting in much fewer cache misses. But the real gain here is in parallelism. By defining a very rigid pipeline and limiting the cases under which the Component data may be transformed, the new paradigm lends itself well to partitioning its operations into small, easily-distributed chunks. (I know that the Boids example in the GDC had most of its services implementing an "IParallelForJob" (or similar) interface whose one function took an index parameter indicating which element in the query arrays it was supposed to operate on.) This means that you barely have to think about locks, mutexes, and so on-- Unity handles the thread coordination, and you only write the code that runs on any individual thread.
I'll admit that there have been certain concepts that I'm still not confident I understand how to port over (for instance, how exactly the system handles the creation and destruction of Entities, if you're allowed to give an Entity a new Component at run-time, how one refers to a specific paired Component from another Component, how to represent when-x-then-y event logic, and so on), but at this point I feel that's more a failure of my own comprehension than a fault of the new paradigm, and though I still resent Unity's habit of publishing hour-long videos rather than text tutorials, I'll probably wind up sitting through a few more to see if I can shake off the remaining clouds. Thanks for muddling through my overlong (and likely incorrect) explanation. If anything seems unclear (or outright wrong), feel free to ask questions (or correct me).
* This last impression is not a feeling I got from the Unity presenter; rather, it is a sense I've got from some of the Internet's more passionate detractors of OOP.
My favorite musical instrument is the air-raid siren.
For what it's worth, I'd say that was a good explanation of ECS as a paradigm, even irrespective of Unity's rendition thereof. Having never even seen the acronym before, and having now spent a few hours reading up on the idea, I think your post is an accurate and sensible introduction.
I picked up the Corgi Engine last week, when it was on sale, and I tried it out with Unity's tilemap. Or, at least, I attempted to, but the last Unity update broke the tile palette!
If you're having the same problem, you're not alone:
It's fixed in the beta branch, but it the LTS will receive a backport of the patch "in the near future", which is too long for me. Which means I just now learned that the Unity Hub is basically rbenv but for Unity??? I'm very into it, and I'm def using it from now on.
good amount of updates to game since I last posted it
several changes based on reddit feedback including adding instructions to the html display page and decreasing the "fade" times to be less arty and more practical
the game has kind of the look of a rhythm game so I'm probably going to try replacing the continuous player movement with instant re-positioning based on which key is pressed, which will also take care of the "unfair" obstacle formations that pop up sometimes
I'm pretty happy with the results but there is always more that can be added
makes things pretty simple to at least try on your own even if I dont quite grok how this would be useful for gameplay functions, I can already see how it could replace particles for some types of vfx
a decent amount of work on the game since last week
Based on player feedback I changed the controls from continuous movement to teleport based. Now the game works like an "anti-guitar hero" where you get out of the way of the falling notes instead of pressing the key on time. I had multiple reports that the 3 key controls (A S D) were awkward and was suggested a couple of different control schemes which I plan on implementing.
Also based on suggestions i removed the "gameover" screen and rolled it into the gameplay screen, that removes a couple of clicks and some fade time before you can restart a game One minor details is I added animations to the obstacles so they "pop open" when the player gets close to them, it doesn't do much for gameplay but it makes the map feel more alive. And finally I added powerups, I picked 4 arbitrary ideas and was able to implement them fairly quickly, the longest dev time was the UI updates to indicate to the player which powerups they got and which were active.
Please try the game and let me know any ideas or shortcomings that I can fix, the playtest feedback I got from reddit and my friends who I keep bugging to play this has been very helpful. As always feel free to ask how I coded anything and I'm happy to share
If once a week is too often for blatant self promotion let me know and I'll pull it back
I still need to do a bunch of QOL stuff on my game but after that I'm going to focus on VFX which is something I don't know anything about
the plan is to watch a video tutorial, implement the ideas in a sandbox scene, then add a small change to the game until either I can't find any obvious places for aesthetic improvement or I don't feel like working on it anymore and move on to something else
if anyone on this board has favorite tutorials either Unity specific or just general "heres what you do to keep your game from looking like shit" let me know, I'm just starting on the whole graphics thing so feel free to suggest the most basic of the basics
Posts
It strikes me very much as if (thing != null) { thing.method }, which language authors have been increasingly designing around. Like the C# null conditional operator or the Ruby safe navigation operator.
Given that, I was wondering if I were missing a Unity idiom that would compare RaycastHit objects without having to know about their internals. Or even just a more compact way of doing so, though I think the answer is just that I need to make the method myself.
Yeah you can do something like:
But a lot of this shit is just code fluff, it doesn't really mean much and is sometimes harder to understand than != null.
Is there an equivalent these days for HTML5 canvas games or has the death of flash completely fucking regressed the environment for small game makers in yet another way?
Like I know I can submit to Kongregate and Newgrounds but they aren't then syndicating the content to a thousand other places. I'm looking for a one and done kind of deal.
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.
Steam: https://steamcommunity.com/profiles/76561198004484595
Twitch: KoopahTroopah - Steam: Koopah
Did any of you participate in LDJAM 41? I would love for you to link me your game submissions if you did please!
Yeah, I agree. The standard Unity idiom (as far as I can tell) is to be involved entirely too much about the internals of a RaycastHit and know to check hit.collider before comparing hit.distance values. So I think I need to write a hit extension method for reliable comparisons.
It reminds me (by contrast) of the Sugar Punch critiques of the awful animation in NRS games. Compared to Garou, Darkstalkers, UNIEL, etc, the lack of anticipation, squash, stretch, overshoot, strong silhouettes is all very striking
I have no idea where anything is with this program and I run better with gimp
edit: Its just occurred to me that having my steam controller dongle plugged into a USB port might have screwed things up, lets unplug that and uninstall Wacom and........
My resolution just got better.
http://www.fallout3nexus.com/downloads/file.php?id=16534
I was just about to share, but here's my first LD game: SmackPaint! Combat Painting with Ross Bob
https://ldjam.com/events/ludum-dare/41/smackpaint-combat-painting-with-ross-bob
The code is ugly as heck (to bring it to the discussion previously). So many if and null checks...
Twitch: KoopahTroopah - Steam: Koopah
http://www.fallout3nexus.com/downloads/file.php?id=16534
Only if Cindi Mayweather is an unlockable character.
Twitch: KoopahTroopah - Steam: Koopah
From your Steam dongle??? I use mine all the time and haven't seen that.
I've been thinking about this during my department offsite since I woke up. I think I'm gonna start deving up a game mode when I get home in Game Maker 2. Probably just classical 'Tetris' first to start, and we'll go from there. What are some of your guys' favorite game modes from different puzzlers? I'm thinking I'd like to include modes similar to classic Tetris, standard Puzzle Fighter, Tetris Attack, Fever mode from Puyo Pop (not necessarily Puyo Pop though, just the Fever feature, building a meter when cleaning up trash that when full leads a player to a 'bonus' section that could counter your opponent with easier deliverable trash), and a power-up or item mode that provides a bit more RNG and chance for not as experienced players to have a more even playing field when playing with more advanced players. I think those five modes would provide a diverse collection of puzzlers that people love but haven't been put in a one stop shop before.
Twitch: KoopahTroopah - Steam: Koopah
What was the Tetris Attack mode?
In short, blocks come up from the bottom of the screen, and instead of randomly getting a block from a set group and spinning them to fit the current blocks in your area, you instead swap two blocks from two columns to try and make pairs of 3+. The more combos or blocks you match, the more junk gets sent to your opponent. Game ends when your opponents blocks hit the ceiling.
Twitch: KoopahTroopah - Steam: Koopah
It jumped from 1200 to 1300 width, my eyes are free
Edit: currently waiting for car brakes to get repaired and doodling afro futurism magical school space harrier
http://www.fallout3nexus.com/downloads/file.php?id=16534
Steam: https://steamcommunity.com/profiles/76561198004484595
Perhaps it's because in Fire Emblem every character is a named character with a written story and so losing any one of them feels insurmountable, or perhaps it's because XCOM pairs it's brutal randomness with significantly more depth than fire emblem. I'm not sure, but there's something about the context there such that I can't stand fire emblem but I can't shut up about XCOM
Once again, for those not in the loop, I'm porting/remastering a commercial game from 1991. The game is rather complicated and in depth and so I'm adding a badly needed tutorial system. When I licensed the source code I also got the original manual data files as well. For those who may be younger, once upon a time games came with thickish manuals that not only told you how to install the game, but also tended to be packed full of tutorials, lore, stories, maps, and other odds and ends. The final manual I have is in PageMaker 4(!) format, which can't be opened by anything under the sun anymore. However, there was a slightly older draft that was in Word 5.5 that shockingly opened with LibeOffice. This version didn't have any of the illustrations embedded, but I have those in a resource folder. I'm adding them back in now and matching the text with a PDF scan of the original manual to make sure everything is up to date. (For example the draft mentions using the manual as copy protection, which was not in the final release)
Now the problem I have is the manual is a staggering 220 pages long, but there is a lot of good content in there. Lots of in-universe roleplayish stuff. How about would you entice a player to go though a manual nowadays? Make oblique references to it in the game? Offer a dead-tree version, or maybe as an e-book and not just a PDF? The manual tickles my nostalgia bones to no end, but I don't know if current players will understand the value of the thing.
Screenshot can bee seen here.
There's also the mass effect way where once they 'unlock' a part of the lore it exists within the player's 'codex' that the player can freely peruse while inside the game.
I guess it depends on what exactly is in the manual that you think is engaging and how much time you are willing to spend converting it into a digital format.
Forgive me for any awkward wording, I am living in the BC time.
Rules of Engagement (the game I'm working on) is a starship battle simulator, but it links into an "Xcom" like game called "Breach 2" that is stand alone. You can play each other stand alone or if you have them together, will behave like a bigger game. When you take over an outpost or broad an enemy ship, ROE passes control Breach and back. IPC happens though a data file transfer. (a kind of psudo-savefile gets passed back and forth). I'm also rebuilding the interlinking part now. After the Tutorial and IGS linking, it will be into Beta for final bug squashing and graphics overhaul.
It has been a while and I decided to start yet another project following the following set of principles
1. no assets (I cheated for the floor though, didnt feel like writing a procedural texture)
2. no plan, as in no design doc, no flowcharts, no trello, no goal
3. one sentence daily dev goals/requirements obtained by asking myself "am I ready to release?" and then implementing what came after "no because....", then forcing myself to stop after I wrote "one sentence" worth of code
4. no per-emptive optimization(huge enthusiasm killer), including not following any coding or organization principles whatsoever, not even making folders in my unity project pane until I had a specific reason to
5. publish the moment I hesitate to answer "no because..." to by mantra question
complete results here: https://acp.itch.io/thewedge a hybrid endless runner + rail shooter, no instructions, should be able to figure out controls by 2nd go
playable in browser but if you have shields up you might need to switch to a more "open" browser for the game to work
~12 days of one sentence dev work and 2-3 days of proof of concept work to figure out what I wanted to make
the game is fun enough to leave as is but there is always stuff that can be added
my original plan was to release on mobile, I'll try it but i dont think tap targeting will be nearly as much fun as mousing over enemies and seeing them blow up
I'm happy to share my code or explain how I did anything if there are any non-obvious features anyone has questions about
It would probably be worth it to buy (or "find") an old copy of pagemaker to open the original files and export to another format. A quick search found this which is a reasonable price: https://www.amazon.com/Adobe-PageMaker-6-0-Education-Version/dp/B000HX1LVW/ref=sr_1_8?s=software&ie=UTF8&qid=1525697388&sr=1-8&keywords=pagemaker no idea about legitimacy but Amazon is pretty good about refunds for DOA products.
If you want some help PM me, I have some contacts that do this kind of thing so they might have a solution.
To start out with, Unity's current paradigm is "ECS" in the sense that "we stopped writing design documents and have daily standups" is "Agile". Maybe that's a slightly extreme analogy, but the point remains that right now Unity uses a more object-oriented approach to implementing ECS, and OOP is bad and for stupid people*. (I struggle to remind myself that it is irrational to feel personally attacked by a criticism of a software development paradigm, but when you've done something a particular way for ten years it's difficult to keep the statement that "this method produces worse code" from implying "and therefore people who use that method are bad programmers".) The new paradigm moves toward a more procedural style in which all operations are simple transformations of highly-compact data. This pushes the new implementation closer to the "canonical" form of ECS.
In the canonical form of ECS, the three members of the acronym have the following roles:
- Entity: Has no function but to act as an aggregation of Components.
- Component: Describes a specific attribute or behavior of the Entity. Note that it "describes" rather than "provides".
- System: Controls the interaction and transformation of Components.
What will probably be most surprising for someone used to the object-oriented model is that in this new paradigm, there is no class that represents an Entity. In the current model, there are GameObjects, which aggregate a number of behaviors related to Entities and provide things like Component-finding functions and most-common functionality like position and rotation by way of the Transform class. No such class exists in the new paradigm. Instead, an Entity is represented by a synchronized position in a set of arrays of Components.
For simplicity's sake, let's say that we only have one type of Entity, a Character, which is made of one Position, Health, Hitbox, and Sprite Component each. Then, the underlying collection of entities looks like this:
const int MaxEntities = 100; Position[] positions = new Position[MaxEntities]; Health[] healths = new Health[MaxEntities]; Hitbox[] hitboxes = new Hitbox[MaxEntities]; Sprite[] sprites = new Sprite[MaxEntities];(I should note that you, the programmer/Unity user does not declare these collections. This is just a pseudocodey way of representing what I suspect Unity does behind the scenes with your Component classes and the big Entity/GameObject tree structure.)If you need to refer to a specific Entity, your one and only method of doing so is to know the index of the Entity in the component arrays. positions[37] is the position information for entity #38. healths[37] is the health information for that same entity. And so on. But there is no Entity class by which anything in the system can refer to an Entity. And, for our purposes, that's actually a good thing. Nobody should ever need to refer to a specific Entity. They should only care about Components.
Now, there are different types of Entities, defined by which Components they have. There might be, say, a light-emitting Entity that has a Position, some lighting information, and a Sprite, but no Health or Hitbox. These are stored in separate collections from, say, the Components that make up the Character Entities.
Components in the new paradigm are also significantly different from the Monobehaviors we're used to. Monobehaviors have hooks to override a large number of behaviors, like startup logic through OnStart() or routine updates through Update(). This is no longer the case in the new model. Now, Components are effectively structs. They do not have behaviors other than, perhaps, helper functions for composite transformations. A Position Component from my example isn't like a Transform, with its ability to create an object hierarchy. It's just a vector with a 2D position (I'll say it's 2D because Characters render through Sprites). Health is just a simple floating-point counter with maybe a set function that handles value clamping. Hitbox provides a position-relative width, height, and offset. And so on. However, Components don't have behavior. They don't interact, they don't send or receive messages, they don't "think", they just sit there and expose data.
The only thing in the new paradigm that actually has behavior is a System. The role of a System is to pick up a set of Components that it's interested in and either transform them in some way or to produce data that can be consumed by a subsequent System that's part of a data pipeline. My comprehension of how exactly Unity's new ECS paradigm handles this is blurry, but essentially you declare a set of queries that will be used by your System class, which then produce synchronous streams of the appropriate Components. For instance, let's say that we wanted to make a System called SpriteRenderingSystem that draws Sprites at the point in space given by a Position component. The SpriteRenderingSystem would (somehow) declare that its input query should accept any Entity which has a Position component and a Sprite component. You'll notice that in this example, that includes both Characters and Lights. It doesn't matter if an Entity is a Character or a Light, only that it has a Position and a Sprite to render. The SpriteRenderingSystem goes through its component queries (which are known to be synchronized), and draws each Sprite centered at the Position that matches it. It does that not only for the existing Character and Light entities, but also for any future Entity that has both a Position and a Sprite to render. When you later create an Particle Entity archetype that also happens to have a Position and a Sprite Component, the SpriteRenderingSystem picks them up and draws them without any further changes.
Now, this is all what so far. The more important question is why. Why is this system better than what we have now? The first thing that comes to mind is simplification of the behavior code. Separation of concerns is a noble principle, but an excessive reliance on subclassing, virtual functions, and event publication can make the flow of your gameplay logic extremely difficult to track. In this new paradigm, the use of callbacks, publication and subscription, and so on is minimized, meaning you have a smoother, forward-facing flow to your game's behavior. A more obscure concern is the idea of cache coherency. (I'm putting cache coherency in the middle because people tend to forget the middle element of a list.) In an object-oriented approach, you tend to have objects that are linked together through pointers to highly diffuse areas of memory. Cache misses are a huge trouble spot for losing performance at a low level, because pulling new pages in from RAM takes a dog's age in microprocessor time. In this new approach, related Components are very tightly packed together. As the SpriteRenderingSystem iterates over the paired Position and Sprite elements, it's working on values that are close together in memory, resulting in much fewer cache misses. But the real gain here is in parallelism. By defining a very rigid pipeline and limiting the cases under which the Component data may be transformed, the new paradigm lends itself well to partitioning its operations into small, easily-distributed chunks. (I know that the Boids example in the GDC had most of its services implementing an "IParallelForJob" (or similar) interface whose one function took an index parameter indicating which element in the query arrays it was supposed to operate on.) This means that you barely have to think about locks, mutexes, and so on-- Unity handles the thread coordination, and you only write the code that runs on any individual thread.
I'll admit that there have been certain concepts that I'm still not confident I understand how to port over (for instance, how exactly the system handles the creation and destruction of Entities, if you're allowed to give an Entity a new Component at run-time, how one refers to a specific paired Component from another Component, how to represent when-x-then-y event logic, and so on), but at this point I feel that's more a failure of my own comprehension than a fault of the new paradigm, and though I still resent Unity's habit of publishing hour-long videos rather than text tutorials, I'll probably wind up sitting through a few more to see if I can shake off the remaining clouds. Thanks for muddling through my overlong (and likely incorrect) explanation. If anything seems unclear (or outright wrong), feel free to ask questions (or correct me).
* This last impression is not a feeling I got from the Unity presenter; rather, it is a sense I've got from some of the Internet's more passionate detractors of OOP.
If you're having the same problem, you're not alone:
It's fixed in the beta branch, but it the LTS will receive a backport of the patch "in the near future", which is too long for me. Which means I just now learned that the Unity Hub is basically rbenv but for Unity??? I'm very into it, and I'm def using it from now on.
several changes based on reddit feedback including adding instructions to the html display page and decreasing the "fade" times to be less arty and more practical
the game has kind of the look of a rhythm game so I'm probably going to try replacing the continuous player movement with instant re-positioning based on which key is pressed, which will also take care of the "unfair" obstacle formations that pop up sometimes
I'm pretty happy with the results but there is always more that can be added
makes things pretty simple to at least try on your own even if I dont quite grok how this would be useful for gameplay functions, I can already see how it could replace particles for some types of vfx
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Based on player feedback I changed the controls from continuous movement to teleport based. Now the game works like an "anti-guitar hero" where you get out of the way of the falling notes instead of pressing the key on time. I had multiple reports that the 3 key controls (A S D) were awkward and was suggested a couple of different control schemes which I plan on implementing.
Also based on suggestions i removed the "gameover" screen and rolled it into the gameplay screen, that removes a couple of clicks and some fade time before you can restart a game One minor details is I added animations to the obstacles so they "pop open" when the player gets close to them, it doesn't do much for gameplay but it makes the map feel more alive. And finally I added powerups, I picked 4 arbitrary ideas and was able to implement them fairly quickly, the longest dev time was the UI updates to indicate to the player which powerups they got and which were active.
Please try the game and let me know any ideas or shortcomings that I can fix, the playtest feedback I got from reddit and my friends who I keep bugging to play this has been very helpful. As always feel free to ask how I coded anything and I'm happy to share
If once a week is too often for blatant self promotion let me know and I'll pull it back
the plan is to watch a video tutorial, implement the ideas in a sandbox scene, then add a small change to the game until either I can't find any obvious places for aesthetic improvement or I don't feel like working on it anymore and move on to something else
this tutorial on adding particle effects to UI elements popped up on reddit and it seems like a good place to start:
if anyone on this board has favorite tutorials either Unity specific or just general "heres what you do to keep your game from looking like shit" let me know, I'm just starting on the whole graphics thing so feel free to suggest the most basic of the basics