https://projectoh.svn.sourceforge.net/svnroot/projectoh
Or browse my
Browse SVN
Currently it's far from playable,though I would like to make the development more transparent to others.
5/09/2008
Source available at sourceforge svn
You can check out the source code via sourceforge svn now:
https://projectoh.svn.sourceforge.net/svnroot/projectoh
Or browse myhacks magick via sourceforge viewvc:
Browse SVN
Currently it's far from playable,though I would like to make the development more transparent to others.
https://projectoh.svn.sourceforge.net/svnroot/projectoh
Or browse my
Browse SVN
Currently it's far from playable,though I would like to make the development more transparent to others.
4/08/2008
Progress on pre-alpha part 3
I am having a problem with map at the moment,I will need to either store mover objects pointers in map tile or make collision-test on all objects every frame,apparently the latter sounds a bit stupid,but pointers-in-maptile has its own problem:
In Ocean Horizons,each tile is 32 by 32 pixels big,so in order to represent the 'world' at an acceptable size,I will need tons of them,more precisely 1024x1024+ of them,in a worst case scenario,there might be few hundreds objects overlapping each other in one tile at a time,let's say 200,then there will need to be 1024x1024x200 pointers,in 32bit it's 1024x1024x200x4 bytes or 800MB,in 64bit it's 1024x1024x200x8 bytes or 1.6 GIGABYTE!Now this sounds even more stupid than the collision-test on all objects every frame idea.
Perhaps I should allocate them dynamically,but a pointer pointing to array of pointers on each tile doesn't sound like a good solution either.Hopefully I will get this problem sorted out soon.
In Ocean Horizons,each tile is 32 by 32 pixels big,so in order to represent the 'world' at an acceptable size,I will need tons of them,more precisely 1024x1024+ of them,in a worst case scenario,there might be few hundreds objects overlapping each other in one tile at a time,let's say 200,then there will need to be 1024x1024x200 pointers,in 32bit it's 1024x1024x200x4 bytes or 800MB,in 64bit it's 1024x1024x200x8 bytes or 1.6 GIGABYTE!Now this sounds even more stupid than the collision-test on all objects every frame idea.
Perhaps I should allocate them dynamically,but a pointer pointing to array of pointers on each tile doesn't sound like a good solution either.Hopefully I will get this problem sorted out soon.
3/13/2008
Why OSS game developments suck
Firstly, this is not a rant about OSS game developments(Open-Source-Software for those that don't understand geeky abbreviations), so don't take it personally.It's just some random thoughts I have after observing various OSS game projects.
1.retarded precise versioning
Almost all open source games use a 3 tier versioning technique,that is,Major.Minor.MinorMinor,as you may wonder:WTF is MinorMinor? MinorMinor is the actual version number that gets incremented by 1 every time a release is published.An example
game version 0.0.1(initial alpha)
minor release = 0.0.1 + 0.0.1 (takes 1-3 months)
major release = 0.0.1 + 0.1.0 (takes about 10 minor release)
breakthrough = 0.0.1 + 1.0.0(takes about 5 major release)
So...let's work out the formula
Development of an Open Source Games would take 5*10*(1-3months) or 50 months to 150 months to reach 1.0.0,I bet most players will be scared after reading this if they do play 0.0.x version of an OSS game.
2.Irresolute Cautious to do release
OSS developer always over-cautious about the quality of a release,whether it's alpha,beta or release candidate,this further increases the delay between minor releases.
3.More people make the project's development faster???
OSS developers believe more developers will make the project's development faster,this is simply NOT the truth.Sometimes 1 good developer with iron-fist style development style will be a lot faster than 2 good developers or more,since with more than one experts in one field,the actual works on code will be replaced by endlessflamewars expert-exchanges between the developers.
4.Write perfect game not perfect code and documentation
An impatient player who cares only about graphics will take a look at the in-game graphics and say:this game looks like 80's,then uninstall it and never install it again.
An average causal player who cares more about gameplay will play the game for a few minutes,and he will uninstall this game if the controls/user interfaces is uncomfortable.
The most patient and wise player will try his best to play throughout the game and will only uninstall this game if it has no replayability or depth.
5.Mess with the bestdie like the rest
Exist libraries have been used/field-tested for years and they are ready for production,while some developers irresistibly want to write libraries from scratch for their game,because they think the exist wheel is not good enough,unfortunately their ambition usually ends up as a broken wheel,with a broken lib/core the game project's death will be imminent.
6.Get bound by your own freedom
What would you feel if your painting can be reworked by anyone including those who are not even artists and those who alter it in a destructive way?
To satisfy the project host,distro distributors,OSS project admins are forced todupe convince the artists to release their arts under GPL/CC-by-sa.This behavior particularly pisses artists off,cause artists care more about the integrity of their arts and their names being mentioned as original author.
Please note that avoiding the problems I listed won't guarantee your project success,but it should help prevent your project from being slow-downed or killed by the pitfalls that creep in OSS game development.The key contributes to an OSS game project is still your dedication,and the best way to motivate yourself is to play and learn to love the game you are developing.
1.
Almost all open source games use a 3 tier versioning technique,that is,Major.Minor.MinorMinor,as you may wonder:WTF is MinorMinor? MinorMinor is the actual version number that gets incremented by 1 every time a release is published.An example
game version 0.0.1(initial alpha)
minor release = 0.0.1 + 0.0.1 (takes 1-3 months)
major release = 0.0.1 + 0.1.0 (takes about 10 minor release)
breakthrough = 0.0.1 + 1.0.0(takes about 5 major release)
So...let's work out the formula
Development of an Open Source Games would take 5*10*(1-3months) or 50 months to 150 months to reach 1.0.0,I bet most players will be scared after reading this if they do play 0.0.x version of an OSS game.
2.
OSS developer always over-cautious about the quality of a release,whether it's alpha,beta or release candidate,this further increases the delay between minor releases.
3.More people make the project's development faster???
OSS developers believe more developers will make the project's development faster,this is simply NOT the truth.Sometimes 1 good developer with iron-fist style development style will be a lot faster than 2 good developers or more,since with more than one experts in one field,the actual works on code will be replaced by endless
4.Write perfect game not perfect code and documentation
An impatient player who cares only about graphics will take a look at the in-game graphics and say:this game looks like 80's,then uninstall it and never install it again.
An average causal player who cares more about gameplay will play the game for a few minutes,and he will uninstall this game if the controls/user interfaces is uncomfortable.
The most patient and wise player will try his best to play throughout the game and will only uninstall this game if it has no replayability or depth.
5.Mess with the best
Exist libraries have been used/field-tested for years and they are ready for production,while some developers irresistibly want to write libraries from scratch for their game,because they think the exist wheel is not good enough,unfortunately their ambition usually ends up as a broken wheel,with a broken lib/core the game project's death will be imminent.
6.Get bound by your own freedom
What would you feel if your painting can be reworked by anyone including those who are not even artists and those who alter it in a destructive way?
To satisfy the project host,distro distributors,OSS project admins are forced to
Please note that avoiding the problems I listed won't guarantee your project success,but it should help prevent your project from being slow-downed or killed by the pitfalls that creep in OSS game development.The key contributes to an OSS game project is still your dedication,and the best way to motivate yourself is to play and learn to love the game you are developing.
2/25/2008
Progress on pre-alpha part 2
I was mainly working on Opengl renderer,the SDL blit speed is simply not good enough for 32bit color tiles,with 800x600/32x32 tiles and 256 Guichan image buttons,an optimized windows/linux release build linked against release version of SDL(provided by SDL site/distro,assuming they are O2) runs at approximately 10fps,while a debug one runs at about 5fps on windows/3fps on linux.
Now Opengl renderer is working and it has much better performance than SDL,but it will require a 3D card that supports 1.1 version of opengl.
Data loading via GM is sorta working,I can load info of different ship parts from .gm files.Current goal is to make a working ship sprite with 8 directions(45 degree per frame),so I could test the mobile object class I wrote earlier.Another goal is keeping both texture size and texture amount as low as possible,my goal is keeping total amount under 32MB.
32MB = 32 * 1024 * 1024 B = 32 * 512 * 512 * 4 B = roughly 32 512x512 32bit bitmap's
Wow that's a lot,now I should really stop talking to myself on this lifeless blog and get back to coding. =)
Now Opengl renderer is working and it has much better performance than SDL,but it will require a 3D card that supports 1.1 version of opengl.
Data loading via GM is sorta working,I can load info of different ship parts from .gm files.Current goal is to make a working ship sprite with 8 directions(45 degree per frame),so I could test the mobile object class I wrote earlier.Another goal is keeping both texture size and texture amount as low as possible,my goal is keeping total amount under 32MB.
32MB = 32 * 1024 * 1024 B = 32 * 512 * 512 * 4 B = roughly 32 512x512 32bit bitmap's
Wow that's a lot,now I should really stop talking to myself on this lifeless blog and get back to coding. =)
2/10/2008
Progress on pre-alpha
I registered and created a project on sourceforge.net(and they approved my project,thanks sourceforge.net).I will import local svn repository on my harddisk into sourceforge.net as soon as test data is relatively complete and compile-able on both windows and linux.
Actually I have been working on this project for more than half a year now,but due to other projects draining most of my spare time,it did not progress very well =(
Renderer:
I wrote a simple tile drawer using SDL_Blit functions,but it's more 3d orientated than 2d orientated,so the performance is a bit unacceptable with 32bit per pixel.I might consider using OGL to do the pixel fill instead.
Current renderer features:
Input:
Current Input system uses SDL input events,I added some basic features such as doubleclick and hold.
Features:
GUI uses guichan library,which is probably the best and the most versatile GUI library available,its forums and its author are also very helpful,for a list of features it supports please refer to guichan's site: http://guichan.sourceforge.net
Scripting:
I use gamemonkey(GM) script,which is an underrated/unpopular scripting language designed specifically for games.GM supports universal table(any element in any table can be any data type) like LUA but GM is more powerful than LUA for games.
Currently GM is only used for data loading and storage.
Sound and Network:
No time has been spent on them yet,they have the least priority in my todo list. =)
That's all for now.
Actually I have been working on this project for more than half a year now,but due to other projects draining most of my spare time,it did not progress very well =(
Renderer:
I wrote a simple tile drawer using SDL_Blit functions,but it's more 3d orientated than 2d orientated,so the performance is a bit unacceptable with 32bit per pixel.I might consider using OGL to do the pixel fill instead.
Current renderer features:
- Draw background layer(draw an image before anything else)
- Draw grids(a hack to draw 4 (1*TileWidth) rect to resemble grids around a tile)
- Draw tiles
- Per pixel scrolling
Input:
Current Input system uses SDL input events,I added some basic features such as doubleclick and hold.
Features:
- SDL input based input
- double-click handling
- hold handling with duration
GUI uses guichan library,which is probably the best and the most versatile GUI library available,its forums and its author are also very helpful,for a list of features it supports please refer to guichan's site: http://guichan.sourceforge.net
Scripting:
I use gamemonkey(GM) script,which is an underrated/unpopular scripting language designed specifically for games.GM supports universal table(any element in any table can be any data type) like LUA but GM is more powerful than LUA for games.
Currently GM is only used for data loading and storage.
Sound and Network:
No time has been spent on them yet,they have the least priority in my todo list. =)
That's all for now.
2/04/2008
Magick Panda' FAQ
Q:What is your hobby game project?
A:It's an open-source clone of old school SNES game named Uncharted Waters: New Horizons Also known as Daikoukai Jidai II in Japanese,firstly released in 1994,with a superb graphics which is utterly unacceptable for you modern peeps who are accustomed to state-of-art 3D graphics.
Q:What is your game's goals?
A:
*Top-down plain 2D game 32bit graphics(this roughly quadruples the amount of pixels to fill compare to 8bit(256),so 3D acceleration might be needed)
*All functionalities from original game
*Small scale MP support 2-8 players
Q:Ah you mentioned open-source,License?
A:code and contents I created will be released under GNU GPL V3
Will add more later
A:It's an open-source clone of old school SNES game named Uncharted Waters: New Horizons Also known as Daikoukai Jidai II in Japanese,firstly released in 1994,with a superb graphics which is utterly unacceptable for you modern peeps who are accustomed to state-of-art 3D graphics.
Q:What is your game's goals?
A:
*Top-down plain 2D game 32bit graphics(this roughly quadruples the amount of pixels to fill compare to 8bit(256),so 3D acceleration might be needed)
*All functionalities from original game
*Small scale MP support 2-8 players
Q:Ah you mentioned open-source,License?
A:code and contents I created will be released under GNU GPL V3
Will add more later
Magick Panda's blog test
I am never a fan of blog hype nor am I like writing articles and shytz online like most others do,but I would like to open a blog for my hobby game project.
This is a test post.
This is a test post.
Subscribe to:
Posts (Atom)