Here we go!
This branch is for discussing code itself. Remember that our first task is to make ENGINE, not game. And now we must invent some script language to use with this engine as describer of games. And remember that GAME itself must be written only in this fuckin language, not having a deal with engine's source!
I see no reason to use C++ instead of C... but this question still opened.
Now! Begin the invention! Turn your minds ON! Offer! Every idea is good one. (Who is the weakest chain?! :))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As told it shall use some kind of machine code - binary - to write games.
But it is not necessary for you to have such a binary code. Your game is always in principle finished, you only have to change the data from game to game.
You'll need world data, object data, creature data and dialogues, sound and music files; perhaps animations. And of course editors for them.
BTW: to this "there is no magic" point: what about LOOM ?
Such an "engine" has its limits. It's much more easy to do without an own programming language, but it has the disadvantage that you can't enhance your game then with unsupported features...
Second, the graphic question: you obvisiously misunderstood the illustrations of Universon Dragonflight.
The Golden Axe engine of it is no real 3D; all the tiles are 2D sprites. The advantage of such a graphic engine is, that you can create -combine- huge (side-scrolling) worlds, where you can drop every object, where you like, you can introduce higher and smaller areas without programming.
But the movement is limited. Zak McKracken could walk upwards - "down the street", where he shrinked. Such a gag means more work on the code and for the artist.
The Monkey Island adventures combined the landscape out of complete backgrounds and objects in the foreground. A question of personal liking.
It is much work to draw every place in the world by hand, but the result may also be worth it.
If your games should be able to share sprites with other games, it's better to use a system, where the sprites at least do have special sizes, that you can place e.g. a cupboard into other worlds.
Also remember, that your hero might step a bit into water (the sea / on a beach), perhaps also swim or dive or something.
- In Monkey Island there was a bird's eye view of the island. Such will require another graphic engine.
- Remember that the world can have animated elements (candles e.g.)
---
A game should be the best one fat DAT file: all game files put together as a kind of archive.
Graphics and sound/music files may be external files, so they can be shared.
In the first subfile may be stored, how the name of the game is, existing items / actions (EXAMINE <item> ...), perhaps icons/sprites/font for the menu/complete look, start position, intro animation/text whatever - you'll need to think about, how the game really will look like.
Use the best the INI format (this way:
[game]
name="Ape Planet"
)
If you want localization support for the games, you must replace every text by an identifier, which is assigned to a string in your strings file.
Second the world / maps - put all together in the fat file; you are always starting in map #1.
Part of the map data is, where you will get (map # and coordinates) if you leave the map up/down, left/right or climb up/down - the best would be to let this yet be done by script.
Special script events can "teleport" you to more places.
The dialogues are also part of the game data and numbered. You can assign every object or creature in the game a dialogue file. They have the same script language as the map script.
example:
left: ! the "left" function
place 5,23,11,2 ! put into Callahan's Bar
right:
forward (right screen border), backward(left screen border), up and down
- those events are responsible in the maps for leaving the map.
'enter' is done on entering a map, and 'leave' on every trial to leave the map. If a map shall change during game, you can do it by script instead of saving a copy of the map file. (open door => place open door object over old door)
examine lamp:
event, if you clicked "examine" and the lamp object (in inventory or enviroment)
some instructions for the script:
! comments, rest of line is ignored
print - displays a text line - in the text window (?)
if -expression-
else
endif
set flag# - see annotation
clear flag#
gosub myroutine - jump to "myroutine:"
return
give -item-
take -item-
place map#, x, y, z -"teleports"
walk creature,x,y,z - moves creature to coordinate (0 = player)
redress creature, number - changes sprite of creature
put object#,x,y,z - (re)places an object in the map
settime minutes - increases current time by minutes
...
expressions:
( ) and or xor not ( )
got(-item-) - has got item
flag(-no-) - flag is set
time(-time-) - time is just a number - "game minutes"; longer travels are increasing this value by hours. You determine the date of minute #0
...
It may be sensible if you start writing an adventure and enhance your engine by all instructions you still need.
annotation:
you've got a big flag array, each number -if set or not- represents one event resp. state. In a new game, all flags are 0. The flags are the most important part of the save file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm standing on Scripting Language. Look, if nobody will even talk... maybe I will go into ur Universon project... if you don't mind of course... but i hope SOMEONE ELSE will say smth!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here we go!
This branch is for discussing code itself. Remember that our first task is to make ENGINE, not game. And now we must invent some script language to use with this engine as describer of games. And remember that GAME itself must be written only in this fuckin language, not having a deal with engine's source!
I see no reason to use C++ instead of C... but this question still opened.
Now! Begin the invention! Turn your minds ON! Offer! Every idea is good one. (Who is the weakest chain?! :))
Again Universon :o)
As told it shall use some kind of machine code - binary - to write games.
But it is not necessary for you to have such a binary code. Your game is always in principle finished, you only have to change the data from game to game.
You'll need world data, object data, creature data and dialogues, sound and music files; perhaps animations. And of course editors for them.
BTW: to this "there is no magic" point: what about LOOM ?
Such an "engine" has its limits. It's much more easy to do without an own programming language, but it has the disadvantage that you can't enhance your game then with unsupported features...
Second, the graphic question: you obvisiously misunderstood the illustrations of Universon Dragonflight.
The Golden Axe engine of it is no real 3D; all the tiles are 2D sprites. The advantage of such a graphic engine is, that you can create -combine- huge (side-scrolling) worlds, where you can drop every object, where you like, you can introduce higher and smaller areas without programming.
But the movement is limited. Zak McKracken could walk upwards - "down the street", where he shrinked. Such a gag means more work on the code and for the artist.
The Monkey Island adventures combined the landscape out of complete backgrounds and objects in the foreground. A question of personal liking.
It is much work to draw every place in the world by hand, but the result may also be worth it.
If your games should be able to share sprites with other games, it's better to use a system, where the sprites at least do have special sizes, that you can place e.g. a cupboard into other worlds.
Also remember, that your hero might step a bit into water (the sea / on a beach), perhaps also swim or dive or something.
- In Monkey Island there was a bird's eye view of the island. Such will require another graphic engine.
- Remember that the world can have animated elements (candles e.g.)
---
A game should be the best one fat DAT file: all game files put together as a kind of archive.
Graphics and sound/music files may be external files, so they can be shared.
In the first subfile may be stored, how the name of the game is, existing items / actions (EXAMINE <item> ...), perhaps icons/sprites/font for the menu/complete look, start position, intro animation/text whatever - you'll need to think about, how the game really will look like.
Use the best the INI format (this way:
[game]
name="Ape Planet"
)
If you want localization support for the games, you must replace every text by an identifier, which is assigned to a string in your strings file.
Second the world / maps - put all together in the fat file; you are always starting in map #1.
Part of the map data is, where you will get (map # and coordinates) if you leave the map up/down, left/right or climb up/down - the best would be to let this yet be done by script.
Special script events can "teleport" you to more places.
The dialogues are also part of the game data and numbered. You can assign every object or creature in the game a dialogue file. They have the same script language as the map script.
example:
left: ! the "left" function
place 5,23,11,2 ! put into Callahan's Bar
right:
forward (right screen border), backward(left screen border), up and down
- those events are responsible in the maps for leaving the map.
'enter' is done on entering a map, and 'leave' on every trial to leave the map. If a map shall change during game, you can do it by script instead of saving a copy of the map file. (open door => place open door object over old door)
examine lamp:
event, if you clicked "examine" and the lamp object (in inventory or enviroment)
some instructions for the script:
! comments, rest of line is ignored
print - displays a text line - in the text window (?)
if -expression-
else
endif
set flag# - see annotation
clear flag#
gosub myroutine - jump to "myroutine:"
return
give -item-
take -item-
place map#, x, y, z -"teleports"
walk creature,x,y,z - moves creature to coordinate (0 = player)
redress creature, number - changes sprite of creature
put object#,x,y,z - (re)places an object in the map
settime minutes - increases current time by minutes
...
expressions:
( ) and or xor not ( )
got(-item-) - has got item
flag(-no-) - flag is set
time(-time-) - time is just a number - "game minutes"; longer travels are increasing this value by hours. You determine the date of minute #0
...
It may be sensible if you start writing an adventure and enhance your engine by all instructions you still need.
annotation:
you've got a big flag array, each number -if set or not- represents one event resp. state. In a new game, all flags are 0. The flags are the most important part of the save file.
I'm standing on Scripting Language. Look, if nobody will even talk... maybe I will go into ur Universon project... if you don't mind of course... but i hope SOMEONE ELSE will say smth!