As it turns out, OpenGL loves to check for errors after every call. This makes you spend about double the time in OpenGL every frame. We were going kinda crazy trying to figure out what the problem was; I assumed it was my fairly elaborate collision detection. But running the Python profiler exposed the truth, and now we’re at a happy 30 frames per second again.
Managed to more or less finished some of the wall and floor tiles last night. As soon as I was done (as goes with these things) I noticed a number of artistic and logical issues with tile placement that weren’t apparent while making them. In the end, I decided to start again. So far in the space of about 30 mins I’ve re-achieved what previously had taken about 6 hours. Funny how this whole thing goes. So much learning.
It feels a little hard to have to start again on a lot of these things so frequently, and makes me feel kind of stupid the first time around. I think the experience is worth it though. Certainly since I am working on this so regularly these days my general ability to create graphics is much faster than it has been in the past.
Also, I almost took some screencaps last night! That was about 5 mins before I decided I needed to start again, though. Maybe once I have something that I like I’ll show an evolutionary side-by-side comparison.
For our meeting on Saturday, I made some tiles that Fet and I could use, as mentioned earlier. These were really simple, basically a new set that had some floor tiles, some stone blocks, and some pitfalls – the basics for making a level. Since then, I’ve been working on a developing a nicer version of this interior set. It’s going really well, last night I finished up the basic wall tiles. They’re quite clever, if I do say so myself, and allow for great flexibility! I’m getting much much faster at quickly developing these sets, too! Hopefully I can finish the floor tiles for this set this evening and we can really make the interior levels a little more interesting.
Maybe I should post some pictures of this stuff. Words are so much more time-consuming to devour.
This weekend gone, Fet and I managed to carve out a few precious hours to actually work on Paraplu together in the same room. The progress was substantial.
Most of the work we do on Paraplu is conceptual – either I’m making tiles outside of a level, or Fet is tweaking or introducing a new feature for which there is no art. It’s been very rare thus far that we actually assemble any of these pieces we have. Whenever I do attempt it, I am impressed with how quickly and easily it is possible to assemble something roughly game-shaped in a small amount of time.
With this, both of us are relatively inexperienced at some of the concepts associated with this. We haven’t either of us had much practice in making levels, or really thought about the consequences our current system has on level design. Each time we delve into this realm it is deeply enriching and we learn a lot in a very short while. Some of what we learning is surprising, and gives us an exciting insight into what our forefathers must have felt when designing their first experimental levels: getting an idea for how to direct the player around the level, to inspire a sense of adventure and curiosity through the lofty building bricks of Passable and Impassable tiles. It’s an artform, and the first time you put brush to canvas, it inevitably feels heavy and unfamiliar in your hand, yet the tantalising and powerful potential is there – through this medium you can fashion exciting, undiscovered worlds into a form that can be experienced by others.
And yet, once we had made a level and put some basic enemies in it, we were left with the “now what?” feeling.
Fet summarised it well, “What makes this game Paraplu?”. I have many clever ideas, most of them are most likely a programming nightmare! I’m usually too scared to mention them to Fet, but I often do anyway. Trying to expand the scope of the game beyond just killing enemies, without introducing complicated code is a difficult challenge. But, for the time being we must remain strong and focused. We can make levels quickly with a great editing tool, and you can do things in them. Next: learn how to make levels! That’s progress, and it’s really good fun, too!
Still feeling very inspired, have been working on Paraplu pretty much every day. :D
Talked to Fet the other day about changing the way levels work in the game. Previously, each level was just a single screen, and now we’re looking at making it so that the edge of any given level will (optionally) take you to another screen, like in TLoZ. Moving in a more adventure game / exploration model direction, it seems!
Started working on an interior tileset for a murky, ruined interior a-la Temple of Doom or something of that ilk. Made more progress in a short time than even I anticipated, with walls and floor tiles already in some workable form after a single evening’s work!
Will keep going with this tonight.
Still making progress! Managed to finish version “A” of the cliff tile-set earlier this week. Easily the most complicated tiling i have attempted. Many tiles have to be able to seamlessly tile with about 6 other tiles in any combination. In the end I managed to bother Fet into working out some slightly more flexible tile masking arrangements to make the task a little easier, but man I am i glad to be finished with it. I can see how many people only have 2 or 3 “texture” tiles – making them all compatible is just such a huge headache!
Regardless, as always I have learnt a lot of very useful tips and tricks in doing this. I’ll probably have to rework the overall palette and touch up a couple of the seam combinations that I didn’t get a chance to try, but overall I feel like finishing this is a fairly major milestone.
In doing this, I did a fair bit of studying of older tilesets, and became interested in discovering how artists overcame the severe limitations (both in terms of colour and size-on-disk) of making graphics for the 8-bit era. Did you know that in Fire Emblem there are 3 tiles TOTAL for walls? Really clever, I never even noticed. With that, I started investigating possibilities for what I might work on next, and I think an interior set, something in the spirit of the kind of atmosphere found in La-Mulana (which, by the way, is an amazing and free game). Such a tileset would be based on perpendicular tiles, and the “seams” would be natural edges found in tiles, meaning that any given floor tile would “automatically” be compatible with any other tile. The amount of work this takes out of the equation is tantalising, as doing seam matching accounted for about 75% of the time it took to draw the tiles. Additionally, fewer tiles overall are required, further reducing the time investment.
I also started to think about the effect that interiors might have on the game itself, as they (often) lend themselves to more confined and technical level layouts. I immediately started to recall the wondrous level designs of earlier screen-based dungeon games, particularly Zelda and its kin. Fashioning diabolical traps and wending dungeons seems like much more interesting way of going about things after the designs I have toyed with thus far. My Capability Brown-like insistence on making outdoors areas look “natural” limits the flexibility of their designs, although it does produce attractive results. But quite aside from that, the prospect of having these quite different and interesting “modes” of play – combat-heavy fields outside and tricky puzzles and traps inside – makes Paraplu seem even more awesome in my mind than ever before. This is going to be FUN.
I like to ramble, evidently.
Last night I got some good work done! Along with the work that fet was able to finish yesterday we’re making some solid progress. Pictures soon, promise.
Fixed some bugs in shooting while running animation
Re-exported shooting while running frames
Updated palette on various grass tiles
Made Mycon spawning “hole” (might change this to something more elaborate later)
Began work on cliff tileset
We have made lot of progress in the past few days.
Thanks to my coworker Andrew, we finally got Python and its dependencies properly set up on Julian’s MacBook so that he could run the game himself. Before that, were having to rely on making prebuilt copies on my machine whenever anything changed. Considering how simple and approachable Python is designed to be, setting up packages and installing things is a giant frustration.
Jules convinced me that we ought to increase the map size by a lot; we now have tons of tiles to work with. Levels that take several minutes to work through are now more possible.
After finding dual-stick Robotron controls unwieldy, and unable to agree on a tap/hold scheme, we decided to offer *both* of the tap/hold schemes. Tap either button to fire in the direction you’re moving; hold the Jules button to maintain your firing direction as you strafe around; hold the Fet button to halt your character in place and shoot in any direction.
Adding a hit stun effect to the enemies when you hit them was a big step in the direction of making Paraplu feel like a game. It’s a tiny thing, but seeing an enemy shake back and forth and halt for three frames is quite satisfying.
After putting it off for a long time (god knows with good reason) Fet managed to help me get a dev environment set up on my new Macbook. I would say that this has been something that has caused progress to be slow, but I would really just be making excuses. Regardless, it did allow me to try my hand at using Fet’s nifty level edit mode to make my first level last night. Holy crap.
It happened so easily, so naturally. We have all these tiles and features in place, and in about 10 minutes I was done making a new level that, if I do say myself, looks great! I could make ten such levels in a single evening if I so desired. I plan to do just that in the coming week. It also helped me to realise a few very easily remedied issues with my tilesets. How much putting these things into practice can reveal.
With the incredible Cave Story coming out for Wii this week I’ve been massively inspired (Daisuke Amaya is not only one of my biggest influences, but one of the people I admire most in the game-development world period). Things have slowed down a little at work, I have some free time, it seems an appropriate time to jump on development and get into a groove.
Until today, the only way to finish a level was to kill all of the enemies in it. Of course, with our new infinitely enemy-spewing doorway thingys, there would have to be another way. I set up an objectives system that allows us to define any number of different conditions for beating a level.
In the process of testing out the â€œget a particular itemâ€ condition, I became stuck inside a rock. This has been going on since I put together the obstacle collision, and I decided to attack the problem. It turned out to be more difficult than I’d expected. At one point I had a crazy system that checked how many character pixels were overlapping with the obstacle, and compared it to how many would be overlapping were the character allowed to continue on her current course:
In the end, I just did a simple series of four checks (which I originally deemed too tedious) to analyze the x and y components of the character’s velocity, and stopped either one if following it would result in a collision. This lets you slide along an obstacle if at least one of your axes of motion is still valid.
Hi! Tonight I implemented a bunch of stuff to add flexibility to our map objects. When an object is added to the map, it checks a dictionary of dictionaries of dictionaries to find out if it should have any special attributes. One of the possible attributes is an “initStep”, which is the name of a function to call one time when the object is created. This gives us a free pass to do anything we want with a new map object: add it to some special sprite group, give it a weird behavior, and so on.
The initial motivation for this was to be able to create crazy puzzley situations like an enemy spawner which constantly sends dudes across a space toward a hazard that kills them. This creates a sort of doorway of enemies that you have to blast through. Actually the hazard will kill any mortalGuy that comes in contact with it; that includes both enemies and the player…
The best you can ever do with a project like this is to keep pushing yourself and trying your best. Often, when the context is as easy ‘n’ totally cas like then it’s hard to remain disciplined. I’m extremely bad at this. Recently I very much wanted to try to shed this taxing trait, and after a thoughtful chinwag with Fet, implemented a simple system of understandable boundary-creation and deadline-setting. The complication with our particular situeÃ© is that there is no reprimanding hand to turn us should we be unindustrious. Well.
So far, over the last week or whatever it has worked surprisingly well. The major, and difficult task of re-redoing all of Vivienne’s animation frames and modifying them for a new context is done, and soonly we should have all of the materials we need to fully animate Viv in game.
I don’t want to let up, this pace is great!
Today I worked on the hit points system for the main character, and the damage and dying mechanisms that that implies. Now the character has a hit point total, can be hurt by enemies and their projectiles, and dies when reaching 0 hp. Pretty basic stuff, but it was taken out for the sake of simplicity when I copied the ship code over from Soft Landing, and it needed to be rewritten.
Thankfully, the code to do all this, including flashing Vivienne red and making her invincible for a short mercy period after taking damage, was quite easy. It only took about half an hour, and worked the first time I tried it!
This should pave the way for building our first few fun, challenging levels, now that the presence of enemies in them actually has some consequence.
Over the past couple of days, I’ve done a lot of work on the equipment system. It was harder than I expected, but now you can equip various types of items that determine how your attack works. This is the core of the “algorithmic shooter” concept we originally devised together. In Paraplu, your attack is calculated based on three types of equipment. From our internal planning site:
- Weapon determines ROF, bullet type, range, damage.
- Costume adjusts ROF, damage, range. â€œFiring upgradeâ€. No costume should be objectively better than another, and most should offer similar factors of improvement. We want costumes to be valuable and interchangeable throughout the game.
- Accessory adds special effects of all kinds: number and direction of bullets, explode on impact, swirly paths, poison, fire, et cetera. â€œMeta upgradeâ€. Practicality of these can vary widely.
I have got the mirror system working, basically. This is how you equip weapons, accessories, and costumes. It was remarkably difficult to make a system that simply opens up a menu, then opens up another menu based on the item you chose. Those old NES RPGs full of nested menus must be a lot more sophisticated than I ever imagined.
But, in the process of getting that working, I really refined the whole concept of the focused (foremost) interface box, and the management of interface modes. Now the game always knows pretty clearly what is going on, and it should be easy to add more multiple-step interfaces.
I also factored some code out into functions, for doing common things like figuring out the selected item in the foremost menu, constructing the syntax needed to show an item’s icon and name side by side, and unfocusing the focused box.
Not a whole lot of work today, but I’m trying to keep some momentum going. I added a wardrobe object (with awful programmer art, of course) to accompany the cabinet object in the atelier. Now, different types of items are stored in the different containers: materials in the cabinet, and costumes in the wardrobe. We’ll need to add a vanity for accessories, too, once we have some of those.
It occurred to me lately how strange it is that at work I’m a designer who keeps his hands off the code, and in MOMO PAX I’m a programmer who keeps his hands off the graphics.
I had a nice time coding in the little food court at Whole Foods today.
- After several hours of work, taught our most basic enemy how to avoid obstacles. This is way harder than it seems, and I had to write in a bunch of psychedelic drawing effects to visualize what what happening in the code. It turned out I was telling it to go in a direction only if any obstacle existed that it wouldn’t hit, rather than if there were no obstacles that it would hit.
- Fixed a weird string-length bug that became apparent when resetting the description box for an item.
- Started moving the main character to a specific spot on the screen when moving between areas, so that you can’t arrive stuck inside a bush.
I was determined to get into a Paraplu groove today, because it was the first time in a couple of months that I had a significant chunk of free time to myself. After getting energized by some bass-playing, coffee, pinball, and Ar tonelico music, I sat down to plow through some coding and planning tasks. It went well!
- Designed a master chart for all enemies, the items they drop, item rarities, and crafting recipes.
- Wrote a system for enemy spawners.
- Added a spawning effect for when enemies appear from a spawner.
- Wrote the item drop probability system. Enemy types have the possibility of dropping one of each of a common, uncommon, or rare item. The probabilities of dropping one of these rarities of item, or any item at all, is customizable per enemy.
- Made it so that items you collect in adventures properly appear in your inventory when you visit your atelier.
- Filled in all of the items, rarity rates, and recipes for the items we have in the game so far. You can theoretically craft a Peasant Dress in the game now if you keep at it, but once I collected the ingredients I immediately got stuck inside a bush.
**Update:** I’m unstoppable!
- Subclassed Interface as TextBox and ViewBox, because once again that class had gotten huge. It was taking up half of the “guys” source file! Really cleaned up how the interface guys work.
- Added enemy portrait and description, in their own little boxes, to the bestiary system.
- Added item description, in its own box, to the inventory system. We have written lots of cute little bits of text about the inhabitants and artifacts of Nettle-Belfry, so this is a big step.
**Update:** My unstoppability continues!
- Set up statistics for how many times you have beaten a certain type of enemy.
- Made the bestiary hide enemy info until you beat that enemy at least once.
Progress is steady now. I am working pretty much every evening on Plu, and managing to tick off boxes every day. Feels good! We will soon have all the parts required to make a working, fun level, which is a very important step to take, obviously. We are simultaneously slimming down un-needed parts of the game to speed up progress, and overall the feeling of progress is wonderful!