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

Login with username, password and session length

 
Advanced search

1345127 Posts in 61701 Topics- by 53273 Members - Latest Member: SyedAlan

August 18, 2018, 02:05:53 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsMoonQuest (OUT NOW!)
Pages: 1 ... 177 178 [179] 180 181 ... 188
Print
Author Topic: MoonQuest (OUT NOW!)  (Read 1069853 times)
jack0088
Level 0
*



View Profile WWW
« Reply #3560 on: July 25, 2016, 03:01:41 AM »

I render every 16x16 set of tiles into a render texture, and only re-render them when they change. Then I just render those textures to the screen.

My friend, Jasson, who makes a game called Crea does it a different way: he uses vertex arrays to batch the tiles into a few draw calls. Both approaches have their pros and cons.

Ben, thank you very much for the insight! I really appreciate that!

I will try out both, since I had an idea similar to Jasson's method: making a mesh with 256 faces, assign each face a tile (which is just a region on same texture) and render that mesh in one draw call. When changes appear re-assign faces on the go.
Logged

Hobby game developer and Lua enthusiast. Currently working on Cavemen, an 8-bit roguelike.

Engine of choice: Codea | Language of choice: Lua
Fallow me @twitter
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #3561 on: July 25, 2016, 03:08:06 AM »

How did you settle on 16x16 specifically? Does it begin to get slower again after that? Is it like a sweet spot? How big is one tile, so that I know how big 16x16 are?
Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3562 on: July 25, 2016, 05:35:00 PM »

I render every 16x16 set of tiles into a render texture, and only re-render them when they change. Then I just render those textures to the screen.

My friend, Jasson, who makes a game called Crea does it a different way: he uses vertex arrays to batch the tiles into a few draw calls. Both approaches have their pros and cons.

Ben, thank you very much for the insight! I really appreciate that!

I will try out both, since I had an idea similar to Jasson's method: making a mesh with 256 faces, assign each face a tile (which is just a region on same texture) and render that mesh in one draw call. When changes appear re-assign faces on the go.

Yep that's a super simple way to do it, good luck! Smiley

How did you settle on 16x16 specifically? Does it begin to get slower again after that? Is it like a sweet spot? How big is one tile, so that I know how big 16x16 are?

One tile is 8x8 pixels, but tiles can be bigger than that with edges that stick out etc. I didn't test 16x16 tiles vs, say 8x8, so I'm not sure which would be better. For my physics I cache in groups of 4x4 tiles.
Logged

MOONMAN devlog WWW FORUM
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3563 on: July 30, 2016, 12:04:24 AM »

Update: I updated to Windows 10 this week. The game still runs well, though I had to update my graphics drivers.



We've done a heap of tiny things this week, bug fixes, system-level stuff, and other things:

FIX: A vertical line would occasionally flash.
FIX: Misc bugs between low/med/high gfx modes, they all work perfectly now and the game runs well in low mode on my 5 year old mac mini.
FIX: Rare crash on OSX to do with submerging entities
Updated launcher to show gfx options and changelog. Removed old options. (see below)
Re-enabled vignetting, there's an option to turn it off.
Cleaned up gui options a bit.
Window dimensions are now saved on exit.
Updated Laser rendering
Restructured Linux build, now it's bundled as a simple tar and will check for updates.


I also did some major work done on build and deploy system -- it has to be cross platform and support the different modes of distribution (humble, itch, steam, mac appstore, ...). Each distribution platform has it's own method for handling updates and deployment, so it's just a matter of plugging into each of the systems. The standalone auto-updating version will still work as normal, though the game will also auto-update through itch and steam. Many details still need to be sorted out.

Sam is building the OSX launcher next week. It'll work like the windows one. For the linux standalone version we'll just have a shell script which you type from command line, it'll check for updates too.



Alex has been doing lots of work on cleaning up the ice and tomb areas in the Mesa. Despite drowning in post-its, I'm feeling confident that we're on schedule for the beta release.
Logged

MOONMAN devlog WWW FORUM
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #3564 on: July 30, 2016, 01:52:55 AM »

I also did some major work done on build and deploy system -- it has to be cross platform and support the different modes of distribution (humble, itch, steam, mac appstore, ...). Each distribution platform has it's own method for handling updates and deployment, so it's just a matter of plugging into each of the systems. The standalone auto-updating version will still work as normal, though the game will also auto-update through itch and steam. Many details still need to be sorted out.
I've been pondering this sort of stuff lately... If you could be bothered and have the time to write something up about it in more detail, I'd love to read it. c:

Sam is building the OSX launcher next week. It'll work like the windows one. For the linux standalone version we'll just have a shell script which you type from command line, it'll check for updates too.
Why do so many people do it this way? It's generally just a small GUI application, right? Why not write it using a portable library off the bat, so that it works everywhere? :/ People at my job did the same thing and now I have to write a Mac version of their launcher from scratch instead of just writing portable code from the start (tho they sort of had a reason, since they're using Unity and they used a proprietary update tool for that and that came with a Windows launcher but no Mac or Linux ones...).
Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3565 on: July 30, 2016, 04:57:16 PM »

I've been pondering this sort of stuff lately... If you could be bothered and have the time to write something up about it in more detail, I'd love to read it. c:

Remind me when the game is out and I will!

Quote
Why do so many people do it this way? It's generally just a small GUI application, right? Why not write it using a portable library off the bat, so that it works everywhere? :/ People at my job did the same thing and now I have to write a Mac version of their launcher from scratch instead of just writing portable code from the start (tho they sort of had a reason, since they're using Unity and they used a proprietary update tool for that and that came with a Windows launcher but no Mac or Linux ones...).

For an application a cross-platform UI toolkit makes a lot of sense, but a small launcher is only a few hundred lines of Windows/Mac code and once written has minimal dependencies. Lines of code shouldn't be the only metric you base a decision on.
Logged

MOONMAN devlog WWW FORUM
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #3566 on: July 31, 2016, 01:56:22 AM »

I was rather thinking about stuff like manageability... Like when changes need to be made, they need to be made for all versions... And consistency, because it might be more difficult to make the launchers match each other if different libraries are used and so on. :E

Also seems easier to just learn one library, like Qt, and not many, which might have their own weird things going on since they're not generic, and they might written in different languages. And say you don't have a Mac or a Windows machine yourself, you can just give the portable code to a friend who does and have them compile it, for example.

Not trying to tell you what to do—I just find it curious! Shocked Not necessarily that you personally are doing it this way, but that it seems to be so common.
« Last Edit: July 31, 2016, 02:07:25 AM by Prinsessa » Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3567 on: July 31, 2016, 09:05:24 PM »

I was rather thinking about stuff like manageability... Like when changes need to be made, they need to be made for all versions... And consistency, because it might be more difficult to make the launchers match each other if different libraries are used and so on. :E

That depends on the complexity of your launcher. If it's just got a few buttons and a checkbox then there is so little work to update it.

Quote
Also seems easier to just learn one library, like Qt ...

I've used Qt for a few different projects, and it's a big dependency to carry around with you. Qt will also increase your game download size by a significant amount. Boost is another library that pains me to carry around.

Quote
And say you don't have a Mac or a Windows machine yourself, you can just give the portable code to a friend who does and have them compile it, for example.

This is the ideal of cross-platform libs, but unfortunately is not so straightforward. I also avoid cmake, scons, etc, and just use per-OS project files. I've spent way too much time debugging cmake errors, building and updating dependencies, and so on. I believe in cross-platform libs for things with lots of code (I use SFML for the actual game, for instance), but for small tools the overhead of an extra dependency is sometimes not worth it.

Quote
Not trying to tell you what to do—I just find it curious! Shocked Not necessarily that you personally are doing it this way, but that it seems to be so common.

Ha that's okay. I'm grumpy and just want to do the minimum work.
Logged

MOONMAN devlog WWW FORUM
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #3568 on: July 31, 2016, 10:13:41 PM »

I've used Qt for a few different projects, and it's a big dependency to carry around with you. Qt will also increase your game download size by a significant amount. Boost is another library that pains me to carry around.
Yeah, didn't necessarily mean Qt. It was just the first one I could think of. But something like it. There's probably something more lightweight out there that serves similar purposes.

but for small tools the overhead of an extra dependency is sometimes not worth it.
Can't say you're wrong! Tongue

But hey, even if the platform-specific code is written manually, I suppose it could all still be wrapped into one project/codebase with some thin abstraction and a couple of #ifdefs either way! Hand Metal Left
« Last Edit: July 31, 2016, 10:23:40 PM by Prinsessa » Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3569 on: July 31, 2016, 10:43:45 PM »

Yeah, didn't necessarily mean Qt. It was just the first one I could think of. But something like it. There's probably something more lightweight out there that serves similar purposes.

Yep totally. I haven't looked in a few years but I used FLTK a while back, it was okay. TBH I also could have used SFML+ImGui which would have been a no-dependencies job.
Logged

MOONMAN devlog WWW FORUM
PsySal
Level 8
***


Yaay!


View Profile WWW
« Reply #3570 on: August 01, 2016, 11:28:08 AM »

Hey! Was reading and I had a tiny bit of experience I wanted to share, FWIW:



1- On the starter

I had to do a starter for The Real Texas. I used wxWidgets. The earlier version used wx 2.6 which generally worked very well. For the recent Steam release I upgraded to wx 3.0 and there were some really terrible conflicts with SDL2. But I was quite happy with wx 2.6.

However writing three separate launchers is also not a terrible idea-- honestly it might have been less work for me to do this, but only because of the issues I had getting it to play nicely with SDL2. The problem, roughly, was that I had to start SDL2 to get a list of screen resolutions, then shut it down, then start wxWidgets but populated with those screen resolutions, then shut down wxWidgets and re-start SDL2. This was (as far as I can tell) not a problem on the SDL2 side but a genuine problem on the wxWidgets side, causing crashes that were for different causes on all three platforms. I literally had to use three separate solutions for each platform and debugging this was a huge headache. Source-diving into wxWidgets was too scary (I tried.)

I am planning to back-grade it to wx 2.6 since this version never gave me any problems (2.8 might be alright, too.)

For Paradise Never I am not including a starter at all.



2- On the auto-updater

I wrote an auto-updater (integrated with it's own starter) for another game Paradise Perfect Boat Rescue. The thing I was most worried about was-- what happens when my web hosting is hacked? It will be hacked, it's always going to be hacked. So how can I guarantee that I don't infect all my customers/players with malware?

What I did was use RSA to sign the updates. The client that the player downloads has the public key, and refuses to install anything (and gives a warning) that isn't signed properly. This way, even if my website is hacked, the hackers cannot convince my client to auto install anything (I keep the private key in an encrypted container that I only mounted for signing purposes.)

I wrote my own RSA implementation, which was a bad idea from a computer security standpoint but an excellent idea otherwise (as in, it's really fun and interesting to do, and not that much work actually, unless you were to write your own prime number generator for the key generator, which I did not do.)

I didn't read earlier about how your auto updater works, hopefully it's not condescending that I'm pointing it out and I kinda expect you probably already got it sorted (mad respect for your work!) but it's an easy oversight to have so better safe than sorry. And Moommamm will easily have 1,000,000 users I think Smiley so worth doing carefully!
Logged
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3571 on: August 02, 2016, 12:07:18 AM »

What I did was use RSA to sign the updates. The client that the player downloads has the public key, and refuses to install anything (and gives a warning) that isn't signed properly. This way, even if my website is hacked, the hackers cannot convince my client to auto install anything (I keep the private key in an encrypted container that I only mounted for signing purposes.)

Ahh, you know what .. I hadn't even thought about this. I thought md5 hashing was enough but it totally makes sense to also RSA sign it with a priv key that isn't stored on the server. So I actually spent the whole of today implementing such a system.

Now my file hash is made by file -> SHA256 -> RSA PKCS #1 1.5 -- (signed by a private key on my build system). The launcher then uses a public key which is embedded in it to decode the hash.

Quote
mad respect for your work!

Haha, you too dude Smiley
Logged

MOONMAN devlog WWW FORUM
standardcombo
Level 8
***


><)))°>


View Profile
« Reply #3572 on: August 09, 2016, 08:31:14 AM »

Implementing auto-updaters is kinda cool, but why is that needed in case there's a Steam build anyway. Steam handles the update right? Why is it worth the effort to create and maintain a whole different build and deploy system?
Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3573 on: August 09, 2016, 02:49:52 PM »

Implementing auto-updaters is kinda cool, but why is that needed in case there's a Steam build anyway. Steam handles the update right? Why is it worth the effort to create and maintain a whole different build and deploy system?

I used the system for alpha testing and it definitely was worth the effort for that. You're right, Steam auto-updates, as does Itch, but other vendors like Humble don't, and the auto-updater will remain to fill that gap. The good thing is that it requires minimal maintenance.
Logged

MOONMAN devlog WWW FORUM
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3574 on: August 13, 2016, 11:44:54 PM »

(Last Weeks) Update:

I'm heading down the coast for a few days so this week has a short and early devlog. Sam and I have been working on build systems and launchers and Alex has been updating mesa tiles and cleaning up all the creature sprites.

For the standalone auto-updater I plugged a security hole (now updates are cryptographically signed). I've also been working on integrating the build system with the various vendors, including itch.io and steam. Itch was very easy to incorporate, and if you use the itch launcher then the game will auto-update through that. Here's a shot of itch downloading a test build.



Steam is a little more complicated due to the number of features it has, but I'm slowly working through it. It's kind of cool and feeling very real to see the game stub appear in my Steam library..



On OSX the launcher is up and running. After some deliberation we decided that we won't support a standalone auto-updater on OSX and Linux. Both platforms will still check for updates and notify if there is one, however you'll have to manually download it from humble or itch or wherever you bought it. Under steam, itch launcher, and mac appstore the game will auto-update as normal.

The creature work involves tidying up all the animations, determining new behaviours and animating those, and setting up the colour mappings and sprites for the variations. Such as the Komodo and Dragon below ... they use the same basic sprite but the dragon has a couple more layers and is colour mapped.



Update (This weeks!):
I was planning to write a big post about the build system, but I ended up working all weekend on the game. I guess that's a good thing, right? :smiley:

I'll probably still write up the build system at some point, but today will be another small devlog.

Build System: All platforms and vendors are setup and working properly. I can do a full build from my work computer -- this includes building for steam, itch, and humble, building for linux in a virtual machine, and building for osx by remoting into my mac at home. Then I have a script which deploys them all and sets up a useful tasklist for the manual tasks that would follow (like checking boxes in steam's web interface, uploading changelogs, etc.)

Misc things: The game runs successfully in itch app's 'sandbox mode', which protects the user from malicious software. The game embeds steam's api and exe wrapper, which just makes sure that Steam is running if you're running the steam version of the game. I'll be hooking up some features like Steam cloud and other things in the near future.

Alex has been experimenting with the character select, title screen, and bits and pieces like creature anims and sand tiles. Sam has been finalising the OSX launcher and remaining linux build issues.

Another boring devlog update, but I'll be getting back into content and gameplay programming this week!

Here's the osx standalone launcher in action:





Logged

MOONMAN devlog WWW FORUM
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3575 on: August 20, 2016, 03:47:19 PM »

Update: 12 days on, now I get today off :slight_smile:

Improved controller support: You can now navigate menus with controller, keyboard or mouse. I'm working on inventory navigation with the controller and then the last thing will be to snap interactions .. e.g., if you're facing a chest and close enough you will just be able to press a controller button to activate it (without having to focus the reticule on it).

Lighting improvements: The lighting system is much improved (for high gfx mode). Amongst many tweaks, torches now feed into the tile-based lighting system. Here's an example:



Colour levels: We added a better colouring system to the game. This will be used to give some extra colour control over full levels or parts of the level. For instance in the forest level the graphics will get bluer and bluer the further down the cave you go. The system works exactly like the Colour Levels dialogue in GIMP (and probably photoshop), which means we can setup levels in that program and then copy them over into the game. Here are some examples, though it will be rare to see such extreme colour mapping:



Among these things we've been working on concepts of the title screens, cursors, veil surface, and we've also been finishing off the osx and linux build system. See you next week, thanks for reading!
Logged

MOONMAN devlog WWW FORUM
RujiK
Level 2
**



View Profile
« Reply #3576 on: August 22, 2016, 08:52:32 AM »

Quote
the forest level the graphics will get bluer and bluer the further down the cave you go

This idea. I like this idea.
Logged

nathy after dark
Level 5
*****


Bene Gesserit Witch


View Profile WWW
« Reply #3577 on: August 22, 2016, 09:32:59 AM »

Quote from: eigenbom
we've also been finishing off the osx and linux build system.

Would you mind sharing some details about that? I'm also working on cross-platform builds for my game, and I'm pretty stumped on OSX as to how I build an executable that's compatible with older OS versions. Building with CMake and AppleClang on my El Capitan Mac, the executables it makes are only compatible with El Capitan (my OS version). What's more, I'm not really sure what a good minimum OS version for Mac might be.
Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #3578 on: August 22, 2016, 04:13:14 PM »

Quote from: eigenbom
we've also been finishing off the osx and linux build system.

Would you mind sharing some details about that? I'm also working on cross-platform builds for my game, and I'm pretty stumped on OSX as to how I build an executable that's compatible with older OS versions. Building with CMake and AppleClang on my El Capitan Mac, the executables it makes are only compatible with El Capitan (my OS version). What's more, I'm not really sure what a good minimum OS version for Mac might be.

Well there's an option in Xcode where you can set the deploy target. We chose 10.7 as our minimum version (meaning you need at least a 2005 mac to run the game). I googled and found that CMAKE_OSX_DEPLOYMENT_TARGET is the flag you need for cmake.
Logged

MOONMAN devlog WWW FORUM
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #3579 on: August 22, 2016, 08:57:52 PM »

And if you need to, you can always dig up old versions of SDK's or Xcode on the Apple Developers website.
Logged

Pages: 1 ... 177 178 [179] 180 181 ... 188
Print
Jump to:  

Theme orange-lt created by panic