GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Sparse Page Previous  1, 2
View previous topic :: View next topic  
Author Message
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Sun May 10, 2015 7:46 pm    Post subject: Reply with quote

There's a list in the release thread. I may not have listed Esc to return to the title screen.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Sat Jul 25, 2015 8:09 am    Post subject: Reply with quote

After a month of not getting a lot done, and a month of working on other things, I've gotten back to Sparse, fixing some old stuff and adding some new stuff. I'll write a more detailed changelog for the release thread, but for now: linux support and explosions.

New screenshots showing the latter are on my screenshot thread.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Sat Jul 25, 2015 9:08 am    Post subject: Reply with quote

Here it is. A big release with some new stuff to try. You can get it on my website.



Release notes:

- Items and Blocks can be extended to handle events and store data. This release mainly focuses on items, the next will focus on blocks.

- Tools have been revamped as item extensions. There are small changes to functionality and appearance, but nothing massive.

- The Laser now has a "ready" state when it's pointing at a minable block. It is also more accurate when destroying nonsolid blocks.

- The Manipulator has been renamed "Mover" and can move blocks anywhere within it's radius, rather than along an arc as was the previous functionality. In addition, it tries to rotate entities it picks up back to 0 degrees, making it easier to pick up and move piles of things.

- The Builder (rather than metalcrafter) has a different color.

- The first weapon has been added: the Launcher. It launches grenades, making use of the newly added explosion effect. I forgot to expose its configuration to json, so that'll be in the next release.

- Changed the behavior of held items: because tools are now items, items can define a custom arm to use when equipped, and because the player can hold things other than tools, a default arm was added that can hold the icon of the item in its hand.

- A simple lighting system was added. Light comes from the layer between the foreground blocks and the background, so anything that is transparent in the foreground lets light through. It then averages the light areas and dark areas. In a later update, I'll add a more useful lighting mechanism, where things are illuminated from above or from blocks/entities/effects, but, without any easily-added light sources already in the game, I decided to leave it as-is for the time being.

- Fixed the bug that was preventing me from porting to Mono. We now have a Linux release. Currently no Mac version, since I'm not entirely sure how to get SDL and its dependencies working on OSX; so far interrogating .library files hasn't been completely successful. If someone can supply me with the .dylib equivalents for the .dlls that ship with Sparse, I can probably get something working.

- The main menu now features a list of controls. On windows it shows the carriage returns, so I'll fix that for next release.

- The size of the sector select indicator was doubled, to make it more noticeable.

- Tweaked movement physics to make explosions satisfying to watch

- Changed (mostly raised) the levels of sound effects You might want to test the game at a low volume, just in case. I'm either using SDL_Mixer wrong, or there's a bug with the auto-select channels, so sound can get somewhat glitchy if too much stuff is going on. Pretend you're being so awesome the world is glitching out around you / you lost your hearing.

- Known Bug: tools might not work right if you pick them up out of the equipped slot and put them down somewhere else. This is because, when you pick a tool up, it doesn't trigger an equip/dequip event for it, which is how the player handles items. In the next release, opening you inventory will pause the game, so this will be fixed.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Thu Aug 06, 2015 12:49 am    Post subject: Reply with quote

I promise I'll write up a real development log soon, but until then I've finished a new release



Alpha 0.0.4 release notes:

A bunch of fixes:

- Improved the playback of sound effects
- Lots of tweaks to particle effects
- Performance tweaks. The biggest one is entities that represent items will now combine if there are too many items in a sector.
- Explosions calculate force correctly.
- A lot of info is now cleanly exposed to json.
- Changed the default UI font to DejaVu Sans.

Some new features

- A new player menu. This combines the floating inventory and sector select menu of previous versions into a tabbed interface.
- The sector select menu has been changed to reflect future plans that will limit travel: the player can only travel two squares. Later, this will reflect the distance the player is able to travel with constraints on oxygen and stamina, but without those implemented yet, I've imposed an arbitrary limit. The colored stripes will indicate whether you have the resources to return
- Instead of a separate inventory menu, it is combined with a creative mode menu. This lets players cheat in stacks of any item to their inventory, including items that represent blocks and tools.
- Players can place items that represent blocks by right clicking near them. This follows most conventions for placing blocks in games like this: you can't place a block on something that isn't solid, and you can't place a block very far away from you. You can place blocks through other blocks, unlike the builder. These differences are to make block placement feel different depending on whether you use a tool or place them by hand,
- On that subject: the builder now uses blocks from your inventory. It looks to the left and right for an item that represents a block and places that at the indicated location.
- I've added a suite of example items and blocks partly to show what's possible with the engine, and partly so that those inclined can look at the json and play around building their own toys.

I'm behind on development logs mostly because I haven't felt like writing them, but partly because, until now, it was pretty hard to see what I had made. With the new stuff I've put in over the last two releases, plus all the stuff I didn't talk about for the last one, I can probably put together a couple of long posts, which I'll work on over this next week. I've been thinking about making Wolfire-style video updates too (they do them for Overgrowth). I think it's good practice for making trailers and, to an extent, public speaking, but I'm not sure whether people want or like them.

Before the next release, I'm going to move stuff over to Visual Studio Community 2015 for my Windows dev. They've got some nice profiling/diagnostic tools that look pretty powerful, plus the title menu is back to regular Title Caps rather than the ALL CAPS of VS2013. For the next release, other than some code and asset cleanup, I want to expand the definitions system to include animations and entities and support clear load order and inheritance/overloading, so that it's possible to safely and easily modify things between packages. That's probably going to make the whole loading system slower, so I might try to thread some stuff, and finally implement hot-updates to assets and definitions. Too, it might be time to start loading external code so that people can make their own extensions and entities without having to wrap my game and implement their own InitState (nobody's done it, but that's the way to do it). All of these changes start paving the way for a dedicated content-building app for the game too, so that might work its way into subsequent releases.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Wed Aug 12, 2015 12:48 pm    Post subject: Reply with quote

I finished a meandering and long development log! Crossposted from my blog on my forums.

These development logs have been few and far between, mostly because I'm lazy, but also because it's hard to explain features that people can't see. The last development log was for from the prototype to alpha 0.0.0. Between 0.0.0 and 0.0.1, there were two big features that made the other parts of that release possible: the new package loading system and text rendering. 0.0.2 added a little bit more content to 0.0.1. The big jump to 0.0.3 introduced extensions, which are how most in-game interaction will be supported. 0.0.4 is mostly user interface parts and some fixes to show off what was possible in 0.0.3.

The most important change included in 0.0.1 was the switch to a reflection-based packaging system. Json.NET is capable of deserializing json into objects, but I often use different representations for in-game objects and on-disk objects. Previously, every type that used this system had its own method that copied all the appropriate data out of a definition; now, there's a method that will copy the values out of a definition and into an object, using a series of attributes to define things like nested types and conversions to in-game representations (for example, List<> to HashSet<>). It also adds a bunch of quality of life things, like object name validation (changing "Name" to "MyPackage.Name") and automatic delegate insertion. The first thing to use this were the biome definitions, which consist of several nested things to define. With 0.0.3 and extensions, this system is somewhat more abused: extension types are chosen and created at runtime and populated via this system. As long as the chosen extension type is in the dictionary of allowed types, it's possible to initialize and populate something this way, which shows off both the power and limitations of the system. Because I didn't design the system to be used outside of the "SomethingDefinition yields a SomethingObject" way, you can't use attributes to aid in deserialization, which is something I plan on fixing in the next release. In fact, I might rebuild large sections of it to reduce work and more cleanly load simpler objects. Most changes I'd need to make for that boil down to changing some types throughout the program, adding attributes to things, and changing where the system looks for said attributes.

Among other major changes coming to the packaging system is proper support for overriding other objects. A basic inheritance model is in place for materials--behind the scenes, materials are just block definitions; however, values are still filled when deserializing something: even if a block starts out as a clone of the material block type, the system will copy over all the zeros and empty strings if fields are uninitialized in json. To get around this, it's possible to mark a field as inherited if it matches a default value. That's easy for strings and lists but problematic for booleans and integers. There's multiple ways to tackle this, from parsing the raw json to adding a field to definition objects that lets people define what they're inheriting/overriding. While the solution will probably be a combination of the two (and a lot of refactoring), it touches on an idea that's important to a game with mods: overriding. The system currently supports a complete replacement of an object in the game: ensure your package is loaded after the one you want to override and present and object to replace the previous version, using that package's name as a prefix. I think it'd be a lot safer to provide modders (and myself) with a simple way to define an object as a parent to inherit from, basically copying it into a new name and changing some fields, or define an object to override selected fields with.

Overriding also touches on a different issue: packages. Right now, packages are dumb containers for assets and definitions. The game looks at them once, loads everything in them, and never bothers them again. To support things like hierarchies, packages need to be able to define a load order. Another small problem I run into with packages has to do with fonts. Currently, a font is loaded at all the default sizes, which means for every font, the game makes six or so versions at various font sizes. This is easily fixed by letting packages define the sizes for the fonts it includes; it just wasn't important enough to implement before. Eventually, I'll add and read more data about packages, and add menus that interact with them--things like a package chooser when creating new world and splitting the creative menu by package.

One of the other important features added in 0.0.1 was text rendering. SDL has an extension library that handles the drawing of glyphs to a SDL_Surface, however, itís quite slow, so often-changing text is problematic, plus, itíd mean Iíd have to push new surfaces to the graphics card every frame. Instead, I pre-render each font to a texture, tracking the areas of all the glyphs. An in-game label looks up the appropriate glyphs and draws them, using the generated texture. Because resizing the window destroys all target textures, I have to re-render every font when the window is resized, but itís better than trying to create a new surface whenever a line of text changes. My system doesnít currently handle kerning, which Iím thinking about adding. SDL_TTF doesnít hand you nice kerning data, so Iíd probably have to extract it by checking each two-character combination and finding the difference in width for the kerned v. unkerned versions, then shifting each character by that when drawn, but Iím not sure if anybody would notice either way. (Plus, itís probably a good idea to minimize the number of Dictionary>ís floating around)

Extensions were the big thing added in 0.0.3, allowing me to track data and events for in-game objects. An extension is just a class with a bunch of event handlers, capable of saving and loading which events it subscribes to through the standard save/load methods. This isnít quite as simple as it sounds--C# delegates canít be safely serialized--so it has to track the names and types of the delegates it has, then load them from GameInfo (the registry where types of things are kept) when being deserialized. I have play a few tricks with reflection to make registering delegate and extension types and adding delegates to extensions not just easy, but also automatic. Instead of talking about how the extension system works, Iíll go through how all of the extended blocks and tools function:

- Laser: all tools use an ItemExtension to get access to BeginUse, Update, EndUse, mainly. The laser is quite simple: in BeginUse, it sets its Active flag on, then damages the first block in a raycast from the player during Update.
- Builder: the update function calculates a raycast every frame to accurately draw the beam. BeginUse places a block at the end of the raycast.
- Mover: in BeginUse, it checks its ray to see if it hits an Entity. If it does, and the entity is a minimum distance away from the player, it stores a pointer to it. During Update, it sets the velocity to a vector pointing to the mouse, and tries to rotate it back to 0 degrees.
- Launcher: this one only has a BeginUse function, where it creates a grenade entity and initializes it to fly in the direction of the mouse. Soon there will also be entity extensions, so instead of the logic behind grenades being locked up in compiled bytecode, I can expose it to json like other in-game objects.
- The ďoverpoweredĒ tools: these use the same code as the other tools, but with all the numbers increased.
- The test tools: these all use ItemExtension as their extension class, meaning they rely on Extension.UserData to store data relating to their abilities. Most of them have a BeginUse handler, but a few use Update.
- Explosives: blocks have an appropriately named BlockExtension that gets access to Place, Break and Update events, but also similar events for adjacent blocks. Explosives are simple: when they break, they call Sector.TriggerExplosion.
- Damage Balancer: I think these are probably the coolest out of the series of example blocks. They have an update function that attempts to balance the damage from the surrounding eight blocks based on each blockís maximum allowed damage. These in chain can make some cool shield-like structures.
- Self-Repairer: a very simple block that removes damage from itself in Update.
- Super Damage Balancer: this block combines the previous three: on update, it attempts to balance damage between its Moore neighborhood and itself. Itís more efficient than a regular damage balancer, but it explodes when it breaks! I think itís a neat way to show off easy it is to create new blocks from old ones: all it has to do is define the UserData needed to support explosions and repair, then add the appropriate delegates.
- Rigger: this is probably the most confusing of the bunch. When itís placed, it attaches extensions to the blocks next to it, so that they explode when they break. Apart from that, it doesnít do anything else, and can be safely placed and removed to make traps.

Sparse has come a long way, and certainly feels as if itís on the brink of becoming a ďreal gameĒ as it were, instead of the sort of tech demo/toy itís been for over a year now. However, itís not there yet, and thereís still lots of work to do, both in making it a game, but also in finishing the things I was talking about in the other development logs! Iím nowhere close to building a runtime property inspector, which was one of the first things I wanted to add. Itís easy to focus on the far-away things and miss out on the medium-away things. I think the next release will be the last release where Iím purely working on toys for the game, and the release after will start bringing things I could call ďgameplayĒ while keeping a straight face. Iím excited.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9441
Location: Not Finland
PostPosted: Mon Aug 17, 2015 2:44 am    Post subject: Reply with quote

I somehow missed your latest release... probably because of all the craziness last month :|

I'll give it a shot and see how it feels this time.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Mon Aug 17, 2015 10:03 pm    Post subject: Reply with quote

I'm refactoring some code to usefor LD this weekend and since I'm using Visual Studio 2015, I get access to C# 6, so I thought I'd try out some things mentioned in this video.



It's beautiful...

I'm also very excited to use the new elvis operator (?.) for events and delegates, since it clears up around five lines into one.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Niunio Martinez
Member

Joined: 26 Nov 2013
Posts: 99

PostPosted: Wed Sep 02, 2015 9:35 am    Post subject: Reply with quote

Will wrote:


So, that's C#, isn't it? And I thought C++ was a confusing heap of stuff...
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Wed Sep 02, 2015 7:26 pm    Post subject: Reply with quote

Niunio Martinez wrote:

So, that's C#, isn't it? And I thought C++ was a confusing heap of stuff...


It's just syntactic sugar. GetIndex could be written like this:

Code:

public int GetIndex(int x, int y)
{
    if(ValidPosition(x, y))
    {
        return y * Width + x;
    }
    else
    {
        return OutOfBounds;
    }
}


It just saves 10 lines of vertical space (8 in K&R style) writing it as a single expression with no braces.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9441
Location: Not Finland
PostPosted: Tue Sep 08, 2015 3:35 pm    Post subject: Reply with quote

Quake-style rocket jumping is alive and well :)

The launcher makes things move along much faster. I like that a lot.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Sat Sep 12, 2015 3:24 am    Post subject: Reply with quote

Playing around with a new image format for tiles



Once I clean the code up and put support in BlockDefinitions, it should be a lot easier to make tile art. This format also supports inverted corners neatly, which I think is kinda cool.

I'm also trying out Aseprite as my graphics/animation editor. I'm liking it so far.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Mon Oct 05, 2015 10:21 pm    Post subject: Reply with quote

Well, after spending the best part of a month playing around with some other stuff, researching the Json library I'm using, and thinking about implementation details, I'm finally getting on with rebuilding the definition loading code. It's shorter, less complicated, and supports more, which goes to show both the value of iteration and how awful my first designs were. I also found Hjson, which, as I'm using Json as a user-editable definition format (rather than a data transfer format), I've added support for. I've put up a gist of this just-finished, untested version, if anyone is interested in looking. I've still got to write the part where it cuts up an entire document, sorts by load priority (so that inherited objects are loaded after their parents), passes the parts to LoadObject, and copies the results into their proper dictionaries, but it's a start.
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Will
Member

Joined: 28 Nov 2013
Posts: 60
Location: California
PostPosted: Wed Oct 07, 2015 8:50 pm    Post subject: Reply with quote

Crossposting a new development log. It feels kinda weird posting them here, since I try to approach this place with a more conversational tone, and I approach blog posts with a proclamational tone. /me shrugs.

Development Release Alpha 0.0.5 is in the works, but still some time away. At the time of writing, I've rewritten the defition loading system, I've changed how the art behind blocks work, and I'm working on integrating all of those together. I've also added a series of scripts to help package the game, generate C# names for all the assets, etc. This release is going to be mostly "things that should have been done earlier." Lots of little development things, like being able to reload art in-game and refactoring the BlockMap class to support more things to some gameplay stuff, like getting the basics of a survival system into the game. These are subject to being cut, if I want to release without them, but those are what I'm building towards recently.

I've migrated the project to Gitlab instead of BitBucket. I prefer the design of the site, and Gitlab gives you more storage space. With the migration, I've started moving some of the mess of little text documents I have lying around onto the provided wiki. I plan to keep better track of changes and To-Do stuff on there, too, making it a place where I keep track of both design ideas and technical stuff. Eventually, it'd be nice to open it up to the players, so they can get a good idea of what I'm aiming for in the design and see how development is progressing. It also seems like a good place to correllate data for modders, too.

At some point in the future, likely after 0.0.5, I plan on doing the "early access" thing for real, and selling releases as they come out. This won't mark the switch from "alpha" to "beta," which, for me, would indicate that the game is almost feature-complete, and moving into balancing, testing, refinement, and other polishing stages, but I might switch up the release types between "Development," "Testing," and "Public," to distinguish how stable a release is, and how long to expect before the next one.

"Some point in the future" could mean upwards of four months, but my plans are to host the paid version of the game on itch.io initially, and hopefully making it through Greenlight to a final release on Steam. As far as pricing goes, I don't like the idea of changing the price from alpha to beta to final release, so it'll stay at $15.00, probably with a 20% discount if/when it goes up for pre-order on Steam. I don't think early-access is trusted or, really, noticed by players on Steam, so, hopefully, the game doesn't get too much attention before release. This seems like wistful dreaming, though--the game is barely more than a tech demo right now, so back to work I go!
_________________
Parents of young organic life forms are warned that towels can be harmful, if swallowed in large quantities.
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Sparse Page Previous  1, 2

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.