Adventures in Unity

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

Post Reply
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Adventures in Unity

Post by Pepsi Ranger »

Hi All,

As I stated recently in my "Entrepreneur Central" post, I've started learning the Unity Engine in an effort to expand the reach of my game, Entrepreneur: The Beginning, from both a design standpoint and a player experience standpoint. This also means I've started learning C#, a language I've wanted to learn ever since I'd seen what types of games it can make, and it means learning about the many different ways I can make the game I want and not just the game I hope is possible.

This thread will be a collection of lessons I've learned while teaching myself a new engine, a new language, and a new experience while adapting the lessons I've learned on the OHR and its plotscripting counterpart. Most of my posts on the matter will be linked to my blog to preserve formatting and other bells and whistles, but those articles may speak in more general terms than I would like, to appeal to a broader audience (mainly those who might be afraid of learning how to make games but want to learn anyway), and much of what I want this thread to be about is the story of what it's like to convert an OHR game to a different engine and scripting language, and evaluate whether the journey is worth it.

I think the best place to start, then, is to talk briefly about the differences between the two engines (and scripting languages) that I've discovered. If any of you use Unity, then this would be the perfect place to sound off on your own experiences, too.

I also hope that this thread will serve as an ideas board for the developers to consider for the OHR some day, especially now that I can see how well the OHR performs among the giants, but also why it still has a few mountains to climb.

For reference, I'm learning the engine via Unity's Web docs and a course I bought on Udemy a couple of years ago called "Complete C# Unity Developer 2D - Learn to Code Making Games." I haven't yet watched Unity's tutorial videos (I think I have to pay for them, which I don't want to do if the Udemy course is sufficient). I may give them a look at some point, though, if I think it'll be necessary.

So, that's a quick overview of "Adventures in Unity." I'll speak about a handful of the differences I've learned in the next post to keep from cluttering this one. I hope you'll keep up with this thread as I report on progress. I think learning one engine and one language is fine, just like learning one spoken language is fine. But learning a few others makes us more versatile and improves our way of thinking, planning, and organizing, so I think this will be a useful thread to keep up with and contribute to if any of you want to add to the discussion. I'll try to keep the thread informative and entertaining. I hope this will also work well as a thread to promote sound design practices, something I wish I had learned more about in my early days of learning how to use the OHR, practices that people like TMC have been great at showing me how to do (like reducing code down to functions, for example). Again, this thread can be a useful tool for learning how to think about game design as it is about learning a new engine in the shadow of learning game design from the OHR.

With that, let's begin the discussion.
Place Obligatory Signature Here
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

First of all, the OHR and Unity are not terribly different in practice, even though they are vastly different in design.

Both engines promote clustering items into groups for easy access:

1. The OHR groups its assets into menus by function (graphics menu, maps menu, battle menu, items menu, sounds menu, etc.).
2. Unity groups its assets by custom folders (the user decides how to categorize the items he wants and can group them accordingly).

Both engines allow for pre-designed elements:

1. The OHR allows for slice collections, which groups various elements together for a specific layout, like UI windows, sprites, and so on, which can be generated in-game via scripting.
2. Unity has a feature called "prefabs," which allows the user to save each state of a game object for quick access, allowing the user to generate levels quickly and efficiently, and renders the objects on the scene as soon as the scene is loaded (without the need for extra scripting).

Both engines use scripting, but do so in different ways:

1. The OHR groups all of its scripts together, and the user can call specific scripts from a vast pool and attach them to certain elements like "on map enter," "at each step," and so on. All non-player actions will be called from these scripts.
2. Unity attaches scripts and other "components" to specific objects designated by the user, and that object will run its functions based on the script or components attached to it. Each component has its own rules and may include executing a script, playing a sound on collision, falling due to gravity, etc.

Both engines allow for internal game testing, sort of:

1. The OHR loads a separate instance of the game outside of Custom for the user to test and requires a restart with every change made to the game.
2. Unity allows for side-by-side comparison of the editor and the game, and allows for "tweaking" elements in the middle of gameplay so that changes made can be experienced in real-time.

Both engines have systems in place for debugging:

1. The OHR offers vague interpreter-related reports but extensive "trace value" options for identifying trouble spots.
2. Unity's "Console" displays all errors in real-time and generally knows exactly what the errors are and roughly what might be causing them. Additional commands like "Debug.LogError()" allow the user to call for even greater bug reporting and faster squashing.

Both engines have flexible scripting options:

1. The OHR has a simple custom coding process that's easy to understand and execute, and generally follows the same standards throughout all scripting options. It's quite accessible to beginners.
2. Unity uses C# (and I think Java), which has a steeper learning curve, as it scripts according to folders, not just straightforward commands, but provides more options, including float values, which I've learned is a fancy way for referring to decimals.

Where the OHR is limited:

Perhaps one of the greatest advantages Unity has over the OHR that I can see at the moment, besides the obvious ability to make games in 3D, or to apply physics, lighting, etc. to any game object, or to construct levels based on prefabs, thus speeding up the design process exponentially (imagine having the flexibility to import/export any aspect of the game scene to a new scene and retain all of the same elements, save for a few minor tweaks to specific game object to provide some element of variety) is its ability to "serialize" variables and other elements right into the editor. What this means is that by serializing a field, the user no longer has to hard-code it into the script. He can change values of variables right in the editor. There is also a way to implement a range slider (really handy for games that require skills distribution, for example), giving the user acceptable parameters in which to experiment with gameplay options. In the "Block Breaker" example from the Udemy course, a slider is used to control game speed right in Unity's "Inspector" window, allowing the user to decide how fast the game should run on that particular scene. It's quite useful to see changes updated on the fly. I also find it incredibly useful that Unity can generate collision points to match the object's shape. The OHR can sort of do this via wallmaps, but they are always square and don't allow for natural physical reactions on collision. That may change someday, though.

Where Unity is limited:

Unity doesn't have a hamster as its mascot. It also requires external programs for graphics, but more importantly, it doesn't have a hamster as its mascot.

In short, Unity has elements in place that make design and testing of levels, functions, etc. run much faster and more efficiently than what we currently can do on the OHR. The disadvantage Unity has to the OHR, however, is that scripting is more confusing, as commands are ambiguous compared to the OHR's well-labeled, well-documented commands. I actually think the OHR makes plotscripting too simple to understand. I'm challenged trying to brain-muscle my way through Unity's C# syntax. Unity makes up for it, though, by allowing the user to attach specific scripts to specific game objects, thus giving those objects specific properties that define what they actually are and how they respond to actions in the game world. It's a bit like adding a soul to the game object, which doesn't work quite so directly in the OHR (even though the concepts of adding scripted elements to specific objects in the game world are definitely present in the OHR--the difference is that Unity allows script attachments to everything in the game world, while the OHR is still limited to specific elements like NPCs, menu selections, etc.).

And that's for starters. There's more to say about the differences between the two, but I want to give others a chance to respond and make comparisons if applicable.

I'll also be posting links to my "Adventures in Unity" blog series as soon as they go live. That'll probably start next week.
Place Obligatory Signature Here
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

This was a good read.

Unity *does* need a hamster ;)

I was able to watch a bunch of the official unity tutorial videos for free. They were good.

The unity feature that let's you edit script variables in the editor is awesome.
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

The unity feature that let's you edit script variables in the editor is awesome.
This is quite honestly my favorite part about the engine so far. It's one of the few scripting concepts I was able to grasp immediately (you have to script a serialized field with every variable you want to change in the editor), and certainly the one I most appreciate, as I like to test variables often to see how they play with other variables. For a game as complicated as Entrepreneur: The Beginning, I can see the advantage of having all of those values on display in a place where I can see them working. I like that this works for both integers (whole numbers) and floats (decimals). The slider is super cool, too, if you decide to use one.

Oh, and you can watch the values change in the Inspector as the game plays. That's really useful.

I don't know how reasonable it would be for the OHR to employ such a tactic. I think it would be quite helpful, especially in the NPC editor (where I see its greatest benefit), but the way Unity does it is that you have to script the feature onto the game object, so if the OHR did something similar, it would look something like:

Code: Select all

serialize script, Script Name, begin
variable
end
or

Code: Select all

script, Script Name, begin
serialize variable
end
or

Code: Select all

script, Script Name, serialize variable, serialize variable, begin
end
or

Code: Select all

serialize script, Script Name, begin
serialize variable
end
or some other similar function that would unlock variables in the editor wherever the script is attached.

I don't know. It might be too complicated, especially if you have separate fields for globals and locals. But still, I like the function, and I think the OHR would benefit from something similar. It would certainly save time on compiling the script with every change.
I was able to watch a bunch of the official unity tutorial videos for free. They were good.
I'll probably watch them after I read through the docs. There are a lot of docs, and they aren't that interesting. I do like the online doc layout, though. I'll bet we could do something similar for the OHR, especially now that we have nearly every element already defined in the F1 help menu. Would just be a matter of porting text over to a series of pages. But, yeah, I think I'll need to watch them. This whole experience is a bit like learning how to fly a jet two weeks after learning how to drive a car.
Unity *does* need a hamster ;)
This is a fact.
Place Obligatory Signature Here
User avatar
shakeyair
Slime Knight
Posts: 217
Joined: Fri Jun 12, 2009 6:15 am

Post by shakeyair »

I thought I'd chime in since I somewhat recently got back into game dev through Unity - having recently released Where the Cloud Lives for Ludum Dare 42 (48 hour compo!) earlier this month. I know Unity fairly well and there are some things you said that I feel are just a little off, so I thought I'd try and clarify a bit.

EDIT: The code is a bit slop because it was made in 48 hours, but 'Where The Cloud Lives' source can be downloaded from the itch.io page if you're curious as to how it was put together, and I'd be happy to answer any questions - although the answer may very well be "I don't recommend doing it that way" lol.
Pepsi Ranger wrote: Both engines promote clustering items into groups for easy access:

1. The OHR groups its assets into menus by function (graphics menu, maps menu, battle menu, items menu, sounds menu, etc.).
2. Unity groups its assets by custom folders (the user decides how to categorize the items he wants and can group them accordingly).
You don't have to use folders at all, but it's much easier if you do. There's nothing special about Unity folders, they're the same as filesystem folders (although Unity will only 'see' folders inside your project directory).
Pepsi Ranger wrote: Both engines allow for pre-designed elements:

1. The OHR allows for slice collections, which groups various elements together for a specific layout, like UI windows, sprites, and so on, which can be generated in-game via scripting.
2. Unity has a feature called "prefabs," which allows the user to save each state of a game object for quick access, allowing the user to generate levels quickly and efficiently, and renders the objects on the scene as soon as the scene is loaded (without the need for extra scripting).
Just in case it's unclear from this, prefabs actually encompass much more of a standard Unity workflow than slice collections do for OHR. In Unity, you'll probably have a 'Player' prefab, a 'Pause Menu' prefab, various 'Enemy' prefabs. Often you use prefabs for objects that don't have any graphical representation, like a 'Game Manager' prefab or 'Audio Manager' prefab or any other object that's only purpose is to manage other objects or the game state.
Pepsi Ranger wrote: Both engines use scripting, but do so in different ways:

1. The OHR groups all of its scripts together, and the user can call specific scripts from a vast pool and attach them to certain elements like "on map enter," "at each step," and so on. All non-player actions will be called from these scripts.
2. Unity attaches scripts and other "components" to specific objects designated by the user, and that object will run its functions based on the script or components attached to it. Each component has its own rules and may include executing a script, playing a sound on collision, falling due to gravity, etc.
The biggest difference, though, is that Unity scripts will encompass basically all your game logic. A Unity game without any scripts doesn't do anything, whereas you can create a complete OHR game without using any scripts. Note that there are 3rd party additions to Unity that allow for making certain kinds of games with no programming, but I've never used any and can't vouch for their effectiveness. (And they are always using scripts under the hood)
Pepsi Ranger wrote: Both engines allow for internal game testing, sort of:

1. The OHR loads a separate instance of the game outside of Custom for the user to test and requires a restart with every change made to the game.
2. Unity allows for side-by-side comparison of the editor and the game, and allows for "tweaking" elements in the middle of gameplay so that changes made can be experienced in real-time.
Changes made in Unity while previewing the game will be updated in-game in real time, HOWEVER all changes will be reverted once you stop previewing the game. Which can be kind of frustrating sometimes.

Also, doesn't GAME update live with new versions of graphics now? I seem to remember that being the case last time I used it.
Pepsi Ranger wrote: Both engines have systems in place for debugging:

1. The OHR offers vague interpreter-related reports but extensive "trace value" options for identifying trouble spots.
2. Unity's "Console" displays all errors in real-time and generally knows exactly what the errors are and roughly what might be causing them. Additional commands like "Debug.LogError()" allow the user to call for even greater bug reporting and faster squashing.
Unity also offers an 'Immediate Mode GUI' (a graphical interface redrawn every single frame) for debugging rapidly changing values that would be hard to track in the Console.
Pepsi Ranger wrote: Both engines have flexible scripting options:

1. The OHR has a simple custom coding process that's easy to understand and execute, and generally follows the same standards throughout all scripting options. It's quite accessible to beginners.
2. Unity uses C# (and I think Java), which has a steeper learning curve, as it scripts according to folders, not just straightforward commands, but provides more options, including float values, which I've learned is a fancy way for referring to decimals.
Unity uses C# as well as a heavily modified version of Javascript (Unityscript). C# is highly recommended by the community and most tutorials use C#, probably because it's a standard implementation of C# instead of a custom language.Unity is actually written in C#, to give you an idea of the flexibility of the language.
C# was popular for game-dev before Unity from a framework called 'MonoGame' which is mostly dead today but some people do still use.

A 'float' referring to a decimal is not a new Unity thing, but a general feature of many strongly-typed languages. It does not just mean decimal, it means that the number is stored as a 'floating point' approximation of the number. So, it's not completely accurate, but in practice they will be accurate out to enough decimal places that you won't notice the issue... except that if you don't truncate the decimal yourself you may find that you set a number to, say, 0.2, and it displays as 0.20000000001.
Pepsi Ranger wrote: Where Unity is limited:
In short, Unity has elements in place that make design and testing of levels, functions, etc. run much faster and more efficiently than what we currently can do on the OHR. The disadvantage Unity has to the OHR, however, is that scripting is more confusing, as commands are ambiguous compared to the OHR's well-labeled, well-documented commands. I actually think the OHR makes plotscripting too simple to understand. I'm challenged trying to brain-muscle my way through Unity's C# syntax. Unity makes up for it, though, by allowing the user to attach specific scripts to specific game objects, thus giving those objects specific properties that define what they actually are and how they respond to actions in the game world. It's a bit like adding a soul to the game object, which doesn't work quite so directly in the OHR (even though the concepts of adding scripted elements to specific objects in the game world are definitely present in the OHR--the difference is that Unity allows script attachments to everything in the game world, while the OHR is still limited to specific elements like NPCs, menu selections, etc.).
Commands are more ambiguous in Unity due to C# being a general purpose programming language as opposed to a scripting language. Unity is actually written largely in C#. Unity has no in-engine designations between a 'hero' and an 'NPC' and has no idea what 'walking' means. It expects you to make those distinctions yourself. It also uses an object-oriented programming paradigm, and inheritance can be tough to wrap your head around at first.

Basically, Unity expects you to make your own component-based abstractions, which allows for more freedom but also comes with a significantly higher learning curve.

Hope that helped to clarify a couple of things!

EDIT 2: Also once you've done a couple of the official tutorials, I highly recommend Catlike Coding's Unity Tutorials. You may run into a handful of deprecated functions, but Visual Studio will usually tell you what to use instead.
Last edited by shakeyair on Tue Aug 21, 2018 3:34 am, edited 3 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Oh, nice to hear from you again, Shakeyair! Have you been working on more than a Ludum Dare entry?

The OHR has a lot to learn from engines like Unity. Our scripting system is very hobbled due to only having a few script triggers such as each-step instead of attaching event handlers to objects like NPCs and slices, and not being able to run multiple scripts at once.

Yes, the OHR lets you edit almost all game data live, not just graphics.
However, typically you have to exit and reenter whatever part of your game to see changes. E.g. to see changes to a menu you have to close and reopen it, for enemy stats you have to exit and restart a battle or spawn a new enemy. Heroes are the worst; a lot of changes to heroes don't take effect unless a new hero joins the party.
But graphics and maps update instantly.

Unity has the advantage in that the editor and the game are running as a single program, so if you edit something you're also editing the running game directly.
The OHR works differently: the editor and game are two separate programs and the editor tells the running game to reload data. That means we need to write code to do the reloading manually. It'll never be as complete, but it turns out you can get pretty close without too much effort.
Bob the Hamster wrote:The unity feature that let's you edit script variables in the editor is awesome.
It seems there's really two different parts to this.
Being able edit the value of any variable in the script debugger is something I want to implement in the OHR. (Plus an entirely new script debugger, similar to what you see in other engines.)
Separately, letting you define new 'serialisable' data fields in editors in Custom (e.g, give all NPCs an 'HP' value in the NPC editor) is another thing I'm keen to add.

Now, editing the values of variables in a debugger is a pretty basic feature.
The next step up is hot-swapping in edits to the code itself:

Bret Victor - Inventing on Principle
https://youtu.be/PUv66718DII?t=226

The OHR can kind of do this too (provided that the script isn't stuck on a wait command), but instead of being instant, you have to save your .hss file and reimport it by pressing F9 in Custom to see the changes in-game. That takes about 3 seconds in total (unless your scripts are the length of a phonebook). I'm going to add an option to auto-reimport the scripts when you save the .hss file. Then you'll be able to see your changes in a split second!

But that's nothing.

The next step is to be able to pause the program, rewind it to a previous point - say, before some bug happened - and then be able to inspect data, change it, hot swap in new code, and resume the game or fast forward back to where you were.
This is called time-travel debugging, or reverse debugging.

I've been thinking long and hard about how to implement that in the OHR. It's incredibly difficult but I think it's possible. Actually, James already did a some of the work when he implemented input recording!

Still, that's not all.
THIS is what the future looks like.

https://youtu.be/PUv66718DII?t=822
Last edited by TMC on Tue Aug 21, 2018 7:33 am, edited 8 times in total.
User avatar
shakeyair
Slime Knight
Posts: 217
Joined: Fri Jun 12, 2009 6:15 am

Post by shakeyair »

TMC wrote:Oh, nice to hear from you again, Shakeyair! Have you been working on more than a Ludum Dare entry?
:o I'm surprised you remember me. I have been continuing to do exactly the same thing I did with the OHRRPGCE: Tech demos and proof-of-concepts that never go anywhere! :D

The most recent thing I've shared was a bezier-spline-based 2.5D platformer, although I haven't even opened it since July.

I tell myself that I'm waiting for the idea I believe in strongly enough to sink a few years into, but lately I've had the sneaking suspicion that I just don't have very much discipline. :v: Currently trying to make all my ideas smaller!

I do program a lot outside of games, though -- Web dev mostly, but I'm starting grad school for CompSci next month. Haven't ever really thought about it before, but I'm not sure if I would've wound up down this road if not for the OHR - Hamsterspeak was the first programming language I ever learned! That's pretty cool... Many thanks to you and James!
TMC wrote: Bret Victor - Inventing on Principle
I'm loving this talk: "I have better things to do with my head than simulate what electrons are doing!" Yes!
I'm seeing a bunch more talks by him in the sidebar too, and I'm about to watch them all. :devil:
TMC wrote: The OHR can kind of do this too...
Whoa, cool. How long has it been able to do that?
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Oh yes, of course remember your tech demos! They were very impressive! OHRPAL.hss still goes way beyond the OHRRPGCE's own graphics editor... In fact, I'm tempted to ask whether we could incorporate parts of it into the engine someday (would like to allow scripts to run in Custom as well).
I would not have guessed that HamsterSpeak was your first language! You really seemed to know what you were doing already. So it's really awesome to hear it was such a significant stepping stone for you.
And in a fun reversal, cuckoo.rpg is actually pretty influential on me. That is what I want the OHR to support out of the box! I'm still working towards it.

And, compsci and creating endless tech demos which never go anywhere go hand in hand :/
However, this 2.5D platformer is really nice! It doesn't look like just a tech demo, it looks like you have most of a game here! Are you planning to return to it and make something out of it?

Bret Victor is probably a genius; also, check out his website. He co-founded a research lab with Alan Kay!!
shakeyair wrote:Whoa, cool. How long has it been able to do that?
4 1/2 years, but it didn't work as well and was disabled by default until the last release, Etheldreme.
To get the most use of it you have to avoid scripts being un-reloadable due to waiting on a wait. For example I always rewrite "while(...) do (...wait(1))" loops as "while(...) do (eachtick(), wait(1))"
Last edited by TMC on Thu Aug 23, 2018 2:00 pm, edited 5 times in total.
User avatar
shakeyair
Slime Knight
Posts: 217
Joined: Fri Jun 12, 2009 6:15 am

Post by shakeyair »

TMC wrote:Oh yes, of course remember your tech demos! They were very impressive! OHRPAL.hss still goes way beyond the OHRRPGCE's own graphics editor... In fact, I'm tempted to ask whether we could incorporate parts of it into the engine someday (would like to allow scripts to run in Custom as well).
Of course! You (and anyone else) are more than welcome to do anything you want with any of the stuff made with the OHR that I've released to date.

Adding scripting to Custom is a great way to get the community involved in making the tools better. Several standard features in Unity were originally community-made 'assets' that got rolled into the engine. Godot does this too, and is so decoupled that even its 'GDScript' language is a 'module' loaded by the editor.
TMC wrote: I would not have guessed that HamsterSpeak was your first language!
You really seemed to know what you were doing already. So it's really awesome to hear it was such a significant stepping stone for you.
Well I was around for a long time without releasing anything. Castle Paradox says I joined in 2004 but I think I just had a different username before that. Either that or I went and deleted the handful of short demos I uploaded at some point.
TMC wrote: And in a fun reversal, cuckoo.rpg is actually pretty influential on me. That is what I want the OHR to support out of the box! I'm still working towards it.
Haha, well it was me trying to implement everything I wanted the OHR to support out of the box too! Except transparency, which I figured I couldn't do much about.
TMC wrote: And, compsci and creating endless tech demos which never go anywhere go hand in hand :/
Well at least I'll fit in, lol.
TMC wrote: However, this 2.5D platformer is really nice! It doesn't look like just a tech demo, it looks like you have most of a game here! Are you planning to return to it and make something out of it?
I'm stuck on some of my story ideas and some new too-smart-by-half 'totally modular' player/enemy code. I'm also concerned about doing artwork in 3D effectively, and kind of scared of shaders.

Mostly, I'm really hoping to come up with a satisfying way to cut the planned scope way down. I envisioned it as this huge Metroidvania because I was obsessed with Hollow Knight at the time but I'm trying to re-think it as a puzzle platformer now.
TMC wrote: Bret Victor is probably a genius; also, check out his website. He co-founded a research lab with Alan Kay!!
Definitely. Thanks for putting him on my radar.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

More tech demos on CP? I wonder!

Being able to extend the engine yourself with scripting would definitely be wonderful, and would make it about 10x easier to contribute. You aren't the only person to try to create some kind of utility, despite all kinds of infuriating limits. So I definitely believe there's demand for it. As another example, quite a few people have wanted the ability to read/write text and other files too.

As for cuckoo.rpg, everything in it is already partially implemented in the engine and I expect not far off. We've been working on 24-bit color depth too :)
shakeyair wrote:Mostly, I'm really hoping to come up with a satisfying way to cut the planned scope way down. I envisioned it as this huge Metroidvania because I was obsessed with Hollow Knight at the time but I'm trying to re-think it as a puzzle platformer now.
Ah! That's not what I was imagining. Yes, if you want to make some big Metroidvania out of it then a tech demo really only gets you a tiny part of the way there. I was thinking of puzzle-platformer with abstract graphics. There quite a lot of indie games like that now - the graphics can be pretty abstract if the gameplay is engaging.
Last edited by TMC on Sat Aug 25, 2018 1:54 pm, edited 1 time in total.
Post Reply