Author Topic: Quick changes, Huge improvements  (Read 5948 times)

Soulmask

  • Newcomer
  • Posts: 12
  • Karma: +0/-0
    • View Profile
Quick changes, Huge improvements
« on: April 13, 2015, 10:49:43 PM »
So now I'm pretty deep into development and usually programming simple things can take a long time, but there has been exceptions where huge improvements to the game where done very quickly. I have two on the top of my mind:

1. Main map navigation: I'm making a strategy roguelike, inspired a bit by dwarf fortress in that there is a "base map", where you do most of the gameplay and you have to navigate in it. At first I thought navigation would be super hard to do, but in the end it probably took me less than 30 mins to implement and now I could navigate through the whole map! I was pretty inexperienced in programming at the time compared to now, I improved a lot imo, but even in my noob programmer stage it took me less than 30 mins and map navigation is the first thing that gave me the feeling I was in a game when running my program! Sweet memories.

2. Font for ASCII games: For 80% of the dev time I was experiencing what I call "the blur". When I ran the game, the map was blurry, and I had this feeling like my game looked like crap, which my ego rationalized as non-sense, my game couldnt look like crap it was just because I wasn't used to it right? Well at one point when I finalized the first version of my "Character Sheet" menu, I looked at the first time my game with a lot of text in it, and the blur was still there! I thought the blur would be gone when reading text, but no. So now I thought, if it's blurry even when in mostly text form, it most mean the font itself sucks and not the characters/colors I chose for the actual ascii graphics. Took me 5 mins to find what I was looking for(I'm french so word for font is police in french, I also tried "ascii graphics" and "dwarf fortress graphics"), then I finally found I was looking for a new font, then it took me 10 mins to choose a new font: my only criteria was blurriness. To find blurriness I stood 5 feet from the screen, which maximised character blending and thus the blur, and when I found a font that had almost no blur(plus nifty semi-graphic walls(replacing line and double line characters)) and the actual implementation took me 2 mins(1 min because I forgot to add .png to the file address). Result? My game doesn't look like crap anymore! No blur at all, it even looked good. I had been working hundreds of hours and the biggest improvement I did took me 15 mins, and it's by far the most efficient improvement I've done so far. For reference I was using libtcod 12x12 font(the blur) and changed it to unknown curses 12x12 markvii walls font which can be found in the dwarf fortress wiki font page.

What are your stories about small improvements that drastically improved your games?

Trystan

  • Rogueliker
  • ***
  • Posts: 164
  • Karma: +0/-0
    • View Profile
    • my blog
Re: Quick changes, Huge improvements
« Reply #1 on: April 14, 2015, 02:26:28 AM »
Good stories.

1. Log to the screen: I'm sure I'm not the only one who has a few print statements in the tricky parts of their ai code. One thing I did years ago was start writing it to the screen as a message (if the player was in sight) instead of to a log file. So by changing
Code: [Select]
Debug.log("Low health: " + creature.name + " eat " + food.name)to
Code: [Select]
creature.doAction("eats " + food.name + " and looks better.")it became easier and far more interesting to see what my creatures were up to and why. The world was much more interesting once I saw what was going on and that tiny change made a huge impact to the feel of the game.

2. Use maps (dictionaries, hashes, associative arrays, etc) instead of 1D or 2D arrays: I used to store items and creatures in an array or list and iterate over them when I wanted to know if one was in a specific location. I tried using a map of position to item one day and it worked. It worked really well and the code for lookups was much cleaner, the performance was better (not that it mattered really), and modeling it this way seemed like a better "fit".