  mdx.directplay | 
Posted - 6/25/2006 4:07:22 PM | man, the icon list for these posts sucks pretty bad.
i just did the two chapters for peer-to-peer and client-server networking with directplay, out of mdx9 kickstart and did the examples. it was cool to see something working. i got interested in it because i had been playing quite a bit of new super mario bros (versus mode) and was a little sad that i couldn't play against anyone else. only two people i know have a ds (one of them left for the island for a couple of months) and it doesn't do wifi (even though i don't have it) so i'm left with a very limited play base. i was thinking about building a version myself, for private play, of course.. and so i went to my mdx9 book and did some. seems i forgot how aggressive nintendo is about things like that - i'm going to have to drop this idea.
i did get to learn a little bit about it, though. its easy as heck to get basic stuff up and running. knowing what to do with the two models in order to get a successfully working game going is another matter entirely. client-server at its simplest is straightforward, i've had plenty of time to think about how i'd do stuff with it. i've never really thought about any issues with peer-peer though, because i never thought of it as something i'd ever use. oh wells.
figured i'd drop a line about that much. until next time..
[edit: wtf?? apparently dx9 directplay is now depreciated! i dropped a line in #mdxinfo on afternet.org and i guess people've dropped back to sockets. looks like i'm gonna need a book or reference to get things up and running again.]
[edit: this post is a good thing for me to bookmark. done.]
| |
| rediscovery | 
Posted - 6/21/2006 12:51:32 PM | it seems i may have discovered one of the biggest flaws i've got in my programming brain-chemistry. i, like many others, like to be able to have something palpable as i work along with a project. i code something i can see right away, and then proceed to add to it and change it until its closer to what i want it to be. code, compile, run. code, compile, run. and so on. sometimes you have to break apart what you had so that you can extend it more easily - hopefully there's no visual change, other times its enjoyable new additions. pretty obvious stuff, nothing bad there. so what's my problem?
i'm too focused on pretties. i code something and right away, as i look at it, i'm wondering how to make it look better. forget about the code, i mean visual aesthetics - what many people would want to leave until the machine itself is in a decent state, i tackle long before i should. i've been moored because i couldn't figure out whether i should allow for 8 directions or just 4. i've been stumped wondering about how i'd do graphic X with api Y. why can't mario be an unanimated solid-colored rectangle? as i code, it feels unacceptable to have to look at that when i can have something a little more mature.
programmer art exists because that aspect isn't important when you're doing your back-end. it'd be nice, i suppose, to have an artist churn out graphics that you can use as you build - but i'd say that was a rarity. i get too excited about how its gonna look, WAY too early. making animated gif mockups took longer than it should have because i got too distracted about making them look good. i spent 2 hours last night creating an animated coin box gif. was it because i had trouble finding the graphics to rip? no. i took 2 hours to figure out how to create a parabola function out of known roots and max. i wanted the coin path to be pretty. 2 hours lost, for nothing.
after i got that in my head today at work, seperating the logic from the graphics THE OTHER WAY seemed to make more sense. until now i've been writing logic that included graphics work to update animations, as an example. why can't the graphics module do that work on its own? of course it can. sure, that means that the graphics objects will have to have their own state information - but WHO CARES. maybe i'm still stuck in the days of DOS, where you had very limited memory constraints and had to share as much info as you could. saving memory is still an issue today, but for simple things like 2d sprite/tilemap games - you're pushing your luck if you say you've gotta worry about things like that.
i feel renewed.
| |
|
| S | M | T | W | T | F | S | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | | 22 | 23 | 24 | | 26 | 27 | 28 | 29 | 30 | |
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
|
