This is a bit of a milestone. It’s not that it didn’t run on WP7 before, but there was no input method.
The virtual gamepad is something I’ve been putting off for a long time, but I managed to write and implement it last night at Starbucks before I even finished my coffee. While I did that, Kehnon got enemies implemented in the combat system, and now combat exits when all the enemies are dead. Geoff is getting to work on audio and graphics, and we should have a pretty decent demo to show by the end of the weekend.
The big projects right now are combat and map generation/propagation. Both are coming along, as you can see in the videos. I’m focusing on the map stuff, and I’ve handed combat off to Keynone to implement all the damage calculations, skill usage, and number crunching.
I’ve started work on a combat system. Rather than the typical turn-based or ATB system, I’m building it around the idea of queuing attacks in advance. A timeline will show upcoming attacks like an old-style piano roll. The battle clock advances one “tick” and any attacks scheduled for that “tick” are executed simultaneously. You could get a bonus for creating “chords” or “sequences.” Each character gets a queue of up to five attacks, and the same goes for enemies. If you see an enemy attack coming up on the timeline, you can edit a character’s queue to counter it. Inversely, enemies may try to counter your attacks as well.
As you can see in the video, it’s still very much a prototype at this point. Right now, attacks queue up and execute properly. Watch the increasing number to see what the current “tick” number is. Character 0 is using an attack with a delay of 15 and a new attack is added on execution for debugging. That means it attacks every 15 “ticks.” Character 1 is using an attack with a delay of 16, character 2 an attack with a delay of 17, and so on.
The next step is to add some numbers. Right now, attacks don’t actually do anything to their target BattleEntity. I need to add statistics and damage equations. I’m also going to start the timeline when I get a chance. Actions on the timeline will be represented by three icons representing actor, action, and target.
I’ve written a bit more about the concept here, along with some ideas that probably won’t make it into the final system.
I’m not dead, I’m just finishing college. Between now and the DBP deadline, our focus is going to be putting together a finished game, though it might be on a smaller scale than what we originally had in mind.We’re going back to a fantasy 8-bit setting, but keeping the procedural generation theme. This limits the game to one planet, but we’re looking for a ~2 hour play time to preserve replayability and encourage experimentation with classes.
Right now, I’m working on the overworld generation script. My big thing right now is making distinct continents. I can space them out to where they’re all distinct, or tighten the numbers to get a few overlap and make larger continents. Game flow is built around going from one continent to the next, and you need to explore them all to finish the game. Look at the mini-map to see what I’m talking about.
I’m also redoing some of the menus. Character creation is cleaner now.
In preparation for Microsoft’s Dream.Build.Play 2012 challenge, we’ve made the decision to change direction:
We have decided against building a demo game, as it would be a waste of time and resources that could be devoted to our main project.
We are no longer pursuing a steampunk-economics theme. Our new concept leans more toward science fiction, but maintains many traditional fantasy elements.
We’ve abandoned the “strict 8-bit” aesthetic, which never looked right on SDTV output in the first place. Our new direction is closer to a “16-bit” look, but I’m hesitant to call it that. It’s low-resolution, but it fills the 16:9 frame.
A major element of the game is algorithmically-generated maps. The screenshot below is a sample of a planet generated at runtime (using this tileset for testing).
It’s been a while since the last update, but we’re still making progress. I’ve officially started on a demo game (The Wizard’s Tower) to finish building the engine around. The little two-island map was fine for testing the map code and stuff, but now I need to start doing towns, shops, and quests. I’ve got a whole game planned out that should showcase everything I want the engine to do, so now I can objectively gauge my progress by how much of that demo game is implemented. It’s also nice to offset my time spent coding with some content. Content is fun for a change, especially maps.
I sat down the other night to write some story notes and a list of maps, and ended up with a four-page design document. That’s not including a flag list, monster encounter table, dialog index, item table, equipment table, save point list… Still, it’s a good starting point, I just need to work out all the crunchy numbers and details.
Geoff is starting on the character sprites, and I like the style so far. The “warrior” class is mostly done, we’re still doing some little tweaks to it, but it should serve well as the template for additional sprites . In this game, there will probably be six classes, and we’ll probably enhance the sprites for reuse Stormfront Legend, perhaps adding gender variations to each.
I’ve been playing with tiles and color palettes, and I’ve decided on the (approximate) Commodore 64 palette for The Wizard’s Tower. I’m still working on removing “free” resources from the tileset, but it’s getting closer to being 100% original Factory-Eight work. I’ll see if Geoff can do some overworld trees to replace the ones from the OHRRPGCE 8-bit tileset I’ve been using.
I wish I had an interesting video or something to post, but a lot of the recent changes aren’t really worth making a video about…
Volume controls are implemented. There are separate BGM and SE controls on the System screen of the MainMenu.
The System screen also has a CRT effect toggle, as well as a “filter” option. If playing on a real CRT at 480i, the filter prevents flickering colors in solid areas. The CRT effect is not recommended on a real CRT, unless you like emulating scanlines and phosphors inside scanlines and phosphors (lots of flickering…). On any LCD, you should get a clean, unfiltered picture with Filter and CRT off. If you’re running at 720p or higher, enable both to get an exaggerated “retro display” look. Eventually, I’m going to add an optional “noise” filter to give the picture some static. I’m not satisfied with the Xbox 360′s lack of a native 240p output mode, but SDTV output is definitely acceptable.
I figured out how to use the IntermediateSerializer to output objects as XML that can be loaded by Game.Content. Now we can get to work on an editor, and share the library project with it and the game. Keynone is working on porting his WPF + Microsoft SQL Server dialog box editor into an XNA-based solution.
Keynone has also started on the combat screen. Right now, it just loads the character sprites to their positions on the battlefield and activates the command list. Cancel exits combat.
Since he’s got something to show on the combat screen, I implemented the random encounter system. The map screen calculates the StepsUntilCombat, and the CurrentCharacter decrements it on a completed step and checks if it’s zero. It doesn’t decrement if the CurrentCharacter becomes something ineligible for combat, like the airship (the airship has it’s CanDoCombat set to false). The boat still can have random encounters. If you’re entering a vehicle or landing on a door, the number doesn’t decrement. After a battle or on a map load, a new StepsUntilCombat is determined. Minimum and maximum values for StepsUntilCombat are stored as map properties, and you can only have random encounters if a map has those properties. That took all of fifteen minutes to implement…
We’re all on Twitter. A lot of the cool XNA developers are on there, so I figured it would be a good way to network and get some exposure. I would never use it personally, but it’s a neat tool for developer interaction. I’ve been posting short updates on there as they happen, so you’ll see things there before they show up in these blog updates.
My next goals are to finish the System menu (almost done, needs text speed and the noise filter), finish the shop (you can buy items, but it needs quantities to purchase, and a sell screen), and continue adding to the inventory system. Items have lots of properties that aren’t used in the code yet, mainly status effects. I need to determine a way to implement status effect remedies that allows me to stack effects. An antidote heals poison, but shouldn’t be usable on a healthy character. Same with an item that heals all status effects, but it should be usable if even one status effect is active. So, that means adding lots of boolean values to items, two for each status effect. One easy way around it is to just use single-effect items, and let tents reset every effect. That’s no fun though…
Today (well, yesterday; it’s after midnight now that I’m finished writing the update), I didn’t do that much, but I did get a few little things done. The big new feature is the typewriter effect. I had a general idea of how to implement it, but debugging it took a good two hours. As I went along, I got the idea to do a sound effect when it “typed” a letter, and I started having fun with it from there.
All the sound effects are made in sfxr. The “random” button is pretty useful when you just need something that sounds low-fi, and I’ve probably wasted too much time making neat sounds when really, I should be working on code. It doesn’t help that there’s also a port (as3sfxr) that runs in your browser.
I’ve been planning on adding music playback for a while, but it wasn’t until today that the end-of-song crash issue in the SharpMod library was fixed. Why use big uncompressed WAV audio when you can use MOD music? The song in this video is public domain, and you can find it here. Still waiting to hear from the SharpMod guy on manual looping, but at least music works now.
Next things on my list are the shop object (list of items, pretty simple), the ShopScreen (it’s like inventory with a quantity picker, buy/sell option, and purchase confirmation), and the SystemMenuScreen. The system menu is going to have options for disabling the CRT effect and the like. As of yet, there are no plans to have a widescreen toggle in this project, but the next game might have it added to the system menu.
My next real chance to get any work done will be Tuesday evening.
Did some more work on the UseItem screen, now it’s looking better…
I’m implementing a non-fading transition for the menus. When you switch to a different menu screen, it overlays the target screen on top, and moves it to the bottom of the screen list (makes it draw last so you see it on top).
Since all the menus are actually xTile maps, I had to overhaul the display device system. Each map needs its own xTile DisplayDevice if you want to draw more than one at the same time. Two maps can’t be drawing on the same shared DisplayDevice. Not a big deal, just make a new one for each game screen.
Sony just opened up the sign-up for beta access to the PlayStation Suite SDK. It’s C#, so our engine is ready to port over. Let’s make it happen…
Thank you very much for your interest in the Developer Program for PlayStation Suite (Closed Beta Test). When we are ready for your participation, we will get back to you through this e-mail address.
Developer Program for PlayStation Suite (Closed Beta Test)へ
お申込み頂き、誠にありがとうございます。選考の結果、
ご参加頂くことが決定しましたら、
