Here is the new Nordenfelt dev log. This week I was occupied in level asset creation and made decisions on sprite scale and tile usage.
Sorted Saving Order
The editor did not sort the sprites in background layers while saving. Therefore hitting the SAVE button twice for the same level produced different files. This was fixed to avoid Subversion telling me that a level has changed just due to reordered sprites.
Stamp Design for Level 1
As mentioned here I start most of my design work with stamp-sized sketches.
The top-down view includes decisions regarding perspective: How far away is the ground? What’s the sprite scaling factor? A high factor results in more details on the floor and turrets, tanks and boats would become very small. I want less detail work and big enemies.
So: the closer the better.
Tiles or Segments?
Nordenfelt’s engine allows using tiles as well as sprites at arbitrary positions. My first intention was to use tiles for saving RAM, harddisk space and artistic effort. What I did not know was that tiles are quite hard to draw when they should not look boring or gridy. Artistic freedom is less restricted with level segments. They are like tiles but spanning over the whole play field width. Segments are easier to draw, don’t need seamless edges and move the level building work over to Blender. This tool became second nature to me so I’m happy to work with it most of the time now.
Level Segment Prototyping
According to this article I made quick-and-dirty asset prototypes and threw them together in Blender. This is a first draft of a farm level segment:
The farm houses don’t have colors, the trees have all the same color and there is a chocolate river instead of a street. That’s prototyping!
Photos and videos are very important for creating assets. They give new ideas, serve as modeling templates and are guidance for animations. Further you no longer have to fudge new ideas. Adapting existing stuff is easier and faster than coming up with something completely new.
Collected Free 3D Models
Models for detail sprites like trees, bushes, stones, crates or barrels are freely available on the net. They are not worth the effort making them yourself. Therefore I’ve inspected some sites like www.turbosquid.com and got all those tiny give-away things useful for my game.
Farm House Modeling
Nordenfelt‘s first level has a rural area with farms and fields. The first models I made for it were some farm houses without textures or colors:
The models are low-poly because they don’t need more details in the game:
There will also be fields of grain, corn or simple grass. This is the first grass tile test done with Blender:
Showing asset work is always satisfying. It gives me this fuzzy feeling of progress. Good for the soul.
The coming days will also be spent on level assets. I’m wondering if I can show you an ingame video next Wednesday. So be sure to subscribe to Nordenfelt’s RSS feed or follow me on Twitter at @black_golem to not miss the next dev log entry.
As mentioned in dev log 3 I was chasing a strange particle system bug for many days now. Watch the following video to get an idea why it was so annoying. Look at the boat’s exhaust fumes (the black dots) and the emission direction rendered as red line:
It looks totally wrong! The fumes don’t go along the red line but “swing” left and right. What the hell is wrong here?
My first intention was a failure in my own particle system orientation code. After absolving my code I started demonizing the SPARK particle library. Day after day I was decomposing the lib without success. Everything was right, nothing to blame.
Around dev log 4 I paused. Maybe some time off would give me new access to the problem.
Some days of fun & booze later I went on debugging. Reseting my mind did not help. There was still no answer. Until yesterday.
Question: How can something mathematically correct look so wrong?
Answer: You have to ask the right question. Try again!
OK: What do I expect to see? How should the particle emissions look like? How to falsify wrong results? What affects the particles?
Question: What are the parts of the expected particle emission model?
Answer: That’s the right question, young lad! You forgot to include the level scrolling and the boat velocity.
That was the problem. I started searching the bug too close to the base. Missing high level effects made the emissions look wrong. Humans tend to compare game physics with real life physics. Therefore I expected the level scrolling and boat movement to be included in the particle emission calculation. But they were not.
Lesson learned: Know what to expect from code before you judge it.
That’s it for this Wednesday. After this debugging odyssey I can go on with the fun stuff. Subscribe to Nordenfelt’s RSS feed or follow me on Twitter at @black_golem if you’re curious what the fun stuff is. 🙂
This week there’s nothing new to show. I was on a vacation … some kind of. Today I went on debugging the particle rotation failure mentioned in the last dev log. The bug is still there. I can hear it laughing.
This Wednesday I have just two points: a new enemy model and a really nasty bug.
New Cannon Boat
This is the first nautical vehicle in Nordenfelt:
Hunting a Stealth Bug
Adding exhaust particle effects to the cannon boat unveiled a curious bug. Check out the following two screenshots:
The upper image shows a boat heading from left to right. In this case the unit has no rotation as the debug display “native rot = 0” tells. The lower image shows the same boat pointing in the opposite direction, the unit has a 180 degrees rotation. Now compare the orientations of the exhaust particles relative to the boat orientations. Can you see the failure?
Today is the fifth day I’m chasing this damned bug. It’s a really tough beast. Hopefully it will be squashed soon to go on with more interesting stuff to show next Wednesday.
In the meantime feel free to subscribe to Nordenfelt’s RSS feed or follow me on Twitter at @black_golem.