next »

[Adam_]

Added a simple AI to those space mines. As soon as the player is near and they have a direct line of sight, they will wake up...



...and start to follow the nearest player. They retract their spikes while flying so they aren't triggered when crashing into something on the way or being shot at.



When approaching their target, they will activate their spikes again right before impact.



If they can't see any target for a certain time, they will go to sleep.



Gameplay-wise they will probably be almost invincible, so the best way to get those space mines out of the way will be to trigger them by making sure they crash into something with their spikes exposed.

On a slightly different note, does anyone have thoughts on the style of my recent update postings? While I like the idea of illustrating progress with animated gifs, I'm not sure whether this is actually the best way to share it, especially regarding page load times and user traffic. But on the other hand, uploading a youtube-video would be "too much" for these tiny bits, and simply posting static pictures doesn't really present the subject as nicely... any thoughts?

[Adam_]

Time for a short break with all those example game updates. There's a new Duality release / update available using a fresh binary download or the Duality package manager!

I have submitted an entire new set of NuGet packages that is on par with the current master branch. This means, the new cloning system is now live in the binary release as well as all those little tweaks and fixed that have sneaked in while developing it. There also has been a lot of tweaking in the physics system that now actually pays attention to not messing up unit conversions throughout its API.

Since the new binaries are out there now, I was finally able to release the new and shiny sample packages for the DynamicLighting and Steering plugins: You can now install them using the Duality package manager and will receive some new folders containing usage examples. Here's a sneak peek of what you get:

Tweaking ambient / directional lighting and moving around a point light:



Basic steering behavior and aggressiveness settings:



Both packages have been available before, but since there was no sample content I can imagine that it was virtually impossible to get into it without pouring a lot of work into understanding each of those plugins. The new sample packages aim to improve this by providing a simple test setup that runs "out of the box" and can be used as a sandbox for playing around with the new functionality.

The cool thing about Duality is that anyone can write Plugins for both the editor and the core. For these two, I happen to be the developer and publisher, but it's certainly not a requirement. Everyone can extend Duality without altering or even knowing its source code. And thanks to the new package management system, everyone can publish those packages on the same platform that I publish mine. Still waiting for some neat "third party" plugins out there

[jamesprimate]

this is mega impressive stuff. seems so usable already! the minimalist example you did a few updates back was QUITE NICE

[Adam_]

this is mega impressive stuff. seems so usable already! the minimalist example you did a few updates back was QUITE NICE

Thanks! Duality still has some rough edges, but I think it's pretty usable overall. The only thing that's missing is a bigger community embracing it. Some brave souls are already venturing in the two-dimensional realms of this engine, but pioneers alone are not enough to provide a safe network of developers to stop you from running into walls and motivate you to exceed all expectations.

Maybe it would help if Duality was on the official tools list of some game jams. Does anyone know someone I could talk to regarding this? Does anyone of you maybe even happen to be the host of a game jam? It would be awesome if Duality could be a part of that.

[Adam_]

Worked on a quick and dirty ParticleEffect Component that will be used for mine explosions when it's fully operational.



It may not look like much in the first image, but those particles are actually parallax objects with 3D movement like all the others. They can blast around in all three dimensions.



For small amounts of particles like that, I could also have simply used some sprite objects with a custom Component to scatter them around - but it's also a great opportunity to provide an example on how to implement custom Renderer Components, so I've done that instead.

[Adam_]

Added an actual explosion effect for the Claymore enemy. Minimalistic as usual.



A single hit will probably kill the player ship, but it doesn't yet. They also emit a slight physical shockwave that pushes away other objects.



Those shockwaves aren't realistic by any means, but at least they're doing a raycast in order to determine which objects will be actually hit.



So far I'm okay with those explosions, but the camera definitely needs a shake animation when hit by them. :D

[Adam_]

Worked mostly on gameplay logic. Ships now have a hitpoints counter, self-heal, get damaged and die. Claymore mines blow up when damaged too much.



Also, player ships disassemble into small debris when being killed.



Nothing spectacular, but it's progress. I also decided to cut down the scope of the example project, because it's educational use would be lost if it grew too massive to be understood quickly. No main menu, no highscore screen stuff and only a single but playable level: I'll try to get this project as small and packed as possible.

[Adam_]

Added screen shake effects:


Also did a lot on respawning, HUD and gameplay logic:


When a player dies, he will automatically respawn, if the other player manages to survive X more seconds. Also, there's now a health bar for each player and no more annoying debug prints on screen to see each objects health.

[Flatgub]

This is looking incredible!
This is definitely something I may pick up and try in the future!
Very Promising looking!

[Adam_]

This is looking incredible!
This is definitely something I may pick up and try in the future!
Very Promising looking!

Thanks! Tell me what you think once you get around to use it. Feedback is always appreciated.


By the way, here's a high-res version of the above .gif animation.

[Adam_]

Added a GameOver screen with a neat mosaic blend animation to fade it in.


> Highres Version <

[Adam_]

Toying around with a level goal design. I don't really want to write "goal" on it though. Happiness will do.


> Highres Version <

[Adam_]

Implemented some more helper classes so it is now actually possible to win. If two players are in the game, both need to make it into the goal - if one makes it and the other one dies before reaching it, the game will be lost. Teamwork wins!

Also, I felt like adding some more mood to it.

Losing the game:

> Highres Version <

Winning the game:

> Highres Version <

[Adam_]

I'll be in the persistent TIGSource Google Hangout, finding out whether I manage to get stuff done.

http://forums.tigsource.com/index.php?topic=36140.msg1071169#new

Feel free to join me.

[Adam_]

I'm a little stuck right now regarding the Example Project. It's probably not that hard to proceed - I'm just not quite sure how exactly. What needs to be done at this point is pretty straight forward:

• Design the only level
• Add sound
• Polishing
• Allow Duality Packages to contain source code
• Publish it

I even came up with a simple, very rough idea on how that level might look like:



Essentially, there are eight separate chambers, connected through pathways that are blocked by a door. What needs to be done to open that door depends on the room the player is in: The initial ones will slide open automatically, the ones later will require to enter a certain trigger area or push an object into that area. There are two "tutorial" rooms without any action just to show how it works. The following rooms will have the Claymore space mine as a challenge in increasing numbers and aggressiveness, along with variants of the simple door opening task. So far so good.

The problem a bit more technical: How do I actually construct the level geometry? Using the existing toolset of Duality, I can think of a few ways:

• Use RigidBody / RigidBodyRenderer objects to model every part of the level and rely on the renderer to display a solid area that matches the collision shape exactly.
  
  Pro:
  
  • Can be done using existing stuff 100% in the editor.
  • Minimalistic.
  Con:
  
  • Only convex shapes are allowed, because the RigidBodyRenderer isn't prepared to display non-convex polygons. Decomposition algorithms will be required..
  • The world will look a bit rough due to the hard polygon edges.
  
  
• Use invisible RigidBody objects to model the level collision shape and use SpriteRenderers to model the visible part of it.
  
  Pro:
  
  • Can be done using existing stuff 100% in the editor.
  • A lot of freedom designing the level geometry.
  Con:
  
  • Requires a lot of content and bloats the example project.
  • Requires a lot of resources in form of unique textures - more than the minimalistic style actually needs, and there is no need to be wasteful like that.
  
  
• Write a custom Renderer for that game which displays a "2D mesh" and model collision areas separately using RigidBodies.
  
  Pro:
  
  • Arbitrary 2D meshes don't use much resources, don't bloat the project and are quite reusable.
  • A lot of freedom designing the level geometry.
  Con:
  
  • There is no existing toolchain I can use to create or import those arbitrary 2D meshes and providing one just for this one project is possible, but would be more overhead than I was hoping for. I also have no idea on what tools to use for this.

So there's that. I'm also thinking about ditching the idea of having round, organic level geometry and just using geometric primitives I can easily stack together in the Duality editor with nearly zero effort and without implementing anything more. The visual quality might be a little lower, but it could also serve the minimalism style quite well.. not sure about that though. Any thoughts?

[Adam_]

On a lightly different note, it's amazing what good developing an example project can do to a framework like Duality. I started this a little over a month ago and when I compile a framework-only change log since then, this is what pops up:

(Older changes first)

Code:

#FIX: Fixed launcher path not working when running Duality with a different working directory than the default one.
#FIX: Fixed "Create Object" dialog not showing ancestor Types.
#FIX: Fixed crash in launcher when launching with a different working directory.
#CHANGE: RigidBody now uses a Duality-local CollisionCategory enum instead of one from Farseer physics, so a reference to the project is no longer required for simple RigidBody API usage.
#CHANGE: Formatter classes are now able to convert different enum types and numeric primitives to enums.
#FIX: Fixed ContentRef docs.
#FIX: Fixed RigidBody sometimes causing accidental rotational forces in ApplyForce due to minor inaccuracies.
#CHANGE: Updated Farseer Physics package.
#CHANGE: ScreenMode.Native is now an actual fullscreen mode while the new ScreenMode.FullWindow is a borderless window covering the whole screen.
#CHANGE: RigidBodyRenderer is no longer considered a pure diagnostics / debugging Component.
#CHANGE: Replaced poor physics unit conversion handling with a much better interface.
#FIX: Fixed some physics unit issues. Users can now actually calculate with physical units without applying additional conversion factors.
#FIX: Fixed Joint layer in Cam View to display appropriate force visualizations.
#FIX: Fixed AnimSpriteRenderer not clamping FixedSingle and RandomSingle AnimTimes.
#ADD: Added an application manifest file to explicitly state that Dualitor is NOT DPI-aware and thus needs to use Windows DPI virtualization.
#ADD: Added optional icon offsets to FormattedText rendering.
#FIX: Fixed Font metrics calculation being off by 1-2 pixels in some cases.
#FIX: Fixed FormattedText metrics not handling cases where icons are bigger than text.
#CHANGE: Canvas.DrawText now behaves a little more intuitive in its text block alignment settings.
#ADD: DualityUpdater is now able to delete empty directories after removing files from them.
#CHANGE: Changed how background rendering behaves in Canvas.DrawText with FormattedText.
#FIX: Fixed RawList.RemoveAt and RawList.RemoveRange duplicating existing entries.
#FIX: Fixed Range object not being flagged [Serializable]
#FIX: Fixed cursor image flickering when using the PropertyGrid on Windows 8.
#CHANGE: Updated AdamsLair.WinForms package reference.
#ADD: Added extension methods for Random to generate colors.
#FIX: PropertyGrid no longer gets stuck with the beam cursor when leaving certain PropertyEditors in the "wrong" way.
#ADD: Added exception guards to prevent the editor from entering an inconsistent state due to core errors.

With few exceptions (thanks everyone who reports issues! ), most of these changes are an indirect or direct result of having the example project around. They are the kind of things that you don't notice when testing your new or improved feature, but pop up only when excessively using it in an actual workflow. Looking back now, I can't believe that all those things were once actual or potential issues. If documentation wasn't already a great reason to do an example project like this, the changelog above certainly is. It's also the reason why you should never develop an engine without having a game there to use it.

[Adam_]

This may not be directly development-related, but here's a recommendation on (mostly) calm background music:

> Max Richter Online Radio <

It sometimes works as a programming background, but when it doesn't, it's still great for doing art and levels. Also nice for moody evenings in general. Did I mention that you'll stumble across the awesome Clint Mansell soundtrack of The Fountain as well? Anyway, maybe some of you like or have a use for it

[Adam_]

Sorry for the long delay on this devlog. Turns out, I'm just terrible at level design. That's why this is taking so long: I finally get myself to build some level stuff, it sucks, I get distracted by fancy technical stuff, repeat. But I'll be getting there. Eventually.

Any suggestions for leveldesign-specific motivation management?

[Adam_]

So I finally got around to do some more level design and ended up shaping out the entire single example level. Or at least to create the first iteration of it, yet without actual collision shapes defined, untested, undecorated and unpolished.

(

you can listen to while looking at the world map to add some mood.)

It doesn't look much like the original draft, but I'm kind of happy with the result. Due to the minimalistic art style, it was possible to create the whole level out of the same five shapes, only by scaling, rotating, moving and overlapping them. The automatically batched rendering pipeline will probably love me for this, but hate me for all the overdraw. Anyway - performance is hardly a concern for a small game like this.

[Adam_]

Added physical collision geometry.