• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.
How does Ori And The Blind Forest put together a world this big with seemingly no barriers between areas to load into? How do you approach that?

edit: Sorry for double posties!

That's a question for Thomas I'm sure, but I think it's a lot of carefully hand-placed invisible triggers. There are a few places where you can feel the game lagging as it loads in new assets. The one that sticks out at me is near the beginning of the escape from the water temple, but there are a few other places where it chugs as well.

In a more general sense, or in a game with a larger scope (like open world AAA titles) I'd probably stick the assets in a quadtree and stream in assets on another thread, polling for updates once or twice per second.
 

Jobbs

Banned
Since they are using Unity I imagine they use something like additive level loading. Source: my ass.

There is a way to find out but I'm not going to mention it here :X

I get they must sorta stream things in as needed, I mean, I sorta get that as a general concept, but how do you approach that? How do you design and implement the levels? How is this done and what sorcery is it?
 
I get they must sorta stream things in as needed, I mean, I sorta get that as a general concept, but how do you approach that? How do you design and implement the levels? How is this done and what sorcery is it?

I haven't played Ori yet, but in general to load two distinct areas you usually need three areas.

Area 1
Area 1-2 Loading
Area 2

When you enter Area 1-2 Loading the game starts to load Area 2 asynchronously, so by the time you get to the end of Area 1-2 Loading (however long it may be) Area 2 is already ready to go.

Once the game is sure that you're in Area 2, it can unload all of the assets pertaining to Area 1, and a little later Area 1-2 as well, if need be. Going from Area 2 to Area 1 works the same way, just in reverse. Depending on the setup, there is usually a window where all three areas are loaded into memory, which is why it's important to unload things as soon as you can, if you have tangible memory constraints.

Asynchronous loading is pretty game-specific, as each game will have different criteria for what it needs, and when. Generally speaking, 2D platformers and 3D linear shooters are the easiest, as they usually have easily defined "areas".

In a more general sense, or in a game with a larger scope (like open world AAA titles) I'd probably stick the assets in a quadtree and stream in assets on another thread, polling for updates once or twice per second.
A quadtree might be a bit overkill there -- it'd probably be better (and faster) to stick areas of the world in "chunks" (think Minecraft) and load chunks as needed. Inside of the chunk you could organize things into a quadtree, though, as that would give you some very fine granularity as to what you need loaded, and when. As a bonus, the chunk+quadtree design would make occlusion culling pretty easy, as you'd only need to analyze the quadtree in the visible chunks -- if a chunk is directly behind you you can safely disable that whole chunk without doing any kind of slow visibility checking.

EDIT: Actually, now that I read that back my chunk design is kind of like a super low-tech quadtree. Anyway, you get the idea -- your quadtree idea is fine, but you'd generally want multiple levels of granularity, so you can implement broad-phase visibility/proximity checks as a first-pass.
 
I haven't played Ori yet, but in general to load two distinct areas you usually need three areas.

Area 1
Area 1-2 Loading
Area 2

When you enter Area 1-2 Loading the game starts to load Area 2 asynchronously, so by the time you get to the end of Area 1-2 Loading (however long it may be) Area 2 is already ready to go.

Once the game is sure that you're in Area 2, it can unload all of the assets pertaining to Area 1, and a little later Area 1-2 as well, if need be. Going from Area 2 to Area 1 works the same way, just in reverse. Depending on the setup, there is usually a window where all three areas are loaded into memory, which is why it's important to unload things as soon as you can, if you have tangible memory constraints.

Asynchronous loading is pretty game-specific, as each game will have different criteria for what it needs, and when. Generally speaking, 2D platformers and 3D linear shooters are the easiest, as they usually have easily defined "areas".

I think Jobbs is commenting on how invisible these transitional areas are. Lots of games are obvious about it by putting in long hallways, doors that take suspiciously long to open and then close right after you pass through, or elevators between regions.
 

Blizzard

Banned
Side note about streaming, I was hoping I could play one of my favorite games ever, Mirror's Edge, on my GTX 770 2GB with PhysX. Unfortunately, even with the latest PhysX, performance got completely destroyed (5 fps at 1680x1050) when a lot of glass would break. The glass doesn't even look that great to me, but that's another story. The cloth looks decent and there's some okay fog in one place but that also killed the performance. I double-checked and made sure the card was selected for PhysX, but maybe it just can't handle PhysX and 16xQ antialiasing.

How this ties into loading is that Mirror's Edge streams and unstreams parts of levels, using Unreal Engine 3. When glass would break and performance would tank, if I managed to somehow grind past the 5 fps parts, I think sometimes I might have made it far enough where performance would go back up again because those early parts of the levels got unloaded.

Mirror's Edge definitely uses some of the classic elevators though, even though systems now might be able to load and unload fast enough.

*edit* Personal pet peeve, though I love the game: There's one spot on a ship that uses the "really slow-turning door unlock wheel" method of masking loading. Unfortunately, the level checkpoint is put right before the wheel, so if you load that part of the level and then die you STILL have to wait through the wheel again to make another attempt. Even though the level is now already presumably in memory.
 

Jobbs

Banned
I think Jobbs is commenting on how invisible these transitional areas are. Lots of games are obvious about it by putting in long hallways, doors that take suspiciously long to open and then close right after you pass through, or elevators between regions.

Exactly. Ori is a world where you kinda go in various directions and there's no "seam" that you can really see, and while I can sort of imagine as a general concept how this might work, I can't imagine how one approaches this both in a technical sense and a design sense. I can't imagine, for example, (and this may be something I need to be brutally corrected on, since I don't have really any personal experience with Unity) having one 3d space to work from that spans the entire game world when you're using Unity -- It seems like it'd just be too large to be practical, so how do you join those babies together and do it seamlessly as one coherent world?
 
I think Jobbs is commenting on how invisible these transitional areas are. Lots of games are obvious about it by putting in long hallways, doors that take suspiciously long to open and then close right after you pass through, or elevators between regions.

Those are just some examples of transitional areas, it's entirely possible to design transitional areas that you (the player) doesn't even know is a loading zone.

In my opinion, those are poorly designed loading zones (e.g. the semi-rare 2-3 minute long elevator rides in Mass Effect).

You could also have levels divided up into three or four areas that you load or unload at will, and have a certain number of "zones" active at once. So, for example:

You start level 1. You have zones 1-1, 1-2, and 1-3 loaded.

You enter level 1, zone 1-3. You unload zone 1-1, and load level 2, zone 2-1.

You complete level 1 and move to level 2-1, you now load zone 2-2 and 2-3, while keeping 1-3 loaded in case the player backtracks.

If the player continues into zone 2-2, you unload all zones from level 1, as you can reload them if the player enters zone 2-1 again.​

Handling things that way, you never have to have a "transitional" area, as you're streaming in what's needed ahead of time based off of what you think the player is progressing toward.

EDIT:
Exactly. Ori is a world where you kinda go in various directions and there's no "seam" that you can really see, and while I can sort of imagine as a general concept how this might work, I can't imagine how one approaches this both in a technical sense and a design sense. I can't imagine, for example, (and this may be something I need to be brutally corrected on, since I don't have really any personal experience with Unity) having one 3d space to work from that spans the entire game world when you're using Unity -- It seems like it'd just be too large to be practical, so how do you join those babies together and do it seamlessly as one coherent world?
Unity has additive scene loading, so you can stitch separately-designed scenes together at runtime. As long as you know that the end of scene 1 connects to scene 2, you can design them in such a way that they get stitched together seamlessly while playing.

You could even design one level in one scene and then split them up into three scenes (zones) to load additively, if that's easier.
 
Those are just some examples of transitional areas, it's entirely possible to design transitional areas that you (the player) doesn't even know is a loading zone.

In my opinion, those are poorly designed loading zones (e.g. the semi-rare 2-3 minute long elevator rides in Mass Effect).

You could also have levels divided up into three or four areas that you load or unload at will, and have a certain number of "zones" active at once. So, for example:

You start level 1. You have zones 1-1, 1-2, and 1-3 loaded.

You enter level 1, zone 1-3. You unload zone 1-1, and load level 2, zone 2-1.

You complete level 1 and move to level 2-1, you now load zone 2-2 and 2-3, while keeping 1-3 loaded in case the player backtracks.

If the player continues into zone 2-2, you unload all zones from level 1, as you can reload them if the player enters zone 2-1 again.​

Handling things that way, you never have to have a "transitional" area, as you're streaming in what's needed ahead of time based off of what you think the player is progressing toward.

Right. If every area is transitional, then that makes things much more seamless. But you either need a lot of subdivisions or a lot of overhead.
 

Ashodin

Member
Exactly. Ori is a world where you kinda go in various directions and there's no "seam" that you can really see, and while I can sort of imagine as a general concept how this might work, I can't imagine how one approaches this both in a technical sense and a design sense. I can't imagine, for example, (and this may be something I need to be brutally corrected on, since I don't have really any personal experience with Unity) having one 3d space to work from that spans the entire game world when you're using Unity -- It seems like it'd just be too large to be practical, so how do you join those babies together and do it seamlessly as one coherent world?

wizardry
 
Are there fake "you've been Greenlit" emails that go out? Because Steam just sent me one that said my game is Greenlit, and I see no reason for that to be the case at all...
 

Ashodin

Member
Nope, my game was greenlit despite not getting lots and lots of votes, so they're possibly getting more games with lower thresholds through the queue.
 
Right. If every area is transitional, then that makes things much more seamless. But you either need a lot of subdivisions or a lot of overhead.
Actually having less subdivisions would be better, I think, so that you don't have to do expensive loading operations too often. The balance between too many and not enough would probably be something that needed to be worked out on a per-game basis, though.

Overhead wouldn't really be a big issue if you're targeting PC and newer consoles, I'd think. Anything mobile or handheld would obviously have some memory issues, but I can't think of a game I've played that handled seamless transitions really well that was on a more memory-restricted platform.

Anyway, I'm not an expert on these things, so hopefully I'm not coming off as "my way is the best and only way!". Given the set of problems laid out, that was my best off-the-top-of-my-head guess as to how they approached it.
 

missile

Member
... You should share moire often!
Yeah! :) Well, usually, aliasing is a pretty bad thing, but I somehow like the
aliasing/moiré structures. If done right I think they can be pretty cool even
in a game. (Aliasing was also used in computer generated music.) Well, I got
some ideas for some (time-)aliasing for another game of mine. But controlling
aliasing not only requires good frequency knowledge, but also tight control of
the output sampling frequency. That means, with respect to time and display
resolution for example, of being in full control of the frame rate and output
resolution, which is a problem at times if the output device does some
interpolation (scaling etc.) on its own. For example, if you watch the picture
of mine on an iPad Air using Safari or Photos it looks a little off due to
scaling (and not being able to see a pixel-perfect/unscaled image with said
apps unless I'm missing something).
 

Ito

Member
@Jobbs @liliththepale RE: Metroidvania item/skills progression

Those were some useful tips. Thanks to both of you!

While I like a progression where you have to evolve to overcome previous obstacles, I do find it "cheap" when the items or skills you adquire are completely situational, and you find little to no alternative use for these.

Acrobatic skills are always a good way to give the player new moves that he'll be able to use in many different situations.

I have a rule that I'll always apply when I'm designing some weapon, item or skill, and it's: Make it useful in all three fields: combat, platforming, and exploration (when possible).

I also think that there're a couple of behaviours/patterns that should be avoided:

- Overuse of the door/key mechanic. It's cool to find an ancient key and wonder where you'll be able to use it later in the game, but it gets boring if you find a lot of generic locked doors (Looking at you, Zelda).

- Cool gadgets/abilities that only work in one way, or that become useless once you leave the few places you're supposed to use them.

- Restrict the use of some item/skills when you're inside someone's house. Let the player move freely always.

- Unrealistic/unnatural usage of the powers you adquire. For example, if your character is able to perform a really powerfull attack, able to destroy thin walls, he should be able to use it downwards/upwards, and destroy the floor or ceiling breakable tiles. Because that's what you would do in real life. The most common case: a game where you can break walls normally, but you have to adquire an special uppercut ability to break ceiling tiles. Just let the player attack upwards :(

- Excessive grading of a same power. It's cool to find a power up that lets you lift up heavier stuff. It's OK if there's a second power up for even heavier stuff. Anything beyond this is going to be boring probably.

- Color-coding blocks, regarding their accesibility, when that's the only visual difference between the different types of doors/blocks. I think there should be some logic behind it; if you can't destroy some block, it should be because it's made of a harder material, not just because it looks red. Therefore it should look different, or you should make the player know somehow that it's different (Metroid Prime did a good job in this, with a scan that allowed you to know the composition of the rocks surrounding you).

One thing I didn't like about Guacamelee is how some kicks break the blue tiles, then another kind of kick breaks the red tiles, and so on.
 

V_Arnold

Member
Folks, any tips on what to use for item/skill databases?

I cant decide between
- IndexedDB
- SQLite
- JSON

I plan on NOT requiring active online connection for any of my mobile versions of any future games, except if the player wants to play the online modes, of course. So an ability to have small "mirrors" of the server's data is a given. While those who test new content (beta tests, etc) would have access to the game via the online-only mode, where the server's data is queried.

Javascript+WebGL+wrappers is the current plan, obviously. Anyone having experience with these being used both online and offline? If not, I shall have some work to dig into, relatively soon - I do not want to store data within javascript classes, as that will be a nightmare to maintain very, very soon.
 
Folks, any tips on what to use for item/skill databases?

If you're going to be working on whats going to effectively be a giant indexed array, I'd suggest thinking about how its best for YOU as the designer / balancer to access it easily and make sweeping changes as necessary, rather than how best your program is going to access it in the future, especially as if you're going to be making a primarily offline application you're going to probably do a database transfer and merge at application start / quit rather than every time you need to check an entry.

I'd probably suggest using JSON with a CSV converter to and from, so you can use a spreadsheet to manipulate data 'offline' or make large changes (because doing this in an actual database is much more of a hassle).

Its potentially worth looking into some form of encryption for your clientside database too unless cheating isnt a concern
 

anteevy

Member
Folks, any tips on what to use for item/skill databases?

I cant decide between
- IndexedDB
- SQLite
- JSON

I plan on NOT requiring active online connection for any of my mobile versions of any future games, except if the player wants to play the online modes, of course. So an ability to have small "mirrors" of the server's data is a given. While those who test new content (beta tests, etc) would have access to the game via the online-only mode, where the server's data is queried.

Javascript+WebGL+wrappers is the current plan, obviously. Anyone having experience with these being used both online and offline? If not, I shall have some work to dig into, relatively soon - I do not want to store data within javascript classes, as that will be a nightmare to maintain very, very soon.
Maybe you could go an even simpler route and store the data in CSV files? Makes it easy to edit with tools like Excel, too. Depends on the complexity of the data obviously, but for my game it was sufficient (stuff like damage, speed, ...).

---

I finally uploaded a public alpha demo of ROLL PLAYING GAME to itch.io:
http://felinefuelledgames.itch.io/roll-playing-game

Would be reeeeeeeeeaaaaaaaa(...)aaaally awesome if some of you could playtest it and give feedback in my awesome feedback form: http://goo.gl/forms/9CceYoCpM9

Here is a screen of one of the larger puzzles in the game:
True%20Grid.jpg
 

V_Arnold

Member
If you're going to be working on whats going to effectively be a giant indexed array, I'd suggest thinking about how its best for YOU as the designer / balancer to access it easily and make sweeping changes as necessary, rather than how best your program is going to access it in the future, especially as if you're going to be making a primarily offline application you're going to probably do a database transfer and merge at application start / quit rather than every time you need to check an entry.

I'd probably suggest using JSON with a CSV converter to and from, so you can use a spreadsheet to manipulate data 'offline' or make large changes (because doing this in an actual database is much more of a hassle).

Its potentially worth looking into some form of encryption for your clientside database too unless cheating isnt a concern

Thanks, I shall look into it! (Anteevy: thanks for your mention of CSV too!)
Cheating is not a concern when you are doing javacript. If they want to ruin their own experience offline, they will be able to do so. And if I somehow manage to encrypt the data part, the function calls that determine the data (and that look for a damage buffer) will be easily manipulated to just request 100 percent of monster health damage or something like that. It is up to them. Online, however, the server will handle everything. Once a player is out of synch (in terms of buffs/debufs/numbers), and try to request a damage that is impossible to attain, it is a disconnect and a loss.
 

thomasmahler

Moon Studios
How does Ori And The Blind Forest put together a world this big with seemingly no barriers between areas to load into? How do you approach that?

We approached that in 2 ways. First off, from a level design perspective, I wanted to see the entire world and how it fits together, similar to the crazy huge maps that people put together for Super Metroid / Symphony of the Night, etc., where you see every single screen connected to make up for one HUUUUGE map. That's how we always saw the entire world. Whenever you updated the repository and artists put in some art or design added a level somewhere, EVERYONE would immediately see it, since you'd see how the entire world changed. Imagine how cool that is: You get to work in the morning, update your repository and boom, you see that these two levels that were blockouts before now got their full art treatment and you can immediately try it out :)

Now, obviously we didn't have every single level in the game loaded at the same time, since that would've murdered just about any workstation. Instead, we developed what we internally aptly called 'the screenshot tool'. I talked about it a bit in the official Ori thread already:

One of my favorite tools was the 'Screenshot Tool'. This was basically directly inspired by these collages people put together of Super Metroid, etc. - I mean the images where people take screenshots of every single screen and then put them together as a 'map', so you see the entire world on one screen. I wanted to have something similar to put together the world layout and getting this working made my life soooo much easier.
I was basically able to take a snapshot of a scene and just move it around however I wanted and whenever I hit play, I could already try out how the levels fit together. Most of the world was designed as blockouts and every day we saw artists updating the screenshots as they updated the rooms and more and more art got in. It was really neat to see the world grow that way and to me, that tool was absolutely magical :)

So, thanks to the screenshot tool, we now saw the entire world laid out in front of us - Every single area in the game was cut up and turned into a screenshot that you could simply doubleClick to load the entire level. On top of that, you're able to just move the screenshots around and the scenes automatically update. So I'd be able to take a scene from the Thornfelt Swamp and connect it to another scene in the Moon Grotto if I wanted to simply be dragging and dropping the screenshots around :) You're also able to load up multiple levels at once, to ensure it's all seamless and perfect. And we then 'simply' had our programmers write the streaming tech. The game tries to figure out which level is near where you are right now and loads / unloads areas accordingly.

I hope that answers your question - it's not magic, but it's a magical tool that I think is a necessity if you're making a Metroidvania'ish game, since it's obvious how insanely helpful it is to see the entire world and be able to simply rip out bits and put it somewhere else :)
 

Minamu

Member
Another indie game dev here :D Well, aspiring dev trying to make some portfolio titles for job applications. I was wondering, the OP didn't cover it, if there are any good sites out there for freeware graphics, like 8-bit sprites etc? I found opengameart but it's a bit rough to navigate. I'm currently on my third project, which other teammates, where the graphics consist of colored squares made in ms paint lol. I have a game design / level design education but it didn't have any graphics courses in it whatsoever unfortunately.
 

Jobbs

Banned
I hope that answers your question - it's not magic, but it's a magical tool that I think is a necessity if you're making a Metroidvania'ish game, since it's obvious how insanely helpful it is to see the entire world and be able to simply rip out bits and put it somewhere else :)

this was interesting to see. it partly answered my question, but also introduced new ones. XD

Speaking for myself, the game I'm doing is a bit more standard metroid, with many rooms connected by doorways. To make my map I did it "on paper" (in photoshop) on a grid where each space represents a screen. Moving screens around or editing the map for me is a painful process as all kinds of little things have to be configured and adjusted in each scene.
 

thomasmahler

Moon Studios
this was interesting to see. it partly answered my question, but also introduced new ones. XD

Speaking for myself, the game I'm doing is a bit more standard metroid, with many rooms connected by doorways. To make my map I did it "on paper" (in photoshop) on a grid where each space represents a screen. Moving screens around or editing the map for me is a painful process as all kinds of little things have to be configured and adjusted in each scene.

Yeah, I know, I worked in the same way before we got the screenshot tool and it was unmanageable. Often times you just want to try something by moving this bit here instead of there, but if it's a pain in the ass, you find yourself just not doing it, cause it's such a hassle to move the scene back and forth, etc.

Also, I played Ghost Song and the only thing that really bothered me were the screen changes. I think it'd definitely help your game if you could somehow figuring out making it completely seamless and transition nicely between the scenes. It just makes everything so much more fluid when the player isn't being stopped in his flow. Can't you have more than 1 scene loaded with Stencyl (that's what you're using, right)?
 
Instead, we developed what we internally aptly called 'the screenshot tool'.
That's actually really, really cool. Both from a level design perspective and a programming perspective, that's a really neat implementation that's kind of a natural evolution of drawing connection diagrams on paper.
 

Blizzard

Banned
- Unrealistic/unnatural usage of the powers you adquire. For example, if your character is able to perform a really powerfull attack, able to destroy thin walls, he should be able to use it downwards/upwards, and destroy the floor or ceiling breakable tiles. Because that's what you would do in real life. The most common case: a game where you can break walls normally, but you have to adquire an special uppercut ability to break ceiling tiles. Just let the player attack upwards :(
I respectfully disagree with this and was actually going to specifically mention Guacamelee as a cool example. If Guacamelee only had one strong attack that could be used down, up, or sideways, your mobility and fighting ability would have gone from tiny to huge almost instantly when you unlocked it. Plus, if they all looked the same, it would be rather boring. As it is, you gradually learn the ability to chain things like up dash -> side dash -> down dash for neat battle/combo mechanics, and/or neat traversal, and/or neat block-smashing.

I think realism is BARELY a factor when you have a superpowered luchadore fighting day-of-the-dead skeletons using a magical mask.

I similarly enjoyed the Warioland 1-3 games which used something similar. You could bull-charge blocks to hit them, but not always ground-pound without an ability. This might have helped allow horizontal exploration in certain areas, but have vertical areas that were secret until you had more abilities.

Going way back, take the classic Mario example. Even aside from whether it's realistic to double in size when you eat a mushroom, Mario was able to hit a powerup block with his head, but not generally from the side without a powerup (the cape for example). But why not? In real life, wouldn't a plumber just lie down, aim sideways, and smash a block by jumping horizontally? Maybe, but the games are still fun and there's a bit of balance because it was left out.
 

thomasmahler

Moon Studios
That's actually really, really cool. Both from a level design perspective and a programming perspective, that's a really neat implementation that's kind of a natural evolution of drawing connection diagrams on paper.

Yeah. I also started drawing the entire map in Photoshop, but that becomes unmanageable soooo quickly - and if you do it with Photoshop, you can never try out a new flow. You may THINK that you can just imagine how it'll work, but if you can't really try the flow and see what it FEELS like, it's really not the same thing.
 
Well, now is as a good time as any. I've been working on a game for roughly a couple years called Baxter's Adventure. It's developed using Construct 2 and aiming for the Steam platform.


Title screen:
BVDC09.png


I have an animated gif of a level:

BVDCgif1.gif


Originally I had the intention to make this a pixel themed platformer, but was under the impression people were sick of seeing those since they're technically a dime-a-dozen so opted for handdrawn with simplistic animations. It's just me as the sole developer and has been a very interesting experience so far.

I've considered this game easily portable for the Wii U, however I've led to the conclusion that it won't be possible unless I recreate the game from the ground up from a more stable platform like Unity.
 
So, thanks to the screenshot tool, we now saw the entire world laid out in front of us - Every single area in the game was cut up and turned into a screenshot that you could simply doubleClick to load the entire level. On top of that, you're able to just move the screenshots around and the scenes automatically update. So I'd be able to take a scene from the Thornfelt Swamp and connect it to another scene in the Moon Grotto if I wanted to simply be dragging and dropping the screenshots around :) You're also able to load up multiple levels at once, to ensure it's all seamless and perfect. And we then 'simply' had our programmers write the streaming tech. The game tries to figure out which level is near where you are right now and loads / unloads areas accordingly.

That all sounds really cool. So let me get this straight, every "screen" in your game is an individual Unity scene..? And then, when a designer is done with such a scene, they take a screenshot of it, and add that to another "scene" that acts as your screenshot map. And from this map scene, you have a script that can generate some kind of data structure based on where the screenshots intersect that tells the game which scene to load and when? Is it something like that?
 

Jobbs

Banned
Also, I played Ghost Song and the only thing that really bothered me were the screen changes. I think it'd definitely help your game if you could somehow figuring out making it completely seamless and transition nicely between the scenes. It just makes everything so much more fluid when the player isn't being stopped in his flow. Can't you have more than 1 scene loaded with Stencyl (that's what you're using, right)?

I don't know what version of the beta you played (and the beta is already fairly dated compared to in development), but the door transition stuff was one of the hardest for me to figure out and has been tweaked many times. (Incidentally, initially it was pretty buggy and people kept getting stuck)

To the extent that there's a few seconds transition between scenes, this isn't usually actually necessary, but was placed there for consistency. Early on there was no fade or any kind of transition, and many scene switches would be near instant, but accompanied by a stutter/freeze of varying lengths (depending on the scene and what's in it) as the assets loaded in. I introduced the fade to even things out and prevent this stutter from being seen.

As to your question, I don't know if that's possible. Stencyl is limited in some ways, but the silver lining is there's a certain security in having boundaries, identifying what you can and can't do, and doing your best within that space. I don't know if I'd do another large project with Stencyl, but I'm glad it exists. It introduced me to programming concepts, some of which I'm becoming almost fluent in (and others which remain a mystery) and enabled me to actually make what I feel is a good game almost completely on my own -- A feat I never would have thought possible.
 
Keeping my fingers crossed for "companion" as the theme, since that's the only one I have a decent idea for at the moment.

I forget what I voted. I prefer not to do any early brainstorming or I'll fixate on making an idea fit whatever theme happens. Though, it's sort of a guarantee that whatever I make will be a pretty conventional action game, because they're pretty easy to do on a time budget and because I like old 2D games.
 

Blizzard

Banned
"An Unconventional Weapon" is the winner for Ludum Dare 32! That was one of my favorites so I'm pretty happy. Good luck everyone!
 

Burt

Member
Well, now is as a good time as any. I've been working on a game for roughly a couple years called Baxter's Adventure. It's developed using Construct 2 and aiming for the Steam platform.


Title screen:
BVDC09.png


I have an animated gif of a level:

BVDCgif1.gif


Originally I had the intention to make this a pixel themed platformer, but was under the impression people were sick of seeing those since they're technically a dime-a-dozen so opted for handdrawn with simplistic animations. It's just me as the sole developer and has been a very interesting experience so far.

I've considered this game easily portable for the Wii U, however I've led to the conclusion that it won't be possible unless I recreate the game from the ground up from a more stable platform like Unity.
Looks good! What do you think is keeping you from porting the game with Construct 2? I know there are some people in this thread that've used C2 to get games on Wii U, so maybe they could offer some advice.
 
Exactly. Ori is a world where you kinda go in various directions and there's no "seam" that you can really see, and while I can sort of imagine as a general concept how this might work, I can't imagine how one approaches this both in a technical sense and a design sense. I can't imagine, for example, (and this may be something I need to be brutally corrected on, since I don't have really any personal experience with Unity) having one 3d space to work from that spans the entire game world when you're using Unity -- It seems like it'd just be too large to be practical, so how do you join those babies together and do it seamlessly as one coherent world?

I remember way the eff back in college talking to David Jaffe about designing and building a streaming world (mind you GoW1 was linear but it still accomplished this) and asking him if they borrowed tech from Shadow of the Colossus (which was another game on PS2 that accomplished streaming and was open world). Those two games were so ridiculous from a tech stand point for their era.

I worked on two games on PSP that approached similar problems in different ways. One game was a linear action RPG that was designed for Wii and we were handling the PSP port. There was no direction on level stuff other than "fit it into memory" so we had artists who would check the memory hit (object count, geometry count etc) of a level and then just put an exit in a spot and cut a level in half or a quarter or whatever. Of course this was a low budget port so it was all slip shot.

The other game was an open world GTA style game and basically it loaded up whatever zone you started in and neighboring zones around you, then as you moved in a direction if you crossed so far into another zone it would start loading and unloading other stuff (or something like that, I didn't work on this part of the game).

I actually remember a software engineer technical design question about this at a pretty major studio. It was a fun problem to work through.
 
Status
Not open for further replies.
Top Bottom