Viable to port tecmo superbowl to Python/SDL?

[NateNT321]

Hi guys - long time lurker sometimes poster.

I'm a software engineer who loves tecmo and all you've done with it.

For a long time now I've wanted to try to write a modular Tecmo Superbowl engine in python/sdl using pygame.

I noticed in some other threads that there is a lot of research done looking at assembly/machine code and deriving algorithms of how the game works.

I wanted to ask some of the experts out there that, before I start digging into all the wonderful documentation, do you feel it is a viable place to start to understand the AI, for example?

My biggest concern in this project is emulating the Tecmo feel ... shouldn't be (too) hard to write an engine to do 2d football but if it doesn't play like Tecmo what's the point? One of my goals with this project would be to make the game play tweak-able by anyone with scripting knowledge but the starting point should be to get as close to the original as possible.

Any thoughts/comments? Is this a pie in the sky and should I take a different approach?

Thanks!

[TecmoTurd]

I have always believed that if we had all the rules and original logic laid out, we could recreate tecmo in a newer programming language. Problem is, we don't have a jstout to be a full-time resource dedicated to the project to find out all the original logic...

[TechMobile]

hey Nate, hit me up on aim sometime. we need to talk.

go Pack!

[TecmoTurd]

Count me in if you need anything, I'm a programmer as well...

[TechMobile]

Count me in if you need anything, I'm a programmer as well...

awesome turd

[bruddog]

To get the true tecmo feel it would probably be much easier to to a ram hack of an emulator. Then again maybe not.

The key would be to have the general game physics be similar so that it feels like tecmo.

[TecmoTurd]

I think doing a RAM hack is a decent idea, but to make the game modular and editable in an infinite sort of way, ti should be ported to a new programming language...something open source that could be worked on by anyone.

That being said, I know that it's a HUGE project and likely a pipe dream, but just the same I'd love if it happene, and would help in any way I can...

[bruddog]

I'm talking about hacking nestopia to make it tecmo centric. In that sense it can be open source.

Basically like what tsb ultra was doing.

[TechMobile]

emulator hack vs rewrite/port

of course there is good/bad to both approaches.

emulator hacks like core_dump's with VirtuaNES for TSB Ultra did/does have potential. initially, i started down the same path myself, but eventually realized the many limitations. both immediate limitations and future ones as well. although i do believe that an emulator hack is definitely a more powerful approach than hacking the ROM.

emulator hack

advantage(s): game engine is already built and can be utilized mostly AS IS (despite some of the engines known flaws) ability to easily implement things like 2 point conversions, switching P1/P2 end of each quarter, etc. etc. etc. because all you need to use is the ENGINE during actual gameplay. everthing else can easily be changed in game between plays. (not to over simplify things, but to accomplish most of these types of things, think of it like utilizing multiple saved game states over and over throughout the entire game)

disadvantage(s): peer-to-peer based, some things we can fix like long punts, long fgs, punt/kick returner incorrect attribs, etc., but some known flaws not easily fixed by simple hex edits, like qb being able to throw 120 yards, nt dive too easy, limited ability to change offensive/defensive play logic etc. etc. etc.

cheating is way too easy (via turbo & play picking programs & to lesser extent ***conditions checking programs)

***I realize most players (myself included) would not consider checking for defensive player conditions cheating. however, i'm guessing that many online players probably don't know how or don't want to use these types of programs.

rewrite/port

advantage(s): open source, server based.

ability to centralize game engine on server instead of on peer to peer clients as it is now. ability to use more granular/accurate player attributes. (1-100) instead of (1-13) per attribute (e.g.6,13,19,25,31,38,44,50,56,63,69,75,81)

discouraging cheating, easier to detect/disallow things like turbo and code is more secure on server and thus more difficult to use play picker type programs

disadvantage(s): mega hard work for no pay, possible divorces (sorry speaking for myself here...), managing community expectations while at the same time allowing for very necessary beta/gameplay testing & legal concerns

so for now i am going to continue on with (previously secret) project "Diet Sprite" (Rod named it that btw) if for no other reason than just to have FUN FUN FUN without the limitations of old technology, emulators, ROMs, etc.

offers of help in any capacity are greatly appreciated and i look forward to working with anyone who loves this game as much as i do.

hope to see many of you in Madison on March 5.

[bruddog]

Sounds awesome man. Definitely willing to help with anything. I'm a beginning level programmer.

A couple of points:

My whole point about doing an emulator hack was that it would be MUCH easier to emulate the feel. I see you are taking sprite captures I'm assuming to get the physics of tecmo super bowl correct and to get the animations themselves correct.

There wouldn't be much point in more granular attributes unless you plan on changing the physics of the game completely and the field and sprite size.

The advantages are definitely numerous if you can port it to a higher level language decently...

[Knobbe]

http://pygame.org/news.html

godspeed

[cxrom]

I've toyed with a similar idea (with c/sdl), but couldn't really figure out how to format the plays in a way that was:

1. easy to edit by a generic text editor or an outside program specific for playbook design

2. being able to clone the original plays, while allowing for more complex things to be done

I thought of doing some halfass xml type format:

form=0

  ...some scripting codes: player, action, duration, etc...


  ...some scripting codes: player, route/block scheme, duration, etc...

You could even do away with the formation code, and instead have values to use to position the player from the ball/LOS. Since I haven't messed around with editing plays in TSB, I wasn't sure if this would be enough information. Any thoughts?

Teams and Leauges were defined in a similar text format so that you could have a large pool of teams that could be used in any number of leagues you wanted. Players were defined in the team files, and conferences in the league files. Trading players would be a problem though, unless you edit the team files...

[bruddog]

I think having a formation code is nice. That way you don't have to constantly define the formation over and over. And allows others to create formations simply.

But your xml format looks like how I would structure it.

I'm not sure what kinds of complex things you are looking to do but just make sure the command set includes AT LEAST the same or similar commands that tecmo uses.

Reading this topic will help as it details all the possible player commands during plays.

ttp://tecmobowl.org/forum//viewtopic.php?f=22&t=11941

[NateNT321]

Wow! Lots of good feedback all - sorry I went and disappeared but the point about community expectations and divorces is kind of scary but valid.

I think I'll start to muck around and if i can get a little prototype going I'll try to pop in. I do appreciate this thread - it's given me a lot to think about