Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1025333 Posts in 41084 Topics- by 32684 Members - Latest Member: ActualiseDesign

July 21, 2014, 11:19:40 PM
TIGSource ForumsFeedbackDevLogsDDrop - 2D Action RPG
Pages: 1 [2] 3 4
Print
Author Topic: DDrop - 2D Action RPG  (Read 13038 times)
randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #15 on: October 17, 2012, 10:18:29 PM »

This game will be excellent, guys, mark my words!

Thanks Mr. Sanders! Hope you've been well since PAX :D

This game looks very promising, I'll keep an eye on this.

ps. The fullsize screenshots are either down or the links are broken.

Thank you. Hmm...the screenshot links are all working for me atm. Not sure what might have happened earlier, sorry 'bout that.

The last couple of weeks have been pretty hectic. We showed the game at a local exhibition a couple weekends ago. It was quite different than PAX (not only in scale) but was another nice (and cheap) opportunity to get some first hand feedback.

I also sort of forgot about the IGF submission deadline, so literally just wrapped that up. As the game is heavily work-in-progress right now and we're constantly breaking/adding/fixing things, I had to submit a glorified version of the PAX build. We'll be updating it frequently but with the game in such an early state I doubt we'll get any traction with the judges.

Also sort of realized that if I don't hurry up and finish the "catching up" posts I'll never be able to actually catch up. The resolution/asset info is all written now so I just need to grab some appropriate screenshots; should be able to post that tomorrow.

Since all of the above is not interesting in the slightest, here's a pic of the game running on an iPhone :D



Edit: Checking the screenshot links again from the first post, Screenshot #3 was broken. Fixed now, thanks for the heads up!
« Last Edit: October 17, 2012, 10:38:21 PM by randomshade » Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #16 on: November 16, 2012, 02:17:42 PM »

Well, that was quite the gap in updating! The last few weeks have seen a lot of rapid changes to the game so it's been super busy. We've changed the wall system and a few other things for visual purposes and I'll be writing about that stuff soon I hope. For now, back to where I left off: resolutions.

The plan from the get go was to have DD on as wide a variety of platforms as we could manage, which put a lot of pressure on how to handle resolutions elegantly from the very small 480x320 to the very large 2560x1600. Apart from that, I wanted us to support any possible resolution between there and adhere to the following rules:

1: Never scale up
2: Uniform scaling (i.e. no stretching)
3: Never letterbox
4: Minimize the need to scale down as much as possible

We also had the problem of dealing with widely varying device capabilities: VRAM/GPU/CPU are significantly different between phones/tablets/low end PCs/high end PCs. Effectively, we decided the path of least resistance was to use 2 sets of assets. Our "SD" assets are used on all devices with resolutions less than or equal to our game's standard virtual resolution. HD assets are used for anything above that. The only assets which are duplicated are images: we use the same texture/anim/scene files and simply scale up coordinates/positions in HD mode. At run time, when an image is loaded there is a simple check if we are using HD assets and "_hd" is appended to the file name to load the correct texture. Fairly simple but extremely important.

Back to resolutions! The core idea of our resolution system is that instead of letter boxing, we crop *into* game space and if scaling is required, scale down after cropping in such a way that scaling occurs in the same aspect ratio. Cropping into the game space is effectively the reverse of letter boxing and generates a "title safe" region not so unlike what you deal with on consoles and TVs. Here is an image I generated by taking screenshots at 1280x800, 1280x720, 1204x768, and 960x640 and then overlaid each screenshot at 50% opacity on each other. This is the best way to convey the cropping into game space concept.



Effectively, the system needs 3 parameters:
1: default virtual resolution (1280x800 for us -- used with the HD system this means our highest natively supported resolution is 2560x1600.)
2: maximum crop values (320x200)
3: minimum supported resolution (480x320)

So for any resolution between 1280x800 and 960x600 (or in HD mode 2560x1600 and 1920x1200) we can simply crop into game space and do not require any scaling. Yay, fun.

So we've got HD resolutions/images covered and support a goodly range of resolutions natively, the remaining piece is simply scaling down. Scaling down is pretty simple and lots of games already do this. For us, the only extra consideration is that we want to crop down and then scale, and to do the cropping such that scaling is uniform. This would give the end result that, for example, on an iPhone 3GS (480x320) you would see the exact same gamespace as an iPhone 4 (960 x 640). And with that, we literally support any resolution between 480x320 and 2560x1600 with 1:1 pixel mapping in as many cases as is possible and no letter boxing. Here is a montage of various random resolutions. (Note these are all SD resolutions since the result is exactly the same in HD space but without need a gigantic image.)



Also, here's a screenshot at 2560x1600 for fun.

I actually took all of these screenshots last month, so not a lot of new stuff in them, so sorry for any disappointment there :D

There is one....last little piece to the puzzle. Since we are cropping into game space, that poses a problem for any screen space oriented objects, namely UI. Much like how many 3D games handle UI, we just use a flexible positioning system, where you assign a UI element one of 9 anchor points on the screen and then set its position relative to that anchor (either absolutely relative or screen-size relative.) Fairly simple and nice results.
« Last Edit: November 16, 2012, 11:20:06 PM by randomshade » Logged

Windybeard
Level 3
***



View Profile Email
« Reply #17 on: November 16, 2012, 04:18:17 PM »

THIS LOOKS INCREDIBLE!!!!!  Hand Money Right Hand Money Right Hand Money Right
Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #18 on: December 02, 2012, 01:57:05 AM »

THIS LOOKS INCREDIBLE!!!!!  Hand Money Right Hand Money Right Hand Money Right

Thank you sir!

I've decided to deviate from the original devlog plan a bit (since I'm such a terrible poster anyway) and mention some [relatively] newer things we've been working on. The first, was a complete overhaul to how the wall system works. The previous system seen in the video in the first post used a series of parallaxed (and scaled and offset) layers to achieve a very-faux 3D effect. Lots of folks who played the PAX demo or have seen the videos have liked the system a lot, and generally we have too. But oh, the problems.

Some of the issues are minor to medium in terms of complexity with regards to fixing them: getting normal sprites/animated sprites that are attached to the walls or embedded in them (like doors) to look right, issues with how to handle the corners, problematic inner walls, etc. However, the single biggest factor that more or less forced our hand, was that painting the tiles used for the walls became very difficult once we started on new tile sets and environment types. Effectively, the style used in the previous video was the only style we would be able to create the walls in without encountering some visual ugliness ranging from obvious discontinuity to really bad "stair stepping" effects. Limiting ourselves to the rectangular, weakly varied brick tiles would really hurt the overall variety and aesthetic quality (especially in some of the planned environments) so we decided to scrap it and do something better.

Fortunately, our lead artist knew immediately what he wanted. The solution was again a series of layers, but this time with 3D vertical spans and ortho caps/dividers. The idea is to get closer to real 3D in terms of alleviating issues from the previous system and keeping things very smooth, but still having a bit of a 2D feeling. This gave the artists much more range of freedom in designing the various walls, alleviated basically all of the issues from the first system, and added some gray hair to my beard.

Here is a video showing what it looks like now (with prototype assets.) You'll notice that I didn't have the corner pieces in, which are actually two piece vertical column type things. The idea, I think, is still pretty clear.



You'll also notice in the video another fairly recent development which is support for Tiled. Up to this point we've mostly been using tools that we've developed internally (some more dubious than others) but ultimately, I was spending too much time on them and related fixes. Apart from that, it's really important to me that our tools all run on Mac and PC (and Linux some day) and that any external tools we use be free. Mostly this is because I want to support modding of all of our games to the maximum degree.

In the video you'll see that we support the tile mapping (the floors for our rooms; walls are procedurally generated) and object creation features of Tiled. I also hooked up the ambient lighting to be modified via "map properties." As it is, I'm pretty pleased. The biggest downside is that Tiled is not a WYSIWYG editor from the objects side of things, but I think we can live with that for all of the upsides. It was also sort of annoying on the implementation side; not difficult, just some of Tiled's limitations were ugly to work around (example: not supporting properties in the object type's database.)

To wrap it all up: soon, we'll have the game's official (non-placeholder...) website up and running with lots of good stuff. The first real gameplay trailer is also coming together at which point I hope to spend a few days and write here about a lot of the stuff we've done the last couple of months.
« Last Edit: December 24, 2012, 10:09:41 AM by randomshade » Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #19 on: December 24, 2012, 10:14:06 AM »

Short list of updates!
-Website: 90%
-Gameplay Trailer: 70%
-Inventory system: done
-New particle/emission system: done
-Switch from pure 2D (logic, not visuals) to 3D: done
-Dynamic shadows: 50% -- works, but has some artifacts/inconsistencies
-More interesting enemy behaviors: done

I plan on writing up some stuff about the last things above once we get the site/trailer up; the real purpose of this post though, is to share a little holiday image our artist whipped up :D Happy Holidays/Merry Christmas/Feliz Navidad/etc.


« Last Edit: December 24, 2012, 10:21:16 AM by randomshade » Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #20 on: December 31, 2012, 11:18:22 AM »

For some strange reason (*cough* the wife's wishes) we decided to move over the holidays, which when coupled with the holidays has meant not a whole lot of progress the last couple of weeks. With some luck, we'll get internet at our new place this Thursday and then hopefully sanity ensues...

Last week I did get started on the implementation for traps. A lot of the annoying leg work is done, and now I just need to flesh out the various types and triggers. The simplest to implement was a projectile trap. It is exactly as it sounds: when triggered, it fires off some kind of projectile, be it a fireball, arrow, poison gas cloud, or whatever. In many ways, projectile traps are just a special case of emitter so it was only a couple of hours of work to get something basic up and running.

Of slightly more importance, I *finally* tracked down an awful performance bug that was murdering the CPU. I was convinced that there was something vile going on in the physics system, which turned out to be totally incorrect (although the physics system was a prime manifestation of the issue.) It actually turned out to be some simple evil of leaving in debug code where it shouldn't be and that debug code being horrendously broken anyway. (Performing dynamic string copies on *every* single random element access = very, very bad.)  The net result of that fix was instead of blitzing the CPU during physics solving with only 40-50 on screen entities, we can now solve for many hundreds/low thousands of closely situated objects. Since basically everything in the game is physically interactive (character, enemies, projectiles, objects, debris, coins, items) squashing this bug will finally let me sleep better at night.

And in celebration of axing that bug, I present a short video with a lot of fireball spewing  altars and a lot of goblins. Just a bit of fun :D



At some point, I want to write about our data system (short story: xml based that have a high level of readability/correspondence to game object hierarchy and support for [nested] templates) but that post will take forever. So in the meantime, here's a look at the data which drives the basic fireball trap shown in the video.

Fireball Trap
This "trap" just shoots out fireballs in any random direction on a timer, versus being triggered by some event.
Code:
<FireBallTrap_A name="fireball_trap_A">
<Emitter >
<Nexus type="point" offsetx="0" offsety="0" size="0.0" slope="0.0"/>
<Pattern type="arc" dir="0" minangle="0.0" maxangle="360.0" minmag="200.0" maxmag="250.0"/>
<Burst emitonload="1" numbursts="-1" minemittables="1" maxemittables="1" bursttimer="3.00"/>
<Emissable class="interactive" database="Object" entry="Fireball" quantity="3" />
</Emitter>
</FireBallTrap_A>

Fireball Object
Code:
<Fireball name="fireball">
<Template database="Object" entry="HasBlobShadow" />
<SceneNode posz="32" />
<Renderable debugdraw="5" />
<Sprite file="art/effects/particles/fireball.xml" />
<Dynamic mass="10.0" cod="0.0" cor="1.0" gravity="0" rotatetoheading="1"/>
<Collidable type="9" height="28" prop="3">
<Reaction objtype="4" action="10"/>
<Reaction objtype="5" action="10"/>
<Reaction objtype="6" action="10"/>
<Reaction objtype="7" action="10"/>
<Reaction objtype="10" action="8"/>
</Collidable>
<Interactive maxhp="4" passive_dmg="4" />
<Entity> <Body iscircle="1" radius="15.0"> <Vert x="0" y="0.0" /> </Body> </Entity>
<Node class="emitter">
<SceneNode name="em_destruct"/>
<Template database="Emitter" entry="BloodSpray"/>
</Node>
</Fireball>
Logged

JctWood
Level 1
*


programmer/jammer


View Profile WWW Email
« Reply #21 on: December 31, 2012, 02:18:00 PM »

This looks very nice, I'll keep an Blink out for further updates
Would love to see a simple diagrammatic explanation of touch controls.
Logged

@jctwood  |  programmer/jammer  |  jctwood.uk
SolarLune
Level 10
*****


Hmm.


View Profile WWW Email
« Reply #22 on: January 01, 2013, 09:25:47 AM »

Game looks solid, and the 3D effect is really cool. Very nice art, as well.
Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #23 on: January 01, 2013, 01:11:56 PM »

This looks very nice, I'll keep an Blink out for further updates
Would love to see a simple diagrammatic explanation of touch controls.

Thank you! I don't have a diagram or anything for the touch controls, and they are actually far from finalized right now. How it currently works though is as following: Touching anywhere on the left half of the screen will 'center a virtual joystick' at that position. Then you can slide your finger in any direction to get the character to move. The threshold is quite small so you don't have to move your thumb much at all. This was heavily inspired by how Mage Gauntlet handles their hidden virtual dpad. Further, if you do slide your finger a lot, once you stop moving your finger, it will recenter the joystick slightly offset from the current touch pos back along the direction you were sliding, so the threshold to change directions is again quite small.

The current iOS build, which is 2-3 months old, just has tapping on any part of the right half of the screen as attacking. Since then we've added inventory item usage which requires a button and thus the attacking will have to be modified a lot. I may try and update the iOS build soon and take a short video which shows how this works, although the "feel" is what's obviously important. As it is right now, I'd say the controls are not obvious, but once you are aware of them, fairly intuitive.

Game looks solid, and the 3D effect is really cool. Very nice art, as well.

Thanks very much! I'm glad you like the 3D walls - we've not gotten any feedback on that since changing them as this is the only place it's ever been seen. I will pass along your compliments on the art as well :D

Sort of jumping back to iOS for a second; we're actually heavily leaning towards splitting the release of the game into PC/Mac as the lead/launch SKUs and releasing iOS/Android later. There are a lot of reasons for this: (1) we are a small team and 4, largely different, platforms is very time consuming. (2) the mobile versions will need extra love with the controls as well as a lot of heavy duty optimization. (3) the markets/audiences between desktop and mobile are vastly different and the actual structure of the desktop and mobile versions may end up being quite different.
Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #24 on: January 07, 2013, 02:54:21 AM »

It lives

Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #25 on: January 11, 2013, 10:45:09 PM »

This past week was sort of lost, sadly. Besides needing to get a flash adver-game contract I'm doing to Alpha, I was also sick a couple of days. I still managed to get a new feature into the game though, which is pretty fun: explosions!



Right now the explosions are just a physical effect; no fancy visuals to accompany them, but that's coming down the pipe soon.

Up to this point, we've basically been building up this sandbox of features and systems. It's now pretty easy to add content and build rooms and what not, and there are a lot fun things to tinker with. So, it's time to actually make the *game*; we need game flow, add in narrative, design and build actual rooms, etc. It's pretty exciting but also kind of terrifying realizing how much work is left. A good kind of terrifying, mind you, but still sobering.

Pretty soon, all of the placeholder graphics and rooms are going to be replaced with actual final quality stuff and I hope that it turns out as awesome as it is in my head. I guess we'll see :D
« Last Edit: January 11, 2013, 11:05:27 PM by randomshade » Logged

Hipshot
Level 1
*


GOTTA GO FAST!


View Profile
« Reply #26 on: January 11, 2013, 11:37:40 PM »

Your wall parallax looks really good! However, it strengthens that some things in the game are of a different perspective, like the TNT-crates in the video.
« Last Edit: January 12, 2013, 03:52:38 AM by Hipshot » Logged

Seiseki
Level 4
****



View Profile WWW
« Reply #27 on: January 12, 2013, 02:04:29 PM »

Incredible indeed!
Are you still aiming to release on OUYA?
Can't wait to try this out :D
Logged

randomshade
Level 1
*


Fastzelda


View Profile WWW Email
« Reply #28 on: January 16, 2013, 01:06:06 PM »

Incredible indeed!
Are you still aiming to release on OUYA?
Can't wait to try this out :D
Thanks Smiley
Yep, we are still planning on releasing for OUYA. We didn't back the KS and don't have dev kits, and the Android version of our engine is very incomplete, but there are basically no real reasons for us to not support it. The game plays best on a TV w/ controllers IMO anyway, so it's a fairly natural fit.

Your wall parallax looks really good! However, it strengthens that some things in the game are of a different perspective, like the TNT-crates in the video.

Indeed, the perspective is a challenging problem. (And thank you!) Obviously, it's not possible for us to make it 100% accurate but we'd still like to get something that looks as natural as possible, or at least distracts as little as possible. Whether we can make the un-realism as subtle as games like a LttP, I don't know. But we're going to try!

To that end, I've modified the perspective to be more "drawn down" such that the south faces of the 3D rendered things are always visible. But by doing this, the lower wall can completely cover/obscure the player and other objects. A cheap and quick solution to that was fading out the bottom wall as you approach it. Here's a video to demonstrate. I'd love to hear your thoughts on whether or not this an improvement!



Also, dynamic shadows are looking a lot better. I added in some random animation to them to go along with the flickering of the lights.
Logged

NeonMusashi
Manbaby
*



View Profile
« Reply #29 on: January 16, 2013, 02:06:39 PM »

This is looking really good!

I think it's working with the transparency, but I was wondering it would be possible to lock the camera movement a certain distance from the walls and to block the perspective shift from that point. You could get the same "slanted wall effect" for the bottom wall, and manage to keep your Zelda dungeon wall effect consistent across all of the walls.
I don't know if that's making any sense to you  Smiley

Btw, your post on resolution/texture management/porting was brilliant!

Looking forward to see more of your game, thanks for sharing!
Logged
Pages: 1 [2] 3 4
Print
Jump to:  

Theme orange-lt created by panic