| Thursday, December 30, 2004 |
  Switching Compilers, Diablo Game | 
Posted - 12/30/2004 4:47:04 AM | [journal dump]
C#
well, here i am installing vc#express again. the only problems i actually had with it before was, the worry of expiration due to it being a beta, and that it broke my project into 3 partial classes (which i wasn't very fond of). muer suggested i make a new template that didn't break up the project, but i think i'm going to try it with the partial method for a while and get used to it. #dev's load time and bugs are driving me too batty of late.
something else worthy of note is that i've been using .net 1.1 and express is installing 2.0. i'm doubtful about its reverse-compatibility, but we'll see how it goes when i get it all installed.
ITEM-HUNTING GAME
well, jenn and i went over what we wanted for a quick demo of the game i wanted to build so long ago: a diablo-type game. it's hard to figure out what we should have in the demo and what not to; we don't want too much in the demo, but at the same time, we want enough to show what the game intends to do.
i'm not really sure what to do right now, the first step is getting two guys onscreen and give control to the two joysticks.
[working] well, i just threw a quick sprite sheet together for a greyscale link. if i need, i can color this green and then red for the two players we'll drop into the demo to start with. it consists of 4 directions of walking (2 frame animations) and 4 directions of swinging the sword (2 frame animations). link can perform other actions like jumping and holding things over his head (and dying i suppose) but for now its all i'm going to need.
right now i'm going to be happy to get two players on the screen and let the joysticks dpads move the players around. hmm. maybe i'll go grab the sword graphics too. [working] i didn't do it exactly like they did it in zelda:LA, but who cares.
 
| |
| Tuesday, December 28, 2004 |
| Target Practice | 
Posted - 12/28/2004 10:52:58 PM | I suppose it could be better, and it was never meant to be a game: but i'm sure i'm finished with this for real. You can find it here. Here's a neato pictar~
[journal dump]
TARGET PRACTICE
i've been putting it off for too long. its time to make a highscore table, and/or complete the game cycle (title screen, game, highscore, repeat). i'm going to make a new form for this, just to make it easier to do. can i just go Application.Run(newForm) while the game form is running?
lets make a quickie title screen. [working] done and implemented. now the highscore table. sigh.. wait! what about a gameover screen? surely i need one of those!! it will appear for like 3secs or something, after you game over (unless you hit the highscore table, and then it does it for 3secs after you're done with the table.. blarg, i'm just putting it off.
ok well the first thing is, we need to pop up a new form. lets do that. [working] ok, well i can't use Application.Run() to do it. i'll have to set up another loop to last the duration of the highscore table form. [working] nope, that doesn't work either, because i have to still use Application.DoEvents(). luckily i found ShowDialog() and i'm using that. [working]
added a background to the main game. the highscore list (like the main game window) is being sized improperly. i'm sure its due to how we have a different text size scheme than the default, and its not accounting for that. another problem that came up was that if you're holding the button down when the time runs out and the hs list comes up, it skips over the title screen. should be easy to fix. [working]
so changing the 'extra large fonts' in accessibility didn't do anything to help the size changing problem. i just added a Size = new Size(x,y) in FormLoad and its keeping, for now.
so now we need to check the top scores against the score we enter the high score table with. thats going to need me to give the score in to it somehow.. [working] ok i'm giving it the score and percentage. the score is the only thing that makes a difference in placing in the list, but its interesting to note the accuracy too, imo.
i need to make a list of actual data entries to make the comparison and list building easier. [working] ok now we need to load and save the list (building one from scratch if theres no highscore list file), as well as pop up another form (dialog?) that asks for a name. [working]
ok, i just got a filestream and a streamreader up and going. if the file read fails for any reason, an exception catcher grabs it and we just make a new highscore list. now i have to figure out how to parse a line of the highscore.txt file. it's going to look like ten lines of this:
somename 100 50
(name) (score) (accuracy)
if i can grab tokens out of a string.. [looking] awesome. i just have to Split() the string into an array of other strings. that was awesome. all i have to do now is make the popup for the highscore name. [working]
that was a bit of learning on the fly there, but i got it. all done. i suppose i should have the gameover 3sec screen before the highscore, but you know what? screw it. i wanna just be done with this crap. jeez.
| |
| Monday, December 27, 2004 |
| Target Practice update, Managed DirectSound | 
Posted - 12/27/2004 8:43:45 PM | [journal dump]
TARGET PRACTICE
in addition to actually finishing the project up, i want to make a few changes to see if a slightly different control setup appeals to jenn any better. the most important change i want to make is to have the crosshairs be positioned by the move analog if the aim analog is dead-zoned. one of the things jenn has a problem with is operating the two analogs at the same time.
in an effort to help the bullet speed get fixed up - right now its speed is dependant on how far from center the aiming analog is pressed - i say we get a DistanceFromDeadzone() or something and divide each component by that to always have the maximum distance. another way would be to get the angle and compute it manually, but i say this is the easier route. [working]
i've worked in a bool function called Deadzoned() that gives back whether or not an analog stick is near the center position. because of the problem we had before where the face was sliding slowly when you weren't pressing on the stick, we needed to add in that little bit of functionality. i wanted to make a note of it because atm the deadzone is hard-coded to be 1/3 (.333) of the max radius (which happens to be 1.0) [working]
hmm. looks like 1/3radius is too much. lets go with 1/5 instead. [working] 1/8? [working] yeah, that works pretty well. we'll go with 1/8.
now, for some odd reason, the changes i made to the sytem slowed it way down. i honestly don't know why its so much slower, but its going to need to be investigated. we got some kinda speed hit there from something i'm doing differently (wrong?) and its gonna need to be fixed. [researching]
wow! the Unplugged() function is killing the framerate hardcore.. i wonder why its killing it worse now than it was before? i know we were only hitting 30fps or so before with the test - what's different? [looking] not sure if anything's really that different, but its really hitting us hard to test for the unplugged situation. i knew it before though, that it would be a little tough on the system. oh well.
another thing to make note of is that the fps isn't actually the real fps, its the logic count. every time the logic portion fires, it updates the fps, not every time the thing is drawn. i could probably add an event handler for Paint so that we can properly report the fps. [working] now that the fps is being updated in Paint, it doesn't update unless something's happening. oh well. at least its more accurate as an fps tracker now.
anyways, lets try to have the move analog direct the crosshairs if the aim analog is deadzoned. [working] there we go. i also made it so you have to release the buttons before you can fire again. i was having a bit of a problem with when the target lands right on you and you shoot it, you'd usually shoot another bullet right away, throwing your accuracy off unfairly.
the only Real Important Things (tm) left to do now are the highscore table and title screen.
PLAYING SOUNDS
i want to play a single sound. maybe have a sound loader or something, whatever. just load and play a sound. not hard. [researching]
actually playing small sounds looks real simple. i'm not sure what the limit to the length should be for a static secondary sound buffer.. when should i be trying to stream them, i wonder.. i haven't figured out how to play mp3s, but i did see an audio/video player in the dx9 sample browser for c# under miscellaneous. gotta remember that.
wow! playing mp3s is going to be fscking simple! Ms.DX.AudioVideoPlayback has what i need. i use the class Ms.DX.AVPlayback.Audio - its constructor takes the mp3, and use its Play(), Pause() and Stop() functions to do those things. they added an event handler to the Ending event that Stop()s and then re-Play()s it to force endless looping. damn easy.
lets try to add the shoot noise to the target practice sample. [working] well the only thing i had to figure out on my own was that if you're in the middle of playing the sample still, you have to SetCurrentPosition() back to 0 instead of Stop()ping.. it won't let you Stop() on a dime like i want. oh well, i got it going. now its time to add an explosion sound. [working]
so simple. unoccasionally, a sound will miss on its Play() and no sound happens. but i'm happy with the results for now.
| |
| Tuesday, December 21, 2004 |
| Dual Analog - Target Practice 2D final | |
Posted - 12/21/2004 8:08:39 AM | [journal dump]
i'm thinking that this app might best be served with a status bar to track everything. it would remove obstruction from the client area, at the very least. i guess it depends on how hard it's going to be to use.
time to add the countdown timer. [working] hmm. adding the statusbar and setting up panels on it was easy, but getting at the panels isn't. i'm not sure how to deal with Collections yet. [working] looked at InitComponents.. guess i can just ask for them by name, and not as a part of statusBar.Panels.somethingsomethingsomething.. yay! [working]
ok it won't let me use the panels like i want to. it looks like msdn boxes and then unboxes stuff that's MarshalByRef (whatever the hell that means). let's try that. [working] ... wtf? time to hit the chat. [working] nevermind the chat. i realized i should have been dealing with TimeSpans anyways and for some reason it let me use them fine. whatever, i have a working timer.
[working] now i have an accuracy tracker. i need to do something with the timer now, though. i'm going to have to have a game-over state and stuff to deal with. god, i really need to clean up my code..
ok wtf? you can get a negative for your hit/miss%. oops, i think i forgot to use shotsFired in the equation.. i also have to fix it so that the face can't get under the statusbar. [working] both fixed. now we could maybe throw up a MessageBox and reset everything after the time hits 0. [working]
just re-ordered Main's while(created) so that there's a game state switch. now we add the messagebox. [working] there. now it gives a gameover message and resets everything. i want to have some of the vars update their statusbar entry by making them properties. that will simplify some of the program. [working] yeah, that was cool. i had to be a little careful of how i was setting stuff because i was using values from other properties, and we want to be sure things are getting done in order.
anyways, the game is done enough for me. there's a zip for the game here. i'd tell you to enjoy it, but.. it sucks. i'll probably add a high-score table sometime.
[edit: i forgot to take into account the statusBar when the bullet hits the edge of the playfield - the ClientRectangle includes the statusBar, and the bullets have to go further off the visible area than they should because of it. easy to fix, maybe later]
| |
| Monday, December 20, 2004 |
| Dual Analog Target Practice | |
Posted - 12/20/2004 3:22:54 AM | 
| |
| Dual Analog Target Practice Screenshot | |
Posted - 12/20/2004 2:00:19 AM | 
| |
| Sunday, December 19, 2004 |
| Dual Analog - Target Practice | |
Posted - 12/19/2004 7:43:54 PM | [journal dump]
well, i thought i'd add noise to the game, but it turns out winforms doesn't do sounds. i'm not going to learn directsound unless its INCREDIBLY easy to do - i guess we'll see later. i even made a shooty noise and everything >:(
now we do the collision bit. [working] well that was easy. the shot forgets to disappear when it hits the target, but its cool that way because you can see where you hit it. now we can move on to the scoring part. [working] ok, now theres a score tracker. i want to add a hit/miss ratio tracker too, just for fun.
i notice that sometimes you can see things move a little choppy and i realize that i could still be doing things a little better. if instead of doing two calls to change .Top and .Left, i could set the Position to a new Position(x,y); this would do both ops at once and eliminate the choppy. [working]
ok, the choppy is fixed. i also added the movement of the target when you hit it - still need to randomize its spawn position. i also dead-zoned the face, but not the crosshair. is it even necessary? if you're not aiming, its your own silly fault. perhaps it wouldn't hurt, though..
now i want to finish up the game with a main timer that counts down from 1:00 min. after that the game's main bit is done. i can add a frontend and highscore table and all that stuff later. the game's gotta get done.
| |
| Dual Analog - Target Practice | |
Posted - 12/19/2004 3:59:47 PM | [journal dump]
i want to do the timing now. [working] i had to go look it up. apparently you go with timeNow = DateTime.Now; and find the elapsed time with timeElapsed = (timeNow - timeLast).TotalSeconds; [working] ok, i added bullet support. press any button and the bullet fires. i can add a noise now to that if i wanna. lets go back to the list we made up last time. [working]
todo list:
- limit face motion radially, not with cartesian (like crosshairs)
x add timing
- finish actual game >> elaborate <<
- sound effects
x compare atan2-sin-cos vs sqrt methods
- dead-zone the analog sticks
i'm getting closer to the game part being done. getting the bullet going was one step. i wrote it all as commented code (the comments actually stayed in the code, i just coded around them) there's nothing being doen with any collision between the bullet and the target yet because the collision detection routine isn't written yet - it just returns false all the time.
i changed back to the sqrt method because i wanted to use some of the stuff we got out of it. it came in handy when i wanted to direct the bullet. i'm going to need to go back through the code and make it more readable. its a mess.
as i played with it a bit more, i realized that the bullet is coming from the upper left of the face. that's not right. we need to offset it a little to make it come from the middle of the face. thats gonna be easy.
todo list:
- limit face motion radially, not with cartesian (like crosshairs)
- finish actual game (need to specify more)
- sound effects
- dead-zone the analog sticks
- refactor the code for readability
- make bullet come out of middle of face instead of top left corner
i'm gonna fix the bullet start loc first. [working] fixed. i wasn't initing the bullet's sprite - and then i did, but i did it wrong. so that was a bit of fun. i should eventually introduce a vector class soon to make my job even easier. lets look at what we need for a finished game.
we need to have the bullet collide with the target. when that happens, the score goes up by one point. we might have a sound effect play there, like a crash or explosion or something. the target will be moved somewhere randomly on the window, and you have to shoot it again. we'll have a 1:00 min timer counting down to zero and when it gets to zero, its game over. we need to display the score and the timer to the player as they play.
i'll do the collision test routine next.
| |
| Friday, December 17, 2004 |
| Dual Analog: Target Practice | |
Posted - 12/17/2004 10:10:01 PM | [journal dump]
now i know when the joystick is plugged in. again, its not something i can be sure of for more than one, but its ok for this demo for now. now its time to try to get some info out of the joystick and do something with it.
i should probably do things just as the di sample does, and call a GetData() function that loads up a state object every pass through Main. lets add it in. [working]
first, lets change CheckJoystick() to be called JoystickUnplugged() and have it return a bool. then we'll deal with what to do about it in Main. [working] ok, now we do GetData(). [working] ok, it compiles clean. now lets use some of the data. [working] lets set up the axes to go to 1000 like they did in the sample, just for the hell of it. [working] now we'll move the smiley face with state.X and .Y. [working] i have to take a braek for a min. i gotta remember to add a 'got data' thinger to check in the main loop. [away]
got the smiley face moving with the left analog. now we attach the right analog's functionality to the crosshair. the z axis is the right analog's x, and the rz axis is the right analog's y. [working] yup, done. i want to limit the crosshair to only move around in a circle about the smiley. i'll have to check the distance away and force it to the radius i choose. [working]
ok wierd. it limits it to a circle as i wanted it to, but now its doing some wierd stuff.. its skipping all over the place at angles that look like they're right next to one another. i need to rethink this.
suppose the current analog position is further from center than our maxRadius. we just want the angle, right? lets try that instead. [working] well it didn't work any better, but at least i got it to stop being dumb. switch the signs and Sin/Cos positions and i got it. i wonder if i saved any cycles by switching from a one sqrt to an atan2/sin/cos solution.. (doubt it)
i have a choice of things to do right now. i can do the bullet stuff and get a game actually up and running, or i can clean up how i'm doing things a bit and get rid of some of the artifacts we're getting from doing consecutive .Top/.Left changes. i can also fix the centering error - when you let go of the stick, sometimes it doesn't center at 0,0. thats easy to fix, too.
jenn says the jumpiness should be fixed first, so lets do that. the problem is caused by the fact that we're changing .Top and .Left more than once in a single loop, and so the computer has to move it real quick. what we need to do is store the location of the objects seperate from their pictures and then apply the locations after we're done our logic, during the update phase of the main loop. lets seperate out the smiley first. [working]
i did alot of seperating there. anyways, the smiley doesn't jig when you try to push him out of the window now. i need to remember to add a shooty noise when you fire the bullet.. ^_^ the code is cleaner and a bit easier to read. i changed the name of the demo to reflect what its going to be used for: Target Practice.
something else that needs to be done is the game timing, to make it run the same speed, no matter the workload. probably going to need a double buffer going on too - but that might be more than is needed. lets update the crosshair like we did the smiley face. [working] all done. the last thing i want to mention before i take off is that i'm going to want to limit the speed that the face moves in - its not circular like the crosshair is set up to be. i'll fix that too.
so lets make a todo list.
- limit face motion radially, not with cartesian (like crosshairs)
- add timing
- finish actual game >> elaborate <<
- sound effects
- compare atan2-sin-cos vs sqrt methods
- dead-zone the analog sticks
we'll get a start on these things next time. [gone]
| |
| Thursday, December 16, 2004 |
| Dual Analog, and other random stuff | |
Posted - 12/16/2004 12:37:29 AM | [journal dump]
IRC LORD
i just realized that irc would be an awesome spot to do up a multi-player LORD game. i've always wanted to do one, and this way you could make one where people could play in real-time. err.. isn't that what a MUD is? oops ;)
TODDLER PICK GAME
caleb plays a game at fisher-price.com where you just have to put the mouse on a picture and click on it. you hear the sound of an animal, and they pop two animals on the screen and you pick the animal that makes that sound.
i can make a game like that super easy, no doubt about it. however, there's some things that i'm going to need to know how to do - that i don't know. if i were to use simple PictureBox objects, i don't know how to extract individual pixel information, and i don't know how to tell a PictureBox to not draw a certain color - for drawing sprites.
DUAL ANALOG
so now what we want to do is add, into Main, some routines that will check for a joystick disconnect and try to get it back. as it sits, the application drops if there's no joystick connected at the start of the program. what i'm going to do now is add stuff from GetData() in the sample right into Main and affect the drawing of the disconnect PictureBox. [working]
well, shit. i don't get this. no matter how i code this i can't seem to get that damned disconnect symbol to appear. every way that seems correct doesn't do it. its close - if you minimize and then restore it, it shows up. i thought maybe Refresh() would help, but doing it on mainForm doesn't work, nor does it work if i call it for the disconnectedPictureBox. i'm not sure what to do about this. invalidate the window? ... [working]
i think its a problem that we're trying to Hide() right after the call to Acquire() because if we don't get the joystick, i'm assuming we fire an exception which gets caught. but i don't really know what happens if it doesn't acquire it right away. [researching] i put a MessageBox in the exception handler for Acquire(), and it didn't fire when i unplugged the joy. so how do we know when we get the joystick back? >:( [working]
ok, that's whacked. if you unplug the joystick, its not catching any exceptions - none are being thrown! its not until you switch away from the app taht it realizes something's not right. hmm. so we can't tell right away that the joystick isn't hooked in :( maybe we need to continually enumerate and count? lets try that. [working] yeah, that did it. it doesn't tell us which joystick has been unplugged, though - perhaps we need to unacquire and re-acquire in the case where we have more than one joystick going. that takes us back to what i was saying the other day. if we enumerated four joysticks and then unplugged them and plugged them back in in the opposite order and tried to re-enumerate, what would happen?
anyways, for this simple sample, the method works. i'm not sure if its pretty or not, it might be slow as molasses on a cold kanadia-an day, i'm not sure. we'll find out when we start getting some timing going in here. [working]
ok, i switched around a little bit of stuff. for one, i've taken InitDirectDraw right out of the main loop. its being called by CheckJoystick. CheckJoystick enumerates all attached game devices and gets a count; if the count is less than 1, then there's a problem. in the call to InitDirectDraw, i added a != null test at the start; if we've already got a device created, then we don't need to get another.
thinking on that last bit, though.. what if i attached a different game device? shouldn't i go through again and get the new joystick? in a multi-joystick situation, we'd want to test each 'found' joystick in the enumeration against the ones we think we have, and unacquire the ones we don't have.. in this situation though, we have two ps2 adapters that will both work exactly the same. we don't need to unacquire and wait for the new joystick to be hooked in, because we know we're going to be getting the same device type back. at least i guess this shows that i'm thinking... [gone]
| |
| Monday, December 13, 2004 |
| Dual Analog continued | |
Posted - 12/13/2004 7:14:30 AM | [journal dump]
i need to remind myself again about what my needs are. i was going to try to imagine a full wrapper for any need i might have in the future - but why would i do that when i don't even have this done yet? only when i have it done can i know what more i'm going to need.
right now, we're going to need to add a function that will let us check to see if the joystick is still connected. we're going to repeatedly call it in the main loop. thats all we care about testing for now. [away]
i'm gonna research that right now. [working] it looks like the first try/catch block in GetData from the joystick sample has everything we need. in fact, we could probably get away with .. wait, no. i want to move a bunch of the junk (or all of it) from InitDirectInput to the spot where we 'test for a valid device', because i think that if we don't have a valid device, we might need to do all of that again to get the joystick back. but then, i'm not sure. i should probably stick to what's there and figure out where it's lacking and what needs to be done to get my desired result.
from what i see, the sample tries to poll data out of the joystick. if it can't, an exception occurs and it tries to figure out what to do about them. if NotAcquiredException or InputLostException is the case, it tries to Acquire() the josytick again.
it looks like the sample doesn't deal with the joystick if it is plugged in after the sample starts. let's see what we get if we stress the sample. [testing] ok, if the jostick isn't plugged in when we start the sample, InitDirectDraw bombs and we automatically Close() - ending the program. [testing] if you unplug the joystick while the sample runs, it catches the exception thrown and just keeps on trying to re-Acquire() the joystick until it gets it back.
since the sample just drops out if there's no joystick hooked up, we need to deal with that - because we want to run the program regardless of whether a joystick is hooked or not. we're probably going to have to move some stuff out of InitDirectDraw and into GetData (or wherever we're going to do the stuff in it) at the start, where we test for the joystick being null. i honestly can't see how that could ever be true.. if we lost the joystick for whatever reason, we should still be pointing at a device, right? even if the device is disconnected, it isn't going to be null... or is it? i'll have to bear this in mind. for now we can only have a properly working app if the joystick is hooked at the start.
i'm going to compile the sample seperately and see what happens when we take out the null== line from GetData(). [working] as i expected, the null== line at the start of GetData() is useless. if you get to that function, the app didn't drop out, and has to have a valid joystick; whether or not it lost it at some point is another story.
my next question is how does the di manager handle hooking up more than one joystick while a program is running? suppose we were expecting to have two. if the app was allowed to start if no joysticks were present, and checked for new joys being connected.. we have two different joysticks, one is an original ps2 dual shock, and the other is a microcon that fits into jenn's hands better than the original did. suppose when we had them hooked up and started the app that the original joy was player1 and her joy was player2. now imagine we unhook the joysticks and start the app up again. the input manager is going to be forced to watch for new josyticks being hooked into the system. what happens when you hook up the joysticks in different orders, or to different usb ports in the same order? these questions, and more, will have to be answered in another episode. for now, sleepy time. [gone]
| |
| Sunday, December 12, 2004 |
| Scribbler Dump | |
Posted - 12/12/2004 1:03:02 AM | I have this scribbler (it's actually a graph paper scribbler) and I used it to help figure out what I was going to need from my 'Ultimate Action-Adventure'. I'd been into some games at the time and it was all fresh in my mind, so it seemed like a good idea. Below is a dump of my findings.
[edit: Yeah, it's alot. Some of it doesn't seem finished either - not to mention there isn't much of a flow going on there. I consider it just an extension to my txt journal, only on paper.. and without any real coherent thoughts.]
BAD NOTES on DIABLO II
----------------------
- Stamina Bar is annoying
- Monsters that are walking away from you cannot be hit [edit: by melee attacks]
- not enough variety in monster AI
- hit/miss should not be rolled
- not enough storage space in stash [edit: even in Expansion]
- should show damage values being scored (amount of damage)
- can't share items between different characters (SP) [edit: doing it on battle.net is a pain too]
- should be able to have two or more custom characters in one one-player game
- point-and-click interface takes away immediate response
- too much standing face-to-face and exchanging blows [edit: for melee characters]
- can't take control of helper characters
- can't issue commands to helper (defend me, fight strongest)
- can't have more than one helper (except necro druid)
- should be able to see total ^ chance of finding items/mag items
- things get hidden behind walls & houses
- should be able to put things in open treasure chests (why?)
- monsters shuld want to kill each other
- should be able to gain exp from re-killing revived monsters
- can't remove gems that have been socketed <-(yes you can!)
- traps should hurt monsters nearby
- skills should iprove through use
- can't rotate items to fit them better in backpack
- should be able to check the time somehow without leaving game [edit: can on battle.net]
- no variation on weapons -> all melee weapons act the same, all missile weapons act the same
- no way to see where monsters or treasures are on maps
BAD NOTES ON SWORD OF MANA
--------------------------
- ring menus aren't very easy to find things in
- only one weapon (of each type) and armor (of each type) at a time in inventory
- monsters drop items once per group, and item drop chance is very low
- can't have any more than one effect on a weapon/armor
- level up system doesn't allow you to know what next classes are, or their bonuses
- no indication of how many hitpoints monsters have left
- hit/miss shouldn't be because of roll, if sowrd passes through monster, you should hit 100% of the time
- tempering equipment is too complicated: seeds -> fruit/veggie -> temper
- forging new weapons is also painful, you lose the bonuses you got from tempering earlier
- treasures dropped by monsters disappear after a set time
- if you don't beat all of the monsters on a screen, you don't get a treasure
- can only save at statues
- can't lay right away; you have to go through ~5min of reading first
- if your main char dies, the helper can't bring him/her back to life -> game over
- no map
- helper AI worries more about returning to you than defending him/herself -> dies more often than they should
- no multiplayer [edit: biggest problem with the game!]
- can't hit more than one enemy at a time -> if you focus on one and other steps over it, you might start hitting the new one (makes it difficult to eliminate monster you were focused on)
- NPC AI selection too limited
BAD NOTES on FINAL FANTASY: CRYSTAL CHRONICLES
----------------------------------------------
- item list too long; doesn't auto-sort
- weapons/armor difficult to forge; can't sell or trade completed forgings
- letter sending is annoying
- no health bar over enemies (except boss)
- no indication of amount of damage being dealt
- no CPU AI to help
- once cmd slot list gets big, it takes a while to get to items
- beating monsters is pointless unless you're looking for items
- if you don't have gameboys, you can't play MP
- enemy weakness/4th gba screen not available to 1/2 player games
- should be able to remove attack/defend from action slot list
- stun length too long
- can't access menu (items/equip/etc) from world map
- can only beat 3 new stages before monsters get stronger (must choose only 3 stages)
- too few levels
- should be able to control more than one char
- carrying things slows you down
- shields only for clavats
- can't buy or find completed weap/armor
- can only use one type of weapon
- need gb for map
IDEAL GAME
----------
- looks / feels like Sword of Mana
- plays like Crystal Chronicles
- treasure hunting of Diablo feature
- plays on gba
- up to 4 player MP
GOOD NOTES on SWORD OF MANA
---------------------------
- weapons & magic get stronger through use [edit: unlike diablo, where you just put points in it at level-up]
- damage points shown on hit
- chance for double damage + stun
- weapons all act different
- combos do 1.5x and then 2x damage [edit: on weapons that let you do combos]
GOOD NOTES on CRYSTAL CHRONICLES
--------------------------------
- combining attacks/magic for more power
- method used for selecting & use of commands
GOOD NOTES on DIABLO II
-----------------------
- random map generation
- skill trees [edit: uniqueness of character classes]
- variety of items
HORSEBACK RIDING
----------------
- riding horses to speed travel
- control horse's momentum -> not turn-on-a-dime
- should be able to attack as normal
- new horse-only weapons/armor -> outfit horse
- horse does trample damage against smaler enemies
- buy horses at ranches
- catch wild horses -> probably stronger/faster than ranched
- breed horses -> like chocobo breading in ff7
- horses take damage from monsters
- differences in horses: attack str/def/speed/(stamina?)
- horses level up
| |
| Dual Analog continued | |
Posted - 12/12/2004 12:09:47 AM | [journal dump]
i'm not actually going to do any work, i'm just going to drop some reminders in here for now. i'm going to need to read and highlight important parts of the joystick sample in order to progress. i'm also going to eventually have to add timing support to make the avatar move around at a consistant rate. [away]
ok, me and jenn went and did some more work on the project. what i wanted to do was to do all of the checking for the joysticks and get that out of the way. i wasn't really sure what i was doing, so i just sorta stabbed at it and copied what was in the sample. we ended up forgetting to call the initDirectDraw command in Main, and tried to use a nonexistant command (in our program) called UpdateControls - which was used in the sample but wasn't needed in ours.
after we got all the errors out, we tested it. with no joystick plugged in, it popped up an error message as we expected it to (and jenn was happy!). when we plugged in the joystick, we didn't get an error message - again, just as we expected. something went right!
so the next thing i would like to do is to add an active check to make sure our joystick is still hooked up, in the main loop. something like CheckForJoystick and it will say true (its still hooked up) or false (its not there now) and we'll turn the disconnected sticker on and off. as we plug in and unplug the joystick (poor computer!) it will show up right in the program.
after that, we can start getting information out of the joystick and start moving the avatar and the crosshair pictures around. whee! [gone] [edit: added some descriptive comments to the source code. should probably be doing that as we go along so that we don't forget... ]
| |
| Dual Analog 2D 3rd Person Shooter | |
Posted - 12/12/2004 12:08:26 AM | [journal dump]
i want to test out how jenn does with a setup like this. we'll connect the left analog to moving the player around, and the right analog to a targeting cursor. when you use R1 you shoot a bullet. if the bullet hits a target, you get a point. we'll give her like one minute or something to hit as many targets as possible. the target will move every time its hit.
the first thing we need to do is drop an avatar and target cursor image in. let's do that now. [working] i also dropped the target and bullet pictures in. now what i need to do is get the program to look for the joystick(s). if they're not there, the program will have to complain and just sit there and do nothing. (maybe display a disconnected symbol and keep checking?) once it has the joystick, we'll set up the main loop to be non-blocking and then set the crosshair to wherever the right analog is. i'll talk about that when we get there.
first we'll make the program nonblocking so that we can do all this properly. we're also going to need to set things up for timing eventually. [away]
jenn wanted to try to be a bigger part in the project to help her learn about this stuff. i gots no problem with that! what we've done is, i've walked her through what i think we need to do, and had her type in and click on everything that needed to be done.
we went through the journal entry and i explained everything she wasn't sure of as best as we could. we had a little trouble at first because i was rushing her a bit. after we slowed up, we started getting somewhere. we broke the Application.Run() up into a more explicit loop and now we can start adding stuff in where we need to. i also had her add the DirectX and DirectX.DirectInput references to get us just a little closer to our goal.
the next thing we need to do is go over the DirectInput joystick sample and figure out what parts of it we're going to need to use. the most important part right now is getting ahold of the joystick and if we can't, to just keep trying. the stuff that happens while we have the joystick is going to be ignored if we don't have it. what i mean is, if the program is running and there's no joystick plugged in, it won't do anything. its going to keep trying to grab the joystick until one is plugged in. when its plugged in, it will instead check to see if it still has the joystick and if it does, it'll do the other stuff.
i think i'm going to add a joystick unplugged icon so that the program will visually tell us that there's no joystick plugged in. i'll even add that now. [working] hehe that was a little bit of a pain, but i got it. i just stole the pic from the camera program ^_^ we'll just hide it in the main program when we find the joystick, and show it when we can't find the joystick. i'm out [gone]
| |
| Action/Adventure Games | 
Posted - 12/12/2004 12:00:55 AM | I've been long meaning to get around and write down all of my gripes and praises about various games - in a media form that I probably won't lose to the garbage bin by my 2yr old toddler.
I've longed to make 'the perfect action/adventure game' for me and my girlfriend Jenn, and I just haven't gotten past the idea stage yet. Hopefully this will propel me toward a finished product.
My ideal game combines bits from other games, much as most other games do nowadays. I'll start by mentioning the games foremost on the list I intend to 'borrow' ideas from - though there may be others involved. Here they are, in order of importance:
o Diablo series
o Zelda series
o Secret of Mana series
o Crystal Chronicles
o Crystalis
o Chronicles of the Radia War
The first thing you might note is that there's only one PC game there - yes, I prefer a joypad to a mouse and keyboard. In my opinion, if the game requires more than 4 buttons and a dpad or analog for its main gameplay, its too complicated. This goes for any game. I actually might go so far to say that no game should require any more than 2 buttons - but that may be pushing it.
So what's the connection between all of these games? Control scheme is one of the more important points - they all play alike, aside from Diablo. The reason Diablo is at the top, however, is because it has most of the other important points in it, and has performed extremely well in those areas. Let's cut to the chase, now.
I'm now going to run through each game and make note of (noteworthy) points for each. This is going to be a combination of input from myself and Jenn. While I've played each of the games in the list, Jenn has only played Diablo, Zelda, and Crystal Chronicles, and isn't giving into the others.
=========================================================
DIABLO series
-------------
For the most part, I'm going to be talking about Diablo II. I don't think there's anything it didn't improve on, as compared to Diablo I.
++ The Good ++
The biggest thing here is the item collection. It seems obvious to me that this game is nothing more than a treasure-hunting game. I've argued with n00bs left, right, and center that the game is nothing more than an RPG - but do not mistake it: every patch added to the game alters or increases the item database; the rest of the patches are just alterations made to increase item finding effectiveness. I've gone so far as to label this a fishing game. If I ever get an action/adventure game off the ground, item-hunting will be the focus.
Another important issue they tackle is world randomizing. Every new game you start on Battle.net will dynamically create a world for you to explore. Sure, I don't see this as a free-roaming game; each map they create will always connect to the same other maps - just in different layouts. For instance, the Rogue Encampment always leads to the Blood Moor, which always leads to the Cold Plains. Treasure boxes and Monster placement is completely random as well, and that's important.
The item/trading menus are straightforward and intuitive, and thats key to any play experience.
Variety of enemies and environment is also a good part of the game.
I like that the monsters can be special, having special powers and defenses, or increased resistances to certain types of magic. There are even two types of special creatures - the Leader types, which have a series of underlings - and the random pair of Berzerkers/Ghostly/etc type that have double hitpoints, attack scores, or whatever.
Skill Trees are welcome as well - as you level up, you choose which skills you want to learn or improve. Skills give a character an edge against the monsters, by allowing a player to use magic or special big attack to do more damage.
In the Diablo II Expansion, Lord of Destruction, they let you have two sets of weapons equipped, and a hotkey to let you quickly switch between them. The biggest reason I like this is because I often want to have a melee set and a missile set; being able to switch between them is an important feature to me.
Having a safe spot to toss things you want to save for later, the stash, is key to any item-hunting game. In my opinion, the upgraded stash in the expansion still isn't large enough; people still use mules to store their stuff.
Allowing players to personalize the effects on their items, with sockets and gems is cool. I've found many places where a socketed item was more effective than any gold (rare) item i could find at the time.
Gambling for items is a great place to use your (for the most part) useless gold. They have rings and amulets to gamble for too, and that tends to be where my cash goes.
Dying in this game isn't necessarily a horrible thing. In Diablo I, if you died, all of your equipped items fell on the ground, and it was a real bitch to have to pick up each item and then manually re-equip them. Now, you just have to grab your corpse and you're back up and running.
Having "hirelings" and minions is a great addition to the game. Equippable hirelings is even better.
Waypoints are an effective way to jump around the world - you should have some way to get around quickly in any game like this.
The automap wasn't just a good idea, it's an essential tool for any experienced player. Finding my way around a dungeon or in the desert would be a real bitch without a guide.
++ The Bad ++
As Jenn has pointed out, it seems that Blizzard took the easy way out when they decided to make the game more difficult. As you progress through the game, each area has a higher and higher count of monsters that flood rush you; as the monsters get stronger, they're positioned in higher concentrations. At this point, the game becomes a "pull; retreat; kill" repetition that gets boring and can even become frustrating.
In my opinion that isn't quite as bad as the lack of AI in the game. Most monsters simply rush you and melee until they die. The missile monsters get in range and start firing away. The monster healers do what the missile monsters do, as they tend to also be missile monsters. Aside from the bosses, thats pretty much all there is to them.
Another thing is that the item drop rate seems to go down as you progress through the areas. You might get an item 25% of the time in Act I, but in Act IV it seems more like 5%. In order to get better drop rates, you need to go back through the game in the higher difficulty settings. It seems like just another way to increase play-time without doing any work. This subject may need more research, however.
Like many rpg games, Diablo has a hit/miss calculation that can lead to much frustration. If I click on a monster and my avatar runs up to it and swings an axe at it, and the axe sprite collides with the monster sprite, I say that's a hit - 100% of the time. I've been in situations where my character was quite good, and I'd be spending 10sec or more just trying to get a hit on a monster. That's not fun for me.
At a certain point when I had gotten so used to the game, I was ignoring regular magic drops (blue names) and looking only for uncommon (yellow), set (green), and rare (gold) items, and even later, i stopped looking for uncommons as well. Why aren't the items spread out more evenly? If you find a blue item and then a yellow item, I'd like the blue item to stand a chance against the yellow item: give the yellow item 4 things, and the blue item 2 things; but let the blue be more likely to have the upper half of the range and the yellow the lower half of the range.
Having your items wear out is a useless part of the game. In the middle of a group fight, I see the "low durability" icon pop up and I swear, because I don't need my weapon to break when I'm stuck in a crowd. Durability isn't something I consider fun in any way.
Stamina is another annoying addition. I appreciate the run/walk toggle - though I generally keep it on run - but it seems that vitality just didn't affect enough stuff, so they added it in. Waste of time, not very fun.
Not letting me have a battle plan for my minions and other NPCs in the party is a real let-down. I should be able to tell my helpers to protect me or to go after the strongest monsters.
The hitpoints a monster had were represented by a life bar that popped up at the top of the screen. As you connected with hits, the life bar would drop relative to how hurt it was. I'd much rather not see how much health a monster has, and just see how much damage I'm doing to it as a number or whatever.
This game might have been the perfect game to me if they had just allowed single computer multiplayer. Without it, Jenn and I can't play together without spending ALOT of cash (and that ain't gonna be happening anytime soon)
They had weather effects and day/night cycles, but they were nothing more than environmental effects - there was no effect on gameplay at all. This could have been a bigger deal.
ZELDA series
------------
There's quite a variety in the games in this series - but most of them follow the same formula. I'm actually going to focus my attention on the first Gameboy Zelda, Link's Awakening; it's my favorite one.
++ The Good ++
The control scheme is simple, familiar, and very polished. Many people can pick up this game and play it without the need for a manual.
There isn't any confusion in the menus; there's only one inventory screen, and equipping stuff is as simple as highlighting it and pressing the button you want to use it with.
The monsters in these games tend to have unique personalities. Fighting Octoroks is a different experience entirely from fighting Tektites.
In Ocarina of Time, they worked the day/night cycle in and made important differences between the two. Every zone in the game had different things going on at different times of the day, for instance, at the start of the game, skeletons would come out of the ground at nighttime and wouldn't during the day.
In Four Swords, the multiplayer was really fun. The game was designed with this in mind.
++ The Bad ++
The game is basically a puzzle game. I like puzzles, but once you've solved them, there's really no reason to ever play it again aside from nostalgia.
Some monsters required you to kill them with specific items. If you didn't have the item, you weren't able to kill them. Not real great.
You couldn't roam new areas of land without a specific item. The item usually can't be picked up until you solve the next puzzle, so forget about travelling to the harder levels until you've gotten past everything before it.
Killing monsters is pointless unless you're looking for cash or item refills. Getting better items only happens when you solve the puzzles, and you have to solve them in order.
In Four Swords, in Jenn's opinion, forcing the players to have to do formations to solve the puzzles wasn't cool. We agree that they should have focused on getting used to the controls more at first, and leave the formations for later levels.
SECRET OF MANA series
---------------------
Though each game is different, there are many things that are consistant throughout the series. Some of these things are good, some are rotten.
++ The Good ++
The diversity of magics and weaponry is the name of the game here. Allowing your characters to get better at a weapon or magic class through practice is a real big thing for me. Instead of just putting points into something, you have to work at it to get it better.
Allowing the player to have other members in the party that they can switch to is pretty cool. That they're unique and have to be played differently is also cool. That more than one person can play at the same time really sealed the deal.
Some of the weapons in Sword of Mana let you do 3-hit combos that did more damage with each hit. If you hit your attack button at the right time, you'd follow up with a hit that did 1.5x and 2x damage. That was cool.
Seeing the amount of damage you've done as a number was always informative. In any number-based game, more numerical information is better. This might be a topic worthy of more research, though.
++ The Bad ++
You have to wait until a certain point in the story to get a new type of weapon. You should be able to pick any weapon up at any time.
The monsters weren't really very much different from one another (sprite sets aside). A little more intelligence please!
Hit/Miss is always crap in my books. If my sword hit the Rabite, I'd better be doing some goddamn damage. Seeing MISS pop up instead of a damage count sucked the big one.
Finding items in this game isn't fun at all. In the first few games, you'd have to kill alot of monsters to find the best items. Eventually though, SquareEnix decided that wasn't hard enough. They came up with a new system where you had to gather materials to forge weapons and armor with, and make plants from seeds that you'd use to improve their stats. The materials for the best items in the game were nearly impossible to come by, and you'd need the materials to improve the stats along with the plants. The process is annoying at best, and if you put any amount of time into looking for the materials, you're likely to improve your character to the point where you don't even need the best stuff anyways, to beat the game.
You were never allowed to hit more than one monster in an attack. If two monsters were stacked one on top of the other, you'd only hit one per attack and the others could nail you as you recovered from the attack.
As you levelled your characters weapons and magic, the NPC you were paired with often take matters into their own hands and steal your kills. You're able to tell them to 'Stay Away' but sometimes they're forced into fights and will attack.
NPCs get stuck very easily too. If you run around behind a group of monsters, the NPC won't try to cut a path through to you, they'll just try to walk or run to where you are. The monsters that get in their way will relentlessly beat on them and often will kill them. I usually just leave them to die - they're just going to get in the way of my levelling anyways.
No multiplayer in Sword of Mana at all. That was the biggest disappointment of the game.
CRYSTAL CHRONICLES
------------------
There were alot of new things done in this game, but also alot of things were done really badly.
++ The Good ++
Letting the player hook up the gameboys to the system and look down to see a map wasn't just cool, it was damned useful.
Casting spells was really easy to do - you just hold in the action button and position a cursor that would move along the ground, and you put it under a monster and released the button to cast.
Being able to quick select between a list of actions was a cool way of doing things. You only had 4 buttons to use on the gameboy anyways, so they had to come up with a way to allow for more than 4 things to do - and it works pretty well.
The simultaneous multiplayer was the coolest part of the game.
++ The Bad ++
They set up the multiplayer to force you to use gameboys, so that forces you to have a bunch of them if you want to play.
They decided to force players to work together to get through a multiplayer game in many ways. Having the maps only show monster locations or only the treasures makes you have to tell the group about what is where, or they move around blindly.
Someone needs to carry the chalice around, and that was irritating. You had to keep in mind that you were stuck in the chalice's safety radius, and that was very limiting.
The item creation part of the game was very boring - much like what SquareEnix did with the later Mana games. In this, however, you have to have a design for whatever you're looking to create - without it, you can't create the item. Once you have the design, you need to find the materials by killing monsters.
Killing monsters is only useful if you're looking for items or gil.
The ring command system worked ok until you had too many things in the ring. Suppose you have 8 commands on your ring and you're looking for Heal, chances are you're going to overshoot it when you're spinning the ring. It's also very inconvenient when you need to switch between your attack spells quickly, chances are you aren't going to remember what order the things are in your ring.
CRYSTALIS
---------
++ The Good ++
Clean inventory system.
The game was like Zelda1 on crack to me. You were able to level up your character and choose between different weapons. You also had a series of spells to cast too, which was a new thing in an action/adventure.
Though there was a bit of hand-holding in the game, they let you go to a bunch of areas before you were actually able to progress through them to make you feel like you were allowed to roam a bit.
++ The Bad ++
Your attack range was terrible. If you attacked in any one direction, you'd stab outward from yourself, and only attack on the x or y axis. A sweeping motion is better for these games.
CHRONICLES OF THE RADIA WAR
---------------------------
++ The Good ++
As you progressed through the game, you picked up NPCs that would fight along with you. You were allowed to tell each one a general command in battle - how you wanted them to fight.
++ The Bad ++
Your NPC helpers were dumb as doorposts. Often they'd target a monster in a group and get surrounded - and the monsters would beat the crap out of them.
=========================================================
Before I part, I want to mention some random things I felt might improve on any of these games.
Horses and Mules - Riding Horses or Mules would increase the speed of the character and allow better travelling. If a game has large zones or is completely free-roaming, you're going to want to let the player get around the world quickly and efficiently. If it were a Mule, you could also have a moving Stash of sorts - and it would explain away the inconsistency of Diablo's stash. Having Horses and Mules would also open up the possiblity for a breeding side-game.
[edit: I'm not sure if I ever really completely finished this up, I only worked on it for 3 hours or so over two days. I'll probably get back to this stuff again.]
| |
Page: 1 2 »»
All times are ET (US) |
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | | | | 14 | | 16 | | 18 | | | | 22 | 23 | 24 | 25 | 26 | | | 29 | | 31 | |
OPTIONS
Track this Journal
ARCHIVES
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
June, 2006
May, 2006
March, 2006
October, 2005
September, 2005
August, 2005
July, 2005
June, 2005
May, 2005
January, 2005
December, 2004
September, 2004
|
