Chemaria - Building and material-focused Terraria-like


#1

11/23/2018

Why am I making this?

So back about a year ago now I started work on a Defold project that has since become very important to me. I went through the Runner tutorial provided by Defold, then modified it a bit. Final product ended up being a game suitable to propose to my then-girlfriend, now-fiancee, with!

Defold was fun and easy for that time being, but then I got busy again with school, but eventually came back to wanting to make another video game, from scratch this time. I came up with the idea of Chemaria when I was on a Terraria and Minecraft binge with my college friends. I came to find myself wanting Terraria’s gameplay style, but with Minecraft’s focus on building and redstone logic circuitry. So then came Chemaria!

Breaking down the name…

Chem stems from an intended focus on diverse materials and material crafting in the game. Example would be that if you find some copper and tin ore. Smelt those into some ingots and then you can smelt 1 tin ingot and 4 copper ingots to make 5 bronze ingots. Ratios will intend to reflect reality, but there will be situations such as with pewter where, in real life, it is 99% tin but with a bit of copper, bismuth, etc. So this introduces a new game mechanic which is enrichment, but we don’t need to get into the details now. :stuck_out_tongue_winking_eye: The main goal behind having varietous materials is to allow a larger and more logical expansion of the available materials of the game for better customization of household items.

The aria comes from…well, Terraria. I wanted to give credit where it is due and the base design do come from Terraria.

Current state of things…

Right now, I only have two sprites: stone and dirt. (Hey, I am a computer scientist, not a designer or an artist, be nice!)
stone dirt

I started developing this game in Unity and have player movement, Physics, and block destruction and placement. But…I found Unity to be much too cumbersome and resource-intensive for a 2D game, so i switched back to Defold and I could not have made a better choice. Defold is insanely intuitive for non-programmers and deeply empowering for us programmers who want to control every line of what is going on. I hope to post to this as often as I make any real progress. My most immediate task is to convert what I have on my Unity project over to Defold so I gotta slug through that of course. In the meantime, I would not shy away from any community help in regards to asset and sprite design. :stuck_out_tongue: I haven’t settled on an art style yet, for I think it’d be best if Chemaria allowed texture packs, but I would love to hear what you all think!

What I want from this dev diary…

I mostly want to get ideas from a group of people passionate about games as an art form and as entertainment media. I want your opinions and I want your guidance as this thing moves forward, so any and all suggestions go ahead and make it. Even if the suggestions are as intimate as to how I structure my code. (Do remember though, my code is in a transition between engines right now so develop is a wonky branch) Thank you all, and thank you Defold, for the support so far and the support to come!


#2

Is your project public? Because I can see only 404.

In general - your idea is vast :smiley: I mean, such games are great, though making it in 2D allows you for many simplifications, so I’m keeping my fingers crossed! :wink: Will it be side-view like Terraria? You are focused on chemistry, and thus I suppose there will be a lot of crafting, right? :wink:


#3

My bad! I set the repo to public now so you can look at it. :slight_smile:

It will be side-view like Terraria, but I was actually toying around with the idea of having more than just the one lane of building and one background wall. Maybe having 2 or 3 lanes of building with a wall between each lane to allow buildings with actual rooms and a slight bit of depth, but at that point it felt like just a limited 3D world? And how would I make the user experience manageable as a player of the game switching between the lanes? It seemed to bring more questions and complications than useful features? (If this still seems like a good idea in anyone’s opinion, please let me know and I can look into some potential solutions for this perceived clunkiness of the system)

And yes! There will be loads of crafting! For simplification for both me as the developer and for others as the player, the crafting will be more like Terraria than Minecraft where it simply tells you what you can craft with what is in your inventory.


#4

Really cool—this is probably the first “Engagement by Defold” we’ve had so far :slight_smile:

Terraria sounds interesting, looking forward to following the progress.


#6

Really cool! I’m happy to see that you’re making progress! What specifically did you have problems with when you tried to use Orthographic?


#7

I followed the install instructions, attaching the camera.go to my player character and then the screen was just black. I messed around with different settings but it simply wouldn’t come into view. I am sure I am just using it wrong, but I could not figure it out.


#8

Taking a look now.


#9

I am also now having some issues with release being different from when I run and build in development. In my normal game, I can generate all of my blocks for my template world like in the picture above, but in release it only creates one block. It would be easier to debug if I could figure out how to get debug messages or log text in release. The log.txt file is created when I run the application, but no text is placed inside.

Are there any things off the top of your head that are inconsistent between development builds and release bundles? I am using Windows 10 right now.


#10

I did the following:

  • Added defold-orthographic as a dependency
  • Removed RenderCam as a dependency
  • Project->Fetch Libraries
  • Changed from RenderCam render file in game.project to the one provided by Orthographic
  • Removed RenderCam camera from player.go
  • Added camera.go from Orthographic to main.collection
  • Expanded camera.go and selected the camera.script
  • Checked the Follow box script property
  • Set Follow Target script property to /player
  • Done!

#11

Yes. You can’t do tostring() on a hash and try to process that value to get a human readable string that you can use to for instance build URLs. Like in the url_hash_to_string() function that you have.


#12

Yeah, I saw a post you had replied to talking about just that. I removed the lines which call that function and the world generation worked fine. I see the issue now. I was using it so I could use goput to register events to sprites, but I can use my indexing methods with the chunks and blocks to do the same thing instead. Thanks!


#13

That worked great! I guess there is an issue when you place it on an object you wish to follow though. Thanks though because I was really stressing about not being able to use Orthographic Camera over Rendercam. :grin:


#16

11/30/2018

What has been accomplished

Conversion is done! The Unity project I had has been essentially recreated in Defold, with some extra small features.

  • The player can move left and right, jump, and double jump
  • The player can mine blocks (they just disappear for now)
  • The player can place blocks, decrementing the store of items in their toolbar
  • The world is tracked by chunks and blocks by position

World tracking

I struggled for a bit wondering how best to track the world chunks because I was unsatisfied with how I had done it in Unity.
I tried a bunch of different techniques, but I settled on something I believe to be greatly scalable and (with a little math thrown into some helper functions) very simple to use!
The short version of it is this:

  • The world consists of a 2D Lua table of chunks
  • Each chunk consists of a 2D table of blocks.
  • Each chunk contains a position representing its index in the world’s 2D chunk table and consequently in the game world itself
  • Each block contains a position with these bounds 0 <= x < 12 and 0 <= y < 12 representing its index in the chunk’s 2D block table

The world and chunk object are currently largely analagous structures, but I anticipate great differences later on so I have separated them for now. By choosing this model, using Rendercam’s screen_to_world_2d function and some interesting math, I am able to directly index what chunk and block a user click is interacting with.

Problems I ran into

I did not really want to deal with Defold’s built-in camera on my own and I knew I would need later to map screen positions to world positions, so I sought out my options. I first tried out Orthographic Camera but I failed to get this to work. After a few hours, I switch to Rendercam and it worked immediately for me (If anyone wants to pull my code and try to map everything over to Orthographic Camera, feel free to do so since it has more features, otherwise, I will be sticking with what I got).

If anyone was particularly perceptive, you may have also caught a post I made about issues with collisions. Thankfully, britzl was wonderfully helpful and suggested Platypus, a minimalist 2D platforming engine for Defold. With only a little setup (which was well-documented), my problems were solved and I was able to move right along.

Next steps

I will be focusing most of my time coming up on allowing the player to pick up broken blocks, and implement the beginnings of a true inventory system. The game in general is going to stay pretty visually unappealing as I get these base functionalities in. Thankfully, Defold seems to do a good job of separating the logic of animations and the beauty of the game you are developing that you can develop with that in the back of your mind. Once I believe Chemaria is in a confident state, I will begin to improve the visuals.

Farewell for now!

I want to thank the Defold community, for you all have already been very supportive and responsive in a unique way. And that is that, talk to you all later!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Quick Update

britzl was able to provide some help in fixing the use of the orthographic camera and we fixed a breaking bug in the game only present when built. Here is a little update picture from the first dirt hut of many to come!

12/1/2018

Inventory Update

The beginnings of the inventory system are here!


Right now it has the same functionality as the toolbar, where it simply highlights selected items. Unlike the toolbar, it does not determine what blocks are being placed.

The next step is to implement some kind of drag and drop on the inventory to allow arranging and moving items to the toolbar.

World Generation/Loading/Saving Revamp!

Calling all of this a revamp is a little misleading, whoops. I did change the world generation a bit, becoming more general for right now in early development.

I also removed all of my up-pointers from Chunk and Block (before they had a pointer from the Chunk to its World and from a Block to its Chunk). This was changed to make printing an object easier (no more truncated output on printing one block) and to allow saving the World to a file (same issue with infinite recursion on the Lua table due to the pointers). The pointers were instead replaced with a position vector I can use to obtain the relevant object from my collections pretty simply in code.

Saving and loading does now work though…in a limited fashion. :upside_down_face: I am using sys.save() and sys.load() provided by Defold, but I am already running into size issues when saving the world to a single file, and the saveable world is FAR from the intended size of the game world of the final product. I looked into other implementations for saving a table to a file, but none of them worked with userdata (understandable because it can change drastically between programs. This becomes a problem due to the vector3 provided by the vmath library.) I believe I could make a workaround by simply storing a table with x, y, and z values and then map them to vectors on load from the file, and then implement one of the many options out there for saving large tables to files. If anyone has a better suggestion though, I am totally open to any help one could give.

I believe this use case for sys.save() and sys.load() were simply not meant for tables of this size for games of this scale, which is understandable given Defold’s beginnings as a game engine for mobile games, but as the engine expands its kingdom into these other gaming platforms, the ability to save files larger than 512kb may become necessary sooner than later. I posted an issue to Github regarding this.

P.S. Sorry about the posts being shifted around and reposted. I got the no more than 3 consecutive posts message and did not understand what it meant at first (It’s late at night, give me a break) but now I understand better. Will not happen again!

12/2/2018

Inventory Management

Have you ever needed to organize the piles of dirt in your pocket? Well in Chemaria, now you can do just that!


You can notice a few changes already in this screenshot. First, we finally have textures on the item slots of the toolbar and the inventory. On top of that, item stacks can be dragged and dropped between the toolbar and inventory with ease.

I expected this to be much harder to solve than it actually ended up being. The problems I ran into caused me to generalize the way I index the collections in the UI (toolbar and inventory) and now there is a general solution written to swap items back and forth in the UI.

What is next?

As of right now, if you desire to make a lot of pixel art, once you run out of those 10 stacks of 64 dirt you are out of luck. So I believe the next most important feature Chemaria needs is the ability to pick up broken blocks/items. I anticipate this being a fairly simple feature, but as any developer knows, this could turn into an absurdly large endeavor for the smallest unexpected reason.

Future of Chemaria

Defold has sped up the process of making this game like I hadn’t expected. Many of the basic features of this game are likely to be hear much sooner than I ever anticipated. Once I have gotten Chemaria to a point where I am comfortable letting the general public mess around with it, i intend to throw it onto Steam DIrect and at that point, fork off of my public repo and make the forked project private. This way anyone who wants to see how I implemented the base game will have full access to the initial codebase, while still preserving my intellectual privacy moving forward. In the end, I want this game to not only succeed in fulfilling my vision, but also provide a good point for others to start from and reference for their various questions or needs.

12/4/2018

Item Pickup

The ability to pick up items is in the game! I implemented max stack sizes per item, so when you attempt to pick up an item, it tries to find the first spot of the same type with less than the max stack size. If it first finds an empty spot, it will fill it in. As of right now, it is a very naive approach, so it simply reads through the toolbar and then the inventory and places the block in the first valid spot it finds.

Likely in the future I will change it to place it into the first spot of the same type with less than max stack, and if it cannot find a spot, place it into an empty spot.

What is next?

I am likely going to be working on more of the logic for world rendering and loading. Currently, the whole world is instantiated at the same time, including all of the game objects. I will be implementing dynamic loading and unloading of world chunks. Likely, this is going to be a very complicated problem compared to most everything else that has been implemented so far in Chemaria, but I feel comfortable with the foundation at this point to begin messing with how this is done.

I decided early on that I did not want to work on loading and unloading until after I figured out how the player should be interacting with the world itself and we are at that point! All other features that I deem necessary before release are more peripheral or more UI-based, so it does not relate to the world loading and can be tabled for now.

Benefits of the Dev Diary

This dev diary has really helped organize my thoughts and priorities through making this game. It also has given me a checkpoint at the end of each feature I am excited for: letting everyone know where I am and hopefully encouraging other blossoming game devs to follow their aspirations, instead of sitting back and saying, “This would be nice some day but I can’t [insert fake excuse here]” as I did for so long.

12/11/2018

World Loading/Rendering

The world now only loads within a set distance around the player! This allows Chemaria to have arbitrarily large worlds but only load and render a subset of game objects at any given time.

This was a bit interesting to implement. I ended up resorting to some good old-fashioned set arithmetic to find what chunks must be deleted based on what chunk the player moved into, compared to the chunk they inhabited before.

What is next?

At this point, I will be working on getting a basic crafting system in. At least initially, I will be taking a lot of inspiration from how Terraria does it, where you are simply presented with the options of what can be made with what you have, but I will be adding my own flavor to it of course.

After crafting is implemented, I will be spending much more time on the visuals of the game:

  • Block and Item Sprites
  • World Background
  • Character Sprite and movement animations

I am also running into an issue with saving large worlds to a file but, as I have mentioned before, I have submitted a Github issue on that matter and I have a workaround in mind if a fix is not made in time.